business-agility

Как обеспечить развитие организации. Часть 3: Специфичные роли в SAFe

Итак, пришло время разобраться с нетипичными для Agile ролями, присутствующими в Scaled Agile фреймворке: Машинист (Release Train Engineer), Архитектор решения и Системный архитектор.

АГ
Артем Гринякин
24 февраля 2022 г.
Полезна?

Release Train Engineer

Для того чтобы понять глубину и уникальность каждой роли, обратимся к биологии и для этого возьмем наименее изученный орган человеческого тела, а именно головной мозг. Итак, что мы имеем: нейроны передают данные внутри головного мозга, имеют возможность формировать пары, образуя синапсы; аксон же в свою очередь обеспечивает проведение информации от тела нейрона к другому нейрону. Ничего не напоминает? Именно так работает организация, которую можно представить в виде нейронной сети, для эффективной работы которой необходимы качественные связи.

И как раз в этом нам поможет роль машиниста (RTE) из SAFe, ведь по своей природе он является эволюционным развитием роли Скрам-мастера, но с большим фокусом на уровень программы и межкомандного взаимодействия. RTE предоставляет такие сервисы как: фасилитация ART встреч, идентификация и своевременная эскалация препятствий/ ограничений,  управление рисками и обеспечение непрерывного процесса улучшений.

Общий список обязанностей содержит более 20 пунктов, но в целях экономии вашего времени мы объединили их в 7 групп:

  • Коучинг стримов (ART) в контексте улучшений, направленных на продуктивность и процесс
  • Результативное и эффективное проведение встреч: PI планирование, системные демо, формирование видения, построение Roadmap, встречи по подготовке к PI, встречи по завершению PI, встречи по синхронизации и другие.
  • Обучение команд в таких направлениях как Продукт, Проект, DevOps, Команда, SAFe, и адаптация Agile ценностей и принципов
  • Проведение внутреннего аудита с целью определения точек роста (Agile зрелость) и дальнейшего построения стратегии развития
  • Определение и настройка структуры ART с учетом  роста организации
  • Обеспечение прозрачности на уровне программы, особенно в контексте установленных целей на PI
  • Обеспечение взаимодействие между продуктовым штабом (PM, Владельцы продукта, Владельцы бизнеса) и продуктовыми командами.

Архитекторы

Но что происходит в ситуации, когда система сталкивается с комплексной проблемой? Предположим, нам нужно перейти с монолитной архитектуры на микро-сервисную, или мы хотим перенести наш продукт в Cloud. Вопрос взаимодействия, безусловно, остается актуальным, но появляется необходимость в углубленной экспертизе, и как раз здесь в игру вступают архитекторы.

И начнем мы с архитекторов решения (Solution Architect). Правда сначала нужно определится с тем, что такое решение. Условимся, что под решением мы понимаем сквозные изменения, которые требуется провести на уровне множества систем с целью решения поставленной задачи. Например, обновить алгоритм скоринга по потребительскому кредиту — это уровень одной системы, а вывести новый продукт, скажем, кредит для учащихся — это комплексное решение, и одной системой тут не ограничиться. Часто это еще называют сквозным решением.

 В общем и целом архитектор решения (объединение архитекторов) определяет и коммуницирует техническое и архитектурное видение. Взаимодействие же с бизнесом хорошо иллюстрирует ниже представленный постер.

Как обеспечить развитие организации. Часть 3: Специфичные роли в SAFe

Если мы рассмотрим взаимодействие архитектора решения и системных архитекторов, то увидим, что в рамках данной коллаборации комплексные решения декомпозируются на составные части: технические фичи, истории — и далее уже попадают в Agil-команды. Стоит отметить что от системных архитекторов в большей степени требуется поддержка консистентности изменений в рамках системы или, другими словами, обеспечение стабильности и соответствия стандартам.

Отдельно стоит учитывать, что зачастую системный архитектор может брать на себя роль архитектора решения при условии, что большая часть изменений лежит в рамках его системы, а коллеги могут предоставить ему необходимую экспертизу по другим системам.

Хотите узнать больше о каркасе SAFe, приходите к нам на тренинг Leading SAFe.

Частые вопросы
Почему роль RTE в SAFe сравнивают с аксоном в нервной системе организма?
RTE, как аксон в нервной системе, обеспечивает качественную передачу информации между всеми элементами организации. Это эволюционное развитие роли Скрам-мастера, но с расширенным фокусом на уровень программы и межкомандное взаимодействие. RTE создает эффективные связи между командами, управляет рисками и обеспечивает непрерывные улучшения.
Как Release Train Engineer решает главную проблему масштабирования Agile?
RTE решает ключевую проблему масштабирования – потерю эффективности при росте организации. Он выступает единым центром координации, проводя системные демо, PI планирование и обеспечивая прозрачность целей на уровне программы. Это позволяет сохранить agile-преимущества даже при большом количестве команд.
Почему системному архитектору в SAFe иногда доверяют роль архитектора решений?
Системный архитектор может взять на себя роль архитектора решений, когда большая часть изменений сосредоточена в его системе. При этом он получает экспертную поддержку от коллег по другим системам, что позволяет эффективно управлять комплексными изменениями без создания дополнительной роли.
Какое неожиданное преимущество дает разделение архитектурных ролей в SAFe?
Разделение на системных архитекторов и архитекторов решений позволяет одновременно обеспечить и стабильность систем, и внедрение инноваций. Пока системные архитекторы поддерживают консистентность изменений, архитекторы решений могут фокусироваться на сквозных трансформациях, таких как переход в облако или на микросервисы.
Чем RTE кардинально отличается от классического Скрам-мастера?
В отличие от Скрам-мастера, который фокусируется на одной команде, RTE работает на уровне программы и объединяет множество команд. Он отвечает за коучинг целых стримов, проводит PI планирование и системные демо, обеспечивая согласованную работу всего потока создания ценности.
Как архитектор решений в SAFe трансформирует бизнес-требования в технические решения?
Архитектор решений переводит комплексные бизнес-задачи в конкретные технические изменения. Он декомпозирует масштабные инициативы (например, запуск нового банковского продукта) на составные части, которые затем распределяются между системными архитекторами и agile-командами для реализации.
"Каждый проект начинается с разговора о задаче. Часто за исходным запросом кроется большой организационный контекст, который нужно изучить для правильного решения задачи. Поэтому мы много спрашиваем на старте."
Дмитрий Лобасев, управляющий партнер OnAgile

Сначала слушаем, задаём вопросы, разбираемся в ситуации. Потом предлагаем подход и только тогда обсуждаем условия.

Расскажите о вашей задаче