Подготовка к запуску первого поезда — внедрение 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!).

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

Продуктовые менеджеры и владельцы продукта управляют поездом совместно. У них есть власть над контентом, соответственно, над фичами и историями. Эти две роли имеют решающее значение для успеха 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.