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

Release Train Engineer

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

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

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

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

Архитекторы

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

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

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

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

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

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