Подготовка к запуску первого поезда — внедрение SAFe®

Вольный перевод статьи Prepare for ART Launch — Scaled Agile Framework.

Быстрые победы помогают создать необходимый импульс. — Коттер

Это седьмая статья из серии «Дорожная карта внедрения SAFe®».

В предыдущих статьях этой серии описывались первые шесть шагов дорожной карты внедрения SAFe:

• Достижение переломного момента.
• Обучите агентов изменений Lean-Agile.
• Обучите руководителей, менеджеров и лидеров.
• Создайте центр экспертизы Lean-Agile (Lean-Agile Center of Excellence, LACE).
• Выявите потоки ценности и определите Agile Release Trains (ARTs).
• Создайте план внедрения.

На данный момент предприятие выявило и описало свои потоки поставки ценности и разработало план внедрения, который включает черновик описания первого Agile Release Train (ART). Это ключевой момент, так как планы пора начинать реализовывать. С точки зрения управления изменениями первый ART очень важен, он может иметь далеко идущие последствия. Его запуск станет первым видимым событием, существенным изменением в способе работы и принесет первые быстрые выгоды, которые помогут предприятию набрать обороты. В этой статье описаны действия, необходимые для подготовки к запуску ART.

Настало время выполнить действия, необходимые для успешного запуска ART. SPCs (SAFe Program Consultants) часто возглавляют ввод в работу первых ARTs при поддержке заинтересованных лиц, прошедших обучение SAFe, и сотрудников центра экспертизы Lean-Agile (LACE).

Кто бы ни руководил процессом, масштабные мероприятия по подготовке к запуску ART включают:

• Определение ART.
• Определение даты запуска и циклов календаря программы.
• Обучение руководителей и заинтересованных лиц ART.
• Формирование Agile-команд.
• Обучение продуктовых менеджеров (Product Managers, PMs) и владельцев продукта (Product Owners, POs).
• Обучение Scrum-мастеров (Scrum Masters, SMs).
• Обучение системных архитекторов/инженеров (System Architects/Engineers).
• Оценка готовности к запуску.
• Подготовка бэклога программы (Program Backlog).

Каждое из этих действий описано в следующих разделах.

Определение ART

В статье «Создайте план внедрения» описано, как заинтересованных лиц вовлекают в выявление и описание первого потока создания ценности и определение ART. На этом этапе планирования ART определялся стой степенью детализации, которой было достаточно, чтобы выбрать потенциально готовый к запуску поезд. Однако, параметры и границы ART были оставлены на усмотрение тех, кто лучше понимает локальный контекст.

Ключевым достоинством карточки является помощь командам в определении ключевых ролей в ART. Поезд едет только тогда, когда правильным людям поручают правильные обязанности. Ведь организация ART – это система. Чтобы система функционировала должным образом, все необходимые для этого обязанности по определению решения, созданию, проверке и развертыванию должны быть на кого-то возложены. Заполнение поля ключевых ролей на карточке способствует соответствующим обсуждениям и подчеркивает новые обязанности.

Чтобы понять, кто такие представители бизнеса (Business Owners, BO), следует проявить особую тщательность. Понятно, что к ним нужно отнести внутренних и внешних клиентов и/или их доверенных лиц в части продуктового менеджмента. Однако, «применение системного подхода» означает, что часто в эту категорию, помимо перечисленных ранее, следует включать, например, вице-президента по развитию/технологиям, руководителей дата-центров, корпоративных архитекторов и архитекторов систем безопасности, а также руководителей в области маркетинга и продаж. Только правильно определенный круг представителей бизнеса способен помочь коллективно согласовать различные организационные обязанности и точки зрения.

Определение даты запуска и циклов календаря программы

Имея на руках определение ART, следующим шагом нужно определить дату первого PI-планирования (Program Increment Planning). Появление конкретной даты запуска послужит «принуждающей функцией», опираясь на которую придется определить весь плановый график.

Первый шаг — установить длительность выполнения циклов, включая PI (Program Increment, Инкремент Программы) и длину итерации. На общей картине SAFe (SAFe Big Picture) нарисован 10-недельный цикл PI, состоящий из 4 последовательных итераций и одной Итерации Инноваций и Планирования (Innovation and Planning Iteration, IP Iteration). Не существует фиксированного правила для цикла PI или того, сколько времени должно быть зарезервировано для итерации IP. Рекомендуемая продолжительность PI составляет от 8 до 12 недель с уклоном в сторону меньшей продолжительности (например, 10 недель). Выбранная частота вращения педалей должна оставаться стабильной и не должна произвольно меняться от одного PI к другому. Это позволяет ART иметь предсказуемый ритм и скорость. Фиксированный ритм также позволяет людям в своих календарях планировать мероприятия на целый год вперед. Календарь PI обычно включает следующие действия:

• PI-планирование.
• Системные демонстрации (System Demos).
• Синхронизация ART (ART Sync) или отдельные мероприятия Scrum-of-Scrum и PO Sync.
• Сессия Инспекции и Адаптации (Inspect and Adapt, I&A).

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

Обучение руководителей и заинтересованных лиц ART

В зависимости от масштаба и сроков развертывания, в ART может быть несколько руководителей: Release Train Engineer (RTE), продуктовых менеджеров, системных архитекторов, и несколько заинтересованных лиц: представители бизнеса, менеджеры, внутренние поставщики, эксплуатация и прочие, которые не присутствовали на тренинге Leading SAFe. Скорее всего, они будут иметь поверхностное представление  или будут вовсе незнакомы с SAFe, им будет непонятно, чего ожидать от этой методики, они могут не понимать необходимости и пользы от своего участия. Важно, чтобы они понимали и поддерживали общую модель, а также выполняли свои обязанности. В подобных случаях SPCs часто организуют тренинг Leading SAFe для обучения этих заинтересованных лиц и мотивации их участия. За этим часто следует однодневный тренинг по планированию внедрения, на котором недавно обученные заинтересованные лица и SPC могут уточнить особенности плана запуска. В конце концов, это их «поезд»: только они могут планировать и достигать наилучших результатов. По сути это передача основной ответственности за изменение от агентов изменений заинтересованным лицам недавно сформированного ART.

Организация Agile-команд с использованием топологии команд

Хороший дизайн Agile-команд является одним из основных факторов, способствующих успеху ART в достижении цели непрерывной поставки ценности клиентам. Независимо от того, организован ли сам ART вокруг потока ценности, если команды, работающие в этом ART, останутся разобщенными и будут отсиживаться каждая в своем бункере, то «поезду» будет сложно достичь своей цели.

Чтобы помочь с этим, SAFe предлагает топологию, состоящую из четырех типов команд (из работы Мэтью Скелтона и Мануэля Паиса). Эти четыре основных типа команд улучшают и упрощают задачу организации вокруг ценности:

1. Потоковая команда — организована вокруг потока работы и имеет возможность доставлять ценность непосредственно клиенту или конечному пользователю.
2. Команда сложных подсистем – организована вокруг конкретных подсистем, требующих глубоких специальных навыков и опыта.
3. Платформенная команда — организована вокруг разработки и поддержки платформы, предоставляющей услуги другим командам.
4. Вспомогательная команда — организована для оказания помощи другим командам со специализированными возможностями и помощи им в овладении новыми технологиями. В ней сосредоточены первопроходцы, осваивающие новые инструменты, технологии и расчищающие путь для идущих следом.

Подробнее см. в статье: Масштабирование по SAFe®: как собрать АRT из команд разных типов.

Формирование Agile-команд

Следующим шагом будет формирование Agile-команд, которые будут «ехать» на запускаемом поезде. Одно из решений состоит в том, чтобы позволить сотрудникам ART организоваться в Agile-команды с минимальными ограничениями (см. подробнее в статье Самодизайн команд). В других случаях разработчики уже использовали методы командной разработки и предпочтут оставить всё примерно так, как им привычно. Руководство может сделать первоначальный выбор на основе своих целей, знаний об индивидуальных талантах и стремлениях, времени и других факторов. В большинстве случаев потребуется некоторое взаимодействие между руководством компании и командами. Команды лучше понимают свой конкретный контекст и знают, как им нравится работать. Менеджеры добавляют точку зрения на основе текущих индивидуальных, организационных и продуктовых стратегий разработки.

Перед PI-планированием все специалисты уже должны стать частью кросс-функциональных Agile-команд. Также должны быть назначены первые исполнители ролей Scrum Master и Product Owner.

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

Простое заполнение списка может оказаться весьма информативным, так как оно начинает конкретизировать абстрактные концепции Agile-разработки. В конце концов, структура Agile-команды довольно четко определена; а вот вопрос о том, кто в какую команду входит, и о характере специальных ролей может привести к интересным дискуссиям. Даже, казалось бы, простое назначение человека в одну Agile-команду может стать поучительным опытом. Но пути назад нет. Доказанные модели успеха Agile, в том числе, принцип «один человек — одна команда», довольно ясны.

Столбец географического местоположения также интересен, так как он определяет уровень размещения на одной площадке и распределенности в каждой команде. Конечно, предпочтительно, когда команда размещена на одной площадке. Но нередки случаи, когда один или несколько человек не могут быть физически совмещены с другими географически. Ситуация может измениться со временем в одну или в другую сторону, но, по крайней мере, на момент формирования команд все понимают, где сейчас проживают члены команды, поэтому они могут начать думать о времени и форме проведения ежедневного стендапа и других командных мероприятий. В список большинства трансформируемых команд дополнительно включают имя и контактную информацию непосредственного руководителя каждого члена ART (у каждого сотрудника есть свой непосредственный руководитель, независимо от того, будет он взят в ART или нет), чтобы обеспечить упреждающую связь и координацию с этими руководителями до объявления изменений (их также следует пригласить на тренинг Leading SAFe!).

Если вы дочитали до этого абзаца, то точно любите полезный контент про современные практики управления. Еще больше материалов, видео и экспертных советов от Agile-коучей, анонсы бесплатных вебинаров и митапов в Телеграм-канале ScrumTrek

Обучение продуктовых менеджеров и владельцев продукта

Продуктовые менеджеры и владельцы продукта управляют поездом совместно. У них есть власть над контентом, соответственно, над фичами и историями. Эти две роли имеют решающее значение для успеха ART, и люди, выполняющие эти роли, должны быть хорошо обучены, чтобы обеспечить эффективное сотрудничество, изучить новый способ работы и понять, как лучше всего выполнять свои конкретные обязанности. Кроме того, эти роли будут в значительной степени отвечать за создание начального бэклога, который является ключевым артефактом для PI-планирования.

Специально для этой цели разработан двухдневный тренинг SAFe Product Owner/Product Manager. Тренинг учит владельцев продуктов и продуктовых менеджеров (менеджеров решений), как управлять созданием ценности на предприятии, придерживающемся SAFe. Участники получают обзор мышления Lean-Agile и принципов SAFe, а также подробно изучают практики для конкретных ролей. Участники узнают, как определять эпики, фичи и пользовательские истории, как проектировать Kanban-системы для команд и программ для управления потоком работы, а также как управлять незавершенными работами и расставлять приоритеты с помощью методики «Более Ценная и Короткая Работа Сначала» (Weighted Shortest Job First, WSJF).

Обучение Scrum-мастеров

Эффективные ART в значительной степени полагаются на лидерство Scrum-мастера, его способность обучать членов Agile-команды и повышать производительность команды. Это особая роль, которая включает в себя традиционные обязанности лидера Scrum, а также обязанности перед более крупной командой Agile-команд — ART. В SAFe Scrum-мастера также играют решающую роль в PI-планировании и помогают координировать поставку ценности через мероприятия Scrum-of-Scrums. Очевидно, что было бы невероятно полезно, если бы они прошли соответствующее обучение до начала первого PI.

Двухдневный тренинг SAFe Scrum Master обучает основам Scrum, а также исследует роль Scrum в контексте SAFe. Он готовит Scrum-мастеров к тому, как способствовать успеху командных итераций, как успешно планировать и выполнять PI, как участвовать в мероприятиях ART, а также как измерять и улучшать поток работы в системе с помощью Kanban. Этот курс полезен как для новых, так и для опытных Scrum-мастеров.

Обучение системных архитекторов/инженеров

Системные архитекторы/инженеры поддерживают разработку решений, предоставляя, сообщая и развивая более широкую технологию и архитектурное представление решения. При этом они позволяют Agile-командам принимать эффективные децентрализованные решения, которые ускоряют создание ценности для бизнеса, обеспечивая при этом надежность и устойчивость архитектуры решения. Сотрудники, выполняющие эти роли, должны быть не только опытными техническими экспертами, но и эффективными лидерами Lean-Agile, способными взаимодействовать со всей организацией. Во взаимодействии с продуктовым менеджментом эта роль берет на себя, определяет и владеет Enabler-фичами в бэклоге, предназначенными для поддержания архитектурной полосы, необходимой для обеспечения возможности создания ценности для бизнеса.

Трехдневный тренинг SAFe System and Solution Architect знакомит старших технических специалистов с ролью архитектуры в предприятии Lean-Agile. Участники изучат принципы, лежащие в основе архитектуры Lean-Agile и Релиза по Запросу, научатся руководить и поддерживать Solution Train и Agile Release Train, распространят принципы непрерывного потока на большие «системы систем» и узнают, как обеспечить более качественный поток ценности через весь портфель в целом.

Оценка готовности к запуску

Обучение людей их новым ролям и обязанностям является ключевой частью готовности к запуску ART, но это только один из элементов успешного запуска. Необходимы дополнительные мероприятия. Однако, поскольку SAFe основан на эмпирической модели Планирование-Выполнение-Проверка-Корректировка (Plan-Do-Check-Adjust, PDCA), идеальной готовности к запуску не существует. Даже попытка достичь такого состояния — довольно дурацкая затея, поскольку опыт первого PI будет формировать ваши будущие действия. Более того, попытки быть слишком идеальными заранее задерживают обучение, откладывая трансформацию и реализацию ее преимуществ.

Тем не менее, определенная степень готовности поможет обеспечить более успешное мероприятие по планированию с первого раза.

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

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

Подготовка бэклога программы

Как упоминалось ранее, использование даты запуска в качестве принуждающей функции заставляет ускоряться с определением объема работ и концепции для PI. Конечно, никому не хочется появляться на сессии PI-планирования без четкого понимания цели этого PI. Было бы заманчиво предположить, что цель должна быть определена до начала сессии, опыт зачастую показывает обратное. Более вероятно, что будет несколько мнений о том, что же должна делать новая система, и может потребоваться некоторое время, чтобы свести воедино эти точки зрения до даты запуска.

Границы работ в рамках PI, или «то, что будет построено», в значительной степени определяется бэклогом, то есть журналом невыполненных работ, который содержит набор будущих фич, нефункциональных требований и архитектурных работ, которые определяют будущее поведение системы. Чтобы определить объем работ, SPCs и заинтересованные лица LACE зачастую могут поспособствовать сведению заинтересованных сторон ART для подготовки единого бэклога. Обычно это делается в ходе серии совещаний по уточнению бэклога и других мероприятий.

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

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.