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

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

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

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.

Еще публикации по Agile в Гибкие организации

Публикация
Ритейл
Испытание Новым годом: как ритейлу справиться с авралом и получить новых клиентов
Пик заказов перед Новым годом — серьезное испытание для ритейлеров. Проблемы с доставкой, перегруженная служба поддержки и недовольные покупатели, с одной стороны. И рекордная выручка и приток новых клиентов — с другой.
Публикация
Гибкие организации
Как обеспечить развитие организации. Часть 2: Роли в SAFe
Один из самых популярных фреймворков масштабирования организации — SAFe, или Scaled Agile Framework. Разбираемся, на чем он основан и какие роли есть в SAFe.
Интервью
Гибкие организации
Увеличение гибкости (agility) компании
Дэйв Томас, один из авторов Agile Manifesto, в своем интервью раскрывает понятие «гибкости» компании. Вот небольшой отрывок из его интервью.
Кейс
Банкинг
2 часа вместо 7 суток: внедрение Agile в международном банке
Как оптимизация внутренних процессов помогла в разы увеличить скорость выпуска карт.

Мы помогаем организациям с 2004 года

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!