Solution Train Engineer — лидер и коуч множества Agile Release Trains в SAFe®
Из этой статьи вы узнаете о роли STE в SAFe® (Scaled Agile Framework®). Кто он и что делает? Как и куда развиваться, чтобы им стать? Как постигнуть дзен?
Вольный перевод статьи Solution Train Engineer — Scaled Agile Framework.
Система никогда не является суммой ее частей — это продукт их взаимодействия. — Рассел Акофф
Solution Train Engineer (STE) — это лидер и наставник для всего Solution Train (поезда решений), он фасилитирует и направляет работу всех Agile Release Trains (ARTs) и поставщиков целого Value Stream (потока поставки ценности).
Чтобы преуспеть в цифровую эпоху, организации должны эффективно создавать и развивать большие комплексные продукты, которые выполняют наиболее ключевые функции для своих клиентов. Эта работа, в которой могут участвовать сотни или даже тысячи работников умственного труда, зачастую приносит хорошие плоды, но требует больших усилий. Быстро создать такие решения сложно и требуется надежный процесс создания ценности, обучения и адаптации. Системы такой сложности требуют особой роли для координации, фасилитации и помощи в направлении всех ARTs, составляющих Solution Train, на пути к продуктивным результатам. Роль STE заключается в обеспечении эффективного взаимодействия всех ARTs в Solution Train, что требует наличия возможности децентрализованного принятия решений, согласования и координации всего Solution Train.
STE владеет единым видением всего процесса разработки и поставки. Это сложная задача, потому что в Solution Train (поезде решений) задействовано несколько ARTs (поездов), которые должны работать и совершенствоваться одновременно. Важнейшие практики SAFe, определяющие работу Solution Train, которым STE должен способствовать, сосредоточены на всем Value Streams (потоке поставки ценности). Основой этих практик являются инкрементальные поставки с быстрыми встроенными циклами обучения.
В поезде решений фактическая работа по разработке выполняется в ARTs, которые создают компоненты, подсистемы и возможности большого решения. Поезд решений создает связь между идеей и фактической реализацией. STE должен установить основополагающую коммуникацию между теми, кто выносит на обсуждение инициативы, и теми, кто в конечном итоге их реализует.
Каждый Solution Train сопровождают три ключевые роли, см. рисунок 1.
Рисунок 1. Роли Solution Train
Эти роли оказывают поддержку друг другу. Без надлежащей помощи со стороны Solution Management (Менеджмент Решения) и Solution Architect (Архитектор Решения), STE не может помочь поезду решений двигаться в правильном направлении. Аналогичным образом, без STE двум другим ролям будет трудно воплотить свои планы в рабочее полноценное решение.
Помимо непосредственного содействия работе Solution Train, STE выступает в качестве лидера Lean-Agile для Solution Train и часто в качестве коуча для сообщества Release Train Engineer (RTE). Это может включать дополнительные роли в ART в части подходов Lean и Agile. STE помогает заинтересованным лицам ART и RTE понять их влияние разработку решения, устанавливая правильный баланс централизованного и децентрализованного принятия решений.
Содержание статьи
Обязанности
Как правило, ответственность STE делится на четыре отдельных области.
Рисунок 2. Зоны ответственности STE
Подготовка к PI-планированию Solution Train
Как правило Solution Train имеет множество источников входных данных и широкий круг заинтересованных сторон. В результате каждый PI Planning (Планирование Инкремента Программы, PI-планирование) для Solution Train требует тщательной подготовки. Хотя подготовка к PI Planning наиболее интенсивна во время IP Iteration (итерация инноваций и планирования), достигая кульминации на сеансе Pre-Planning (предварительное PI-планирование), некоторые действия могут выполняться на предыдущих итерациях.
Рисунок 3. Совместная, адаптивная сеть мероприятий по подготовке PI Planning
Когда начинать процесс подготовки, зависит от конкретного контекста поезда решений. Однако, оптимальный подход позволяет избежать слишком раннего или слишком позднего принятия решений, не оставляя достаточно времени для согласования последствий (что может привести к задержке PI-планирования).
Во время подготовки к PI-планированию STE часто взаимодействует с несколькими заинтересованными лицами. Одной из основных обязанностей STE является построение отношений, установление жизненно важных связей внутри и за пределами Solution Train, чтобы помочь группе работать как единое целое.
Когда Solution Train приближается к границе PI (Program Increment), STE должен сосредоточиться на следующем:
- Обновить Vision (концепцию решения) и Roadmap (дорожную карту). STE должен предоставить командам ARTs видение решения и дорожную карту заблаговременно для подготовки к PI-планированию. Менеджмент решения и заинтересованные лица Solution Train обычно выполняют эту работу вместе. STE гарантируют, что это произойдет быстро и таким образом, чтобы его могли использовать ARTs. Он также гарантирует, что архитектор решений и заинтересованные лица предоставят технологическое видение, которое определяет архитектуру решения и стратегию реализации.
- Помощь в подготовке бэклога решения (Solution Backlog). По мере приближения границы PI Solution Management необходимо актуализировать бэклог решения. Однако, значительная часть работы Solution Train может выполняться локально в рамках конкретных ARTs. STE работает с RTE, чтобы гарантировать, что ARTs хорошо подготовлены к предстоящему PI.
- Помощь в обнаружении внешних зависимостей. Подготовка к планированию часто включает в себя определение важных внешних зависимостей, что может быть проведено как серия встречь или как отдельная специальная встреча. Понимание высокоуровневых зависимостей перед PI Planning позволяет поезду решений избегать разрывов связи и дублирования работы. Это помогает установить необходимые коммуникации с другими сторонами, критически важными для успеха в предстоящем PI.
- Подготовка и донесение повестки предстоящего PI Planning для поезда решения. Поезд решения может включать сложные взаимодействия между входящими в его состав ARTs, влияющими на структуру предстоящего PI-планирования решения (длительность, перекрытие часовых поясов, точки синхронизации и т.д.). STE готовят повестку планирования и сообщают ее всем RTE заблаговременно, чтобы было время для корректировок.
- Гарантия необходимого участия в PI-планировании. В зависимости от предстоящей работы и структуры внешних зависимостей, конкретные заинтересованные лица должны быть вовлечены в PI-планирование решения. Они будут предлагать новые задачи, отвечать за финансирование и стратегию, или предоставлять информацию о клиентах или бизнес-результатах. STE обеспечивают подготовку заинтересованных лиц и их присутствие на PI-планировании. Кроме того, в различных сессиях PI-планирования на уровне решения могут участвовать различные представители ARTs. STE должен тщательно организовать все эти мероприятия.
- Помощь поезду решений в оценке его мощности (capacity). Чтобы помочь понять способность поезда решений выполнять работу, STE собирает соответствующие показатели PI. К ним относятся предсказуемость PI, общая емкость Solution Train и пропускная способность по реализации capability (возможностей) и feature (фич). Некоторые Solution Trains считают полезным создать предварительную схему возможностей и фичей по всем итерациям нового PI. Хотя этот прогноз помогает определить объем работы на основе capacity (вместимости) Solution Train, только команды могут принять на себя обязательства по выполнения работы.
Проведение PI-планирования Solution Train
Хотя PI Planning несколько отличается в разных поездах, опыт показывает, что PI Planning для Solution Train отличается еще больше. Большинство Solution Train слишком велики, чтобы следовать тому же процессу, что и для PI. Однако, появилось несколько успешных шаблонов планирования для Solution Train.
На рисунке 4 показан один распространенный и отчасти идеальный шаблон планирования:
Рисунок 4. Шаблон PI Planning для поезда решений
В этом примере бизнес-контекст освещается всем командам во всех ARTs. Затем ARTs индивидуально продолжают первый день планирования в соответствии с программой ART PI Planning, проведение встречи по продуктовой и архитектурной концепции, групповые встречи и т.д. В конце дня представители от каждого ART приносят результаты своего анализа со стороны руководства в Solution Train. Второй день следует структуре планирования ART, но как только каждый ART завершает свой план, консолидированные планы появляются по всему Solution Train.
Основываясь на этой структуре, существует несколько ключевых обязанностей STE для PI Planning:
- Помощь планированию решения на уровне поезда, включает в себя ряд действий: вовлечение заинтересованных лиц Solution Train; вовлечение представителей от ARTs, или всех представителей всех ARTs. Такой подход помогает обеспечить правильное планирование в большой группе людей.
- Помогает настроить эффективное взаимодействие между ARTs — Solution Train не включает в себя какие-либо команды напрямую (кроме, возможно, некоторых общих сервисов); все команды входят в ART. STE должны поддерживать надежную связь с RTE, чтобы быстро реагировать на препятствия во время PI-планирования и направлять свои усилия туда, где это больше всего необходимо. Хороший способ сохранить процесс планирования в нужном русле — выполнить несколько синхронизаций RTE во время планирования. Многие Solution Train считают полезным создать доску решений по образцу программной доски Agile Release Train. Пример доски решений можно найти в статье Pre- and Post Planning.
- Помогает ART коммуницировать с нужным им заинтересованными лицами по мере необходимости. В масштабе Solution Train обычно обнаруживают зависимости или потребность в дополнительных входных данных на этапе планирования, а не на этапе подготовки. Для этого часто требуется быстрый ответ, чтобы связать ART с определенными заинтересованными лицами или представителями других ARTs. STE должен обеспечить постоянное наличие у ART всего необходимого для эффективного планирования.
- Суммируйт цели PI Planning по всему Solution Train. Цель PI Planning для Solution Train заключается в том, чтобы команды придерживались общего плана. Чтобы представить это общее видение, STE фиксирует общие цели Solution Train. Некоторые STE считают полезным создать отдельный набор обобщенных целей. Другие просто представляют цели Solution Train как набор целей ARTs.
Для сильно распределенных Solution Trains (поездов решений) или в ситуациях, когда ARTs требуется изменить свои планы, мероприятие может занять более двух дней. Создание структуры планирования, подходящей для конкретных потребностей поезда решений, является важнейшей задачей для STE.
Координация поставки крупных решений
Разработка на основе каденции — это основной залог успеха Solution Train. В SAFe для успешного выполнения использует циклы обучения как части процесса разработки. Для Solution Trains такой цикл представляет собой PI.
Во время PI STE уделяет особое внимание следующим областям:
- Фасилитирует синхронизацию в рамках Solution Train. Регулярная синхронизация обеспечивает бесперебойную работу Solution Train. Многие STE используют еженедельные синхронизации с участием Solution Management, Solution Architects, Product Management, RTE и System Architects из ARTs. Доска Solution Train (доска зависимостей между ARTs) помогает сосредоточить внимание всех на нужных результатах. Некоторые Solution Train проводят несколько регулярных каденций для синхронизации по проблемным областям, например:
- Прогресс и препятствия (STE и RTE).
- Содержание работы (STE, Solution Management, ARTs Product Managers).
- Архитектура и технологии (STE, Solution and System Architects).
- Предусматривает регулярную интеграцию решений – регулярная интеграция компонентов решения снижает технические риски и обеспечивает устойчивый прогресс в разработке крупных решений.Эффективная интеграция на уровне решения часто является проблемой. Хотя ART вместе с Systems Team несут полную ответственность за интеграцию своих компонентов, STE контролирует, что все ARTs продвигаются к цели, и устраняет любые препятствия. STE также должны убедиться, что все ARTs понимают важность интеграции решений и предпринимают для этого конкретные действия. Выбор способа интеграции, инфраструктуры и инструментов обычно остается на усмотрение System Architects и соответствующих системных команд System Teams.
- Фасилитирует демонстрацию решения. Из-за своего размера Solution Train не всегда создает сквозную демонстрацию решения (Solution Demo) на каждой итерации. Тем не менее, как правило, очень важно регулярно интегрировать и демонстрировать решение во время PI. Создание демонстрационной версии решения в середине PI может стать хорошим началом. Кроме того, в зависимости от контекста, системной демонстрации на уровне отдельного ART могут иметь важное значение для решения. Также они могут получить пользу от участия заинтересованных сторон.
- Организация мероприятий по координации релизов. Успешное проведение обеспечивает частую и предсказуемую поставку ценности. Чтобы обеспечить структуру процесса, STE устанавливают ритм действий по выпуску внутри и между ARTs (например, отслеживание релизов, встречи по управлению релизами). В зависимости от контекста Solution Train релизы могут потребовать разной степени централизации координации. В некоторых случаях Solution Train должен координировать все релизы; в других за релизы полностью отвечает ART.
Если вы дочитали до этого абзаца, то точно любите полезный контент про современные практики управления. Еще больше материалов, видео и экспертных советов от Agile-коучей, анонсы бесплатных вебинаров и митапов в Телеграм-канале ScrumTrek
Измерение и улучшение
Чтобы выжить в цифровую эпоху, важно быстро и надежно разрабатывать и поставлять решения. Измерение скорости работы Solution Train позволяет со временем улучшать его.
В Solution Train используются те же метрики, что и во всем SAFe независимо от размера. Эти метрики включают показатели компетенций, потока и бизнес-результатов (см. рисунок 5).
Рисунок 5. Три области измерения SAFe
Для обеспечения прозрачности работы Solution Train STE должен:
- Определить показатели потока Solution Train. Чтобы обеспечить сквозное системное представление Solution Train, STE должен измерять поток самого высокого уровня (эпики решения и возможности). Простого агрегирования показателей эффективности Solution Train из составляющих его ARTs недостаточно. Независимо от того, насколько быстро движется каждый поезд, плохо скоординированные действия не приведут к высокой пропускной способности на уровне решения. Показатели потока, применяемые на уровне решения, фокусируются на системе и показывают более широкие показатели разработки и поставки решений.
- Настроить измерение результатов Solution Train. Поставка ценности успешна только тогда, когда она обеспечивает желаемые преимущества для клиентов и бизнеса. Следовательно, STE должен гарантировать, что результаты поезда решений измеряются и информируют о будущих решениях. Value Stream KPIs (Ключевые Показатели Потока Поставки Ценности) — это один из распространенных подходов к измерению результатов, осуществляемый в тесном контакте с Solution Management.
- Фасилитировать события Инспекции и Адаптации (Inspect and Adapt (I&A)) уровня Solution Train. Подобное событие является регулярной частью процесса улучшения SAFe и приводит к появлению набора элементов для улучшения. Некоторые из этих элементов будут напрямую связаны с ART, поэтому полезно синхронизировать I&A на уровне Solution Train с воркшопами по Инспекции и Адаптации которые проводят ARTs. Таким образом, поток поставки ценности остается оптимизированным в глобальном масштабе, и за этим последует значительный прирост производительности.
Кроме того, оценка поставки корпоративных решений (Enterprise Solution Delivery) может выявить текущие сильные и слабые стороны Solution Train. STE должны регулярно проводить эту оценку, чтобы поддерживать целенаправленные действия по улучшению производительности Solution Train.
Сходства и различия с ролью RTE
Роли STE и RTE во многом схожи. Оба содействуют событиям жизненного цикла PI, выступают в качестве лидеров Lean-Agile для своей группы и работают над развитием мышления и практики Lean-Agile в своих областях.
Но есть и важные отличия, связанные с большими решениями, поскольку они представляют собой более крупные инвестиции, которые имеют решающее значение для достижения бизнес-целей компании. В отличие от RTE, STE должен больше взаимодействовать и быть открытым для высокопоставленных заинтересованных сторон и менее открытым для команд, создающих ценность. Это создает определенные преимущества и проблемы.
Прежде всего, близость к уровню портфеля предлагает несколько возможностей для эффективного взаимодействия с Владельцами Эпиков (Epic Owners) и другими заинтересованными лицами в бизнесе и технологиях, которым необходимо взаимодействовать с Solution Train. Однако, в отличие от RTE, который напрямую взаимодействует с Agile-командами во время PI-планирования, Системных Демонстраций и событий Инспекции и Адаптации (Inspect and Adapt (I&A)), STE по своей сути не встроен в реальный контекст выполнения. В большинстве мероприятий, проводимых STE, могут участвовать представители ARTs. Тем не менее, STE должен иметь системный взгляд, чтобы оставаться на связи с контекстом выполнения путем:
- Участие в «Gemba-прогулках» вместе с другими лидерами.
- Посещение системных демонстраций ART (особенно когда ART производит что-то важное).
- Вовлечение избранных членов команды в мероприятия уровня Solution Train (в первую очередь, когда может быть полезен непосредственный вклад членов команды разработчиков).
STE также помогают связать ARTs с их конкретным клиентом, это зависит от типа решения и структуры Solution Train. Например, когда ARTs организованы вокруг подсистем или платформ, взаимодействие с клиентами происходит в других частях Solution Train.
ARTs, ориентированные на поток, часто напрямую взаимодействуют с соответствующим клиентом, поэтому в Solution Train необходимо обеспечить объединение информации, поступающей от клиентов, на более высоком уровне.
Для создания универсальных структур, работающих на основе сотрудничества, необходимо предпринять шаги по установлению связей с различными частями системы.
STE как лидер Lean-Agile
Новые STE обычно обладают многими организационными и управленческими навыками, необходимыми для выполнения их ролей. Однако, чтобы получить преимущества масштабируемой разработки на основе Lean-Agile, им может потребоваться изучить и перенять новые модели поведения лидерства Lean-Agile. В рамках этого пути STE должен будет сосредоточиться на следующих областях:
- Подавать пример. Лидер получает заслуженный авторитет, моделируя желаемое поведение для других, вдохновляя их включить пример лидера в свой собственный путь личного развития.
- Мышление и принципы – внедряя подход Lean-Agile к работе в свои убеждения, решения, реакции и действия, STE устанавливает требуемые стандарты организации.
- Управление изменениями. STE направляет трансформацию, создавая среду, подготавливая людей и развивая групповое поведение, которое приводит к желаемым результатам.
Как менеджеру, придерживающемуся принципов Lean-Agile, STE, возможно, понадобится переключиться с руководства и управления деятельностью на то, чтобы стать эффективным помощником группы. Эта роль сосредоточена на предоставлении поддержки командам, ARTs и Solution Train, которые должны быть самоорганизующимися и самоуправляемыми. Действия, которые характеризуют STE как лидера Lean-Agile, включают:
- Умение слушать команды и оказывать им поддержку в определении проблем и принятии решений.
- Создание условий для взаимопомощи.
- Понимание и эмпатия по отношению к другим.
- Стимулирование и содействие развитию команд и каждого отдельного участника.
- Коучинг людей с помощью сильных вопросов против применения власти.
- Мышление за рамками ежедневной деятельности; применение системного мышления.
- Поддержка обязательств команд и поездов.
- Открытость и поддержка открытости в других.
Точно так же, как существуют модели трансформации Lean-Agile для функции Lean Portfolio Management (LPM), существуют также модели трансформации для традиционного менеджера, который становится лидером Lean-Agile. Состояния «от» и «до»:
- От управления деятельностью команды и внесения вклада до обучения команд сотрудничеству.
- От фокусирования на сроках до достижения целей.
- От погони за конкретными результатами до инвестирования в общую эффективность команды.
- От представления ответа до обращения за ответом к командам и ARTs.
- От руководства до предоставления командам возможности самоорганизовываться и добиваться успеха.
- От решения проблем до содействия другим в их решениях.
Наряду с Solution Management и Solution Architect, Solution Train Engineer является одной из трех основных ролей в Solution Train. Большая часть функций STE заключается в построении отношений внутри и вне Solution Train. Это помогает установить важную «связь» между заинтересованными лицами, ARTs и командами. STE обеспечивает высокую производительность группы за счет:
- Помощи Solution Train в подготовке и проведении PI Planning.
- Координации поставки крупных решений.
- Измерения и изучения способов улучшения и достижения лучших результатов.
Solution Train Engineer подает пример, помогая развивать Lean-Agile и системное мышление, чтобы провести необходимые изменения, которые обеспечивают повышение производительности.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
Стать пионером трансформации в компании, кратно увеличить объем продаж, вдохновляя своим успехом другие команды, и разрешить себе мечтать о «космосе»: история успешной Agile-трансформации в интервью с Сергеем Нечушкиным, директором департамента малого и среднего бизнеса Абсолют Банка.
В статье рассмотрим Lean Portfolio Management — одну из 7-ми ключевых компетенций, необходимых для достижения Бизнес-гибкости (Business Agility).
Статья с детальным обзором состава и механизма работы портфеля SAFe®. Содержит различные примеры организации портфелей для крупного и малого бизнеса, а также их плюсы и минусы