Scaled Agile Framework, SAFe — фреймворк Agile-разработки, разработанный Scaled Agile Inc., по сути база знаний по реализации бережливой Agile-разработки в корпоративных масштабах. Ниже вольный пересказ оригинальной статьи «PI Planning — Scaled Agile Framework».
Сессия PI-планирования на 190 участников
Один из принципов Agile-манифеста говорит, что «непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды». Это несложно осуществить, если у вас одна небольшая команда. А как быть в масштабах огромной компании, когда команд много и необходима их синхронная работа? Для этого в Scaled Agile Framework (SAFe) используется инструмент PI-планирование (PI Planning) — это практика прямого общения всех команд, представителей бизнеса и других заинтересованных лиц, которые как бы объединяются в одну большую команду — Agile Release Train (ART).
Общение проходит на регулярных встречах со стандартной повесткой: в начале презентация представителей бизнеса с рассказом о текущей ситуации, стратегии и задачах, затем сессия планирования, когда команды создают план реализации инкремента продукта, создаваемого в рамках программы — Program Increment (PI). Сразу оговоримся: в терминологии SAFe для обозначения большого количества взаимосвязанных между собой команд используется термин «программа», в дальнейшем мы будем его придерживаться. В этой сессии принимают участие все члены ART, насколько это возможно. Для фасилитации таких встреч выделена специальная роль — Release Train Engineer (RTE). Он же отвечает за эскалацию блокеров, помогает в управлении рисками, поставке ценности и непрерывном совершенствовании.
Для подобных мероприятий по планированию, исследованиям и обучению предусмотрена специальная IP-итерация (Innovation and Planning iteration), чтобы не занимать время команд на других итерациях внутри PI. Сессия длится от 1,5 до 2 дней. Результатом является согласованный набор целей программы на следующий PI.
Географически-распределенные ART проводят эту встречу одновременно в разных местах, но поддерживают между собой постоянную связь.
PI-планирование важно проводить регулярно, ведь оно задает ритм работы всего ART. Это неотъемлемая часть SAFe: если вы не проводите PI-планирование, вы не применяете SAFe.
Сессия PI-планирования на 250 участников
PI-планирование предоставляет бизнесу множество преимуществ:
К сессии готовятся следующие материалы: дорожная карта, концепция, топ-10 приоритетных фич из бэклога программы и другие артефакты для передачи бизнес-контекста.
Основными результатами PI-планирования являются:
PI-планирование — важное событие, которое требует подготовки, координации и коммуникации. Участники мероприятия: продуктовые менеджеры, Agile-команды, архитекторы и инженеры, системные команды, заинтересованные лица — все они должны быть заранее оповещены и прийти на мероприятие хорошо подготовленными.
Успешное мероприятие готовится по следующим направлениям:
Ниже приводится описание подготовки по каждому направлению.
Важно убедиться, что у программы есть стратегия, которая будет понятна участникам мероприятия, включая заинтересованных лиц и представителей от бизнеса, что работа команд соответствует этой стратегии, что в ART есть люди на всех ключевых ролях.
Ниже примеры вопросов, которые помогают определить эту готовность.
Не менее важно правильно донести концепцию и бизнес-контекст, поэтому на сессии должны присутствовать все необходимые заинтересованные лица. Для этого PI-планирование включает следующие активности:
Подготовить место проведения и техническую инфраструктуру мероприятия с большим количеством участников не так просто, особенно если есть удаленные участники.
Ниже приведены моменты, которые следует учесть.
В целом мероприятие соответствует стандартной повестке, которая показана ниже. Далее мы рассмотрим каждый блок мероприятия подробнее.
Стандартная повестка 2-дневной сессии PI-планирования
Топ-менеджер или владелец бизнеса описывает текущее состояние бизнеса и то, насколько хорошо текущие решения в перспективе будут удовлетворять потребности клиентов.
Продуктовые менеджеры презентуют текущую концепцию программы, обычно рассказывая про важнейшие 10 предстоящих к реализации фич, про изменения с предыдущего PI-планирования, а также про любые грядущие вехи.
Системный архитектор представляет архитектурную концепцию. Кроме того, старший менеджер разработки может рассказать про изменения в практиках Agile-разработки, к примеру, автоматизации тестирования и непрерывной интеграции, которые нужно учитывать в течение следующего PI.
Ведущий — RTE — объясняет процесс планирования и ожидаемые результаты от мероприятия.
Ведущий объясняет цели и план сессии PI-планирования на 100 человек
Команды для каждой итерации оценивают объем работ, которые они смогут выполнить (емкость) и определяют элементы бэклога, которые, скорее всего, необходимы для реализации фич. Каждая команда создает черновики планов, которые видны всем остальным участникам, итерацию за итерацией. В это время они выявляют риски и зависимости, определяют черновик целей команды на PI. Также команда добавляет фичи на доску программы.
Команды выявляют взаимозависимости на сессии PI-планирования на 100 человек
Рецензирование планов происходит со строгими ограничениями по времени выступления каждой команды. В это время команды представляют основные результаты планирования: черновик целей, потенциальные риски и зависимости. Представители от бизнеса, продуктовые менеджеры, остальные команды и заинтересованные лица задают вопросы и дают обратную связь.
Владелец продукта презентует собранный ее командой план на сессии PI-планирования на 100 человек
Вероятно, планы необходимо будет доработать с учетом ожидаемого объема работ, ограниченности ресурсов и выявленных зависимостей. Во время этой встречи руководство согласовывает объем работ и устраняет недочеты в планах. RTE ведет встречу с участием всех ключевых заинтересованных лиц до тех пор, пока ими не будут определены достижимые цели.
На следующий день мероприятие начинается с того, что руководство описывает все изменения в планируемом объеме работ и ресурсах.
Команды продолжают планирование на основе результатов предыдущего дня, внося необходимые изменения. Они финализирует свои цели на PI, а представители от бизнеса оценивают бизнес-ценность этих целей.
Результаты планирования одной из команд на сессии PI-планирования на 100 человек
Все команды кратко презентуют свои планы. В конце выступления каждой команды озвучиваются риски и блокеры, однако обсуждать и искать решения в этот столь короткий промежуток времени командам не разрешается. Если план принимается заказчиками, то команда вывешивает флипчарты со своими целями на PI и рисками на самое видное место, чтобы все могли видеть в реальном режиме времени формирование совокупных целей программы.
Во время планирования команды обнаруживают критические риски и блокеры на уровне всей программы, которые могут повлиять на возможность решения командами своих задач. Эти вопросы рассматриваются всеми участниками. Все риски, один за другим, четко, честно и открыто классифицируются по следующим группам:
Риски программы на сессии PI-планирования на 100 человек
После того, как были рассмотрены риски программы, команды голосуют за реалистичность и готовность взять на себя ответственность за достижения этих целей программы на PI. Все члены команд поднимают руку, показывая от одного до пяти пальцев.
Правила голосования на сессии PI-планирования на 100 человек
Если по всем командам в среднем подняты три или четыре пальца, то руководство может принять такие обязательства. Если же в среднем меньше трех пальцев, то в план вносятся необходимые изменения и все планы перерабатываются. Каждый, кто поднимает два или меньше пальцев, должен высказать свои опасения. Это позволяет или идентифицировать новый риск, требующий перепланирования, или просто донести до всех важную информацию.
Голосование на репетиции с участием Скрам-мастеров и владельцев продуктов команд перед сессией PI-планирования на 100 человек
При необходимости команды перерабатывают свои планы до тех пор, пока уровень доверия им не окажется достаточным. Это первый момент за всю сессию PI-планирования, когда временные ограничения уходят на второй план — важнее согласованность планов и готовность команд взять на себя ответственность за их исполнение.
В завершение RTE проводит короткую ретроспективную сессию, чтобы определить, что получилось хорошо, что не очень и что можно сделать лучше на следующей сессии PI-планирования.
После этого можно обсудить дальнейшие шаги, занести цели и пользовательские истории в IT-инструменты управления Agile-проектами, запланировать предстоящие ключевые активности и мероприятия… и даже прибраться в помещении!
Успешное PI-планирование позволяет получить три основных артефакта.
В этом видео наша практика PI-планирования:
PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.
Сессия PI-планирования на 190 участников
Содержание
Задачи по разработке продукта невозможно заранее предугадать. Передайте планирование и отслеживание тем, кто может оценить конечный результат и влиять на то, каким он будет.
— Michael Kennedy, «Product Development for the Lean Enterprise»
В SAFe нет никакого волшебства… разве что только PI-планирование.
— Авторы SAFe
Один из принципов Agile-манифеста говорит, что «непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды». Это несложно осуществить, если у вас одна небольшая команда. А как быть в масштабах огромной компании, когда команд много и необходима их синхронная работа? Для этого в Scaled Agile Framework (SAFe) используется инструмент PI-планирование (PI Planning) — это практика прямого общения всех команд, представителей бизнеса и других заинтересованных лиц, которые как бы объединяются в одну большую команду — Agile Release Train (ART).
Общение проходит на регулярных встречах со стандартной повесткой: в начале презентация представителей бизнеса с рассказом о текущей ситуации, стратегии и задачах, затем сессия планирования, когда команды создают план реализации инкремента продукта, создаваемого в рамках программы — Program Increment (PI). Сразу оговоримся: в терминологии SAFe для обозначения большого количества взаимосвязанных между собой команд используется термин «программа», в дальнейшем мы будем его придерживаться. В этой сессии принимают участие все члены ART, насколько это возможно. Для фасилитации таких встреч выделена специальная роль — Release Train Engineer (RTE). Он же отвечает за эскалацию блокеров, помогает в управлении рисками, поставке ценности и непрерывном совершенствовании.
Для подобных мероприятий по планированию, исследованиям и обучению предусмотрена специальная IP-итерация (Innovation and Planning iteration), чтобы не занимать время команд на других итерациях внутри PI. Сессия длится от 1,5 до 2 дней. Результатом является согласованный набор целей программы на следующий PI.
Географически-распределенные ART проводят эту встречу одновременно в разных местах, но поддерживают между собой постоянную связь.
Обзор
PI-планирование важно проводить регулярно, ведь оно задает ритм работы всего ART. Это неотъемлемая часть SAFe: если вы не проводите PI-планирование, вы не применяете SAFe.
Сессия PI-планирования на 250 участников
PI-планирование предоставляет бизнесу множество преимуществ:
- Внутри ART налаживается деловое общение, ведь многие из тех, кому нужно делать совместные проекты, впервые знакомятся вживую.
- Обеспечивается высокая эффективность коммуникации между всеми членами команд и заинтересованными лицами. Проще говоря, если собрать много людей вместе и дать им цель, то это приводит к необычайной энергетике общения. Проверено на нашем опыте! (прим. переводчика)
- Бизнес-заказчики и разработчики наконец-то слышат друг друга и начинают действовать слаженно в соответствии с целями бизнеса.
- Команды начинают видеть «картинку в целом», выявляются зависимости, что подталкивает команды к координации между собой и другими ART.
- Команды выбирают только необходимый минимум требований к архитектуре и пользовательскому интерфейсу. Это позволит уложиться в запланированные сроки и «не наворачивать» избыточный функционал.
- Объем работ планируется с учетом емкости команд, за счет чего устраняется избыток незавершенной работы.
- Форсируется принятие решений.
К сессии готовятся следующие материалы: дорожная карта, концепция, топ-10 приоритетных фич из бэклога программы и другие артефакты для передачи бизнес-контекста.
Основными результатами PI-планирования являются:
- Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. Каждая цель оценена с точки зрения значимости для бизнеса. Цели всех команд объединены в набор целей всей программы на PI.
- Доска программы, на которой показаны новые фичи, ожидаемые сроки их реализации и любые другие вехи, с которыми связаны цели команд.
- Общее согласие с реалистичностью и готовность взять на себя ответственность за достижения этих целей.
Подготовка
PI-планирование — важное событие, которое требует подготовки, координации и коммуникации. Участники мероприятия: продуктовые менеджеры, Agile-команды, архитекторы и инженеры, системные команды, заинтересованные лица — все они должны быть заранее оповещены и прийти на мероприятие хорошо подготовленными.
Успешное мероприятие готовится по следующим направлениям:
- Организация: согласованность бизнеса и разработки по стратегии, готовность команд и всего ART.
- Содержание: подготовленность менеджмента и разработчиков.
- Инфраструктура: место проведения и логистика мероприятия.
Ниже приводится описание подготовки по каждому направлению.
Организация
Важно убедиться, что у программы есть стратегия, которая будет понятна участникам мероприятия, включая заинтересованных лиц и представителей от бизнеса, что работа команд соответствует этой стратегии, что в ART есть люди на всех ключевых ролях.
Ниже примеры вопросов, которые помогают определить эту готовность.
- Объем работы и контекст планирования: «Понятны ли рамки планирования: продукта, системы, технологической области? Знаем ли мы, какие команды нужны для совместного планирования?»
- Согласованность бизнеса: «Согласованы ли приоритеты между представителями от бизнеса?»
- Agile-команды: «Есть ли у нас Agile-команды? Все ли команды укомплектованы разработчиками и тестировщиками? Везде ли определены Скрам-мастер и владелец продукта?»
Содержание
Не менее важно правильно донести концепцию и бизнес-контекст, поэтому на сессии должны присутствовать все необходимые заинтересованные лица. Для этого PI-планирование включает следующие активности:
- Обзор текущего бизнес-контекста от топ-менеджмента.
- Обзор продуктовой концепции, который готовят продуктовые менеджеры на основе топ-10 приоритетных фич из бэклога программы.
- Обзор архитектурной концепции обычно представляет технический директор или архитектор, чтобы рассказать о технологических новинках для поддержки реализации фич, а также о нефункциональных требованиях.
Инфраструктура
Подготовить место проведения и техническую инфраструктуру мероприятия с большим количеством участников не так просто, особенно если есть удаленные участники.
Ниже приведены моменты, которые следует учесть.
- Пространство: в помещении должно быть достаточно просторно для всех участников, включая места для перерывов при необходимости.
- Техническая поддержка: заранее определите людей, которые будут помогать вам с настройкой, тестированием и решением проблем с технической инфраструктурой на мероприятии.
- Каналы связи: распределенные сессии планирования требуют наличия основных и резервных каналов трансляции аудио, видео и презентаций.
Повестка
В целом мероприятие соответствует стандартной повестке, которая показана ниже. Далее мы рассмотрим каждый блок мероприятия подробнее.
Стандартная повестка 2-дневной сессии PI-планирования
День 1
Бизнес-контекст
Топ-менеджер или владелец бизнеса описывает текущее состояние бизнеса и то, насколько хорошо текущие решения в перспективе будут удовлетворять потребности клиентов.
Концепция продукта
Продуктовые менеджеры презентуют текущую концепцию программы, обычно рассказывая про важнейшие 10 предстоящих к реализации фич, про изменения с предыдущего PI-планирования, а также про любые грядущие вехи.
Архитектура и практики разработки
Системный архитектор представляет архитектурную концепцию. Кроме того, старший менеджер разработки может рассказать про изменения в практиках Agile-разработки, к примеру, автоматизации тестирования и непрерывной интеграции, которые нужно учитывать в течение следующего PI.
Контекст планирования
Ведущий — RTE — объясняет процесс планирования и ожидаемые результаты от мероприятия.
Ведущий объясняет цели и план сессии PI-планирования на 100 человек
Работа команд — 1
Команды для каждой итерации оценивают объем работ, которые они смогут выполнить (емкость) и определяют элементы бэклога, которые, скорее всего, необходимы для реализации фич. Каждая команда создает черновики планов, которые видны всем остальным участникам, итерацию за итерацией. В это время они выявляют риски и зависимости, определяют черновик целей команды на PI. Также команда добавляет фичи на доску программы.
Команды выявляют взаимозависимости на сессии PI-планирования на 100 человек
Рецензирование черновиков планов
Рецензирование планов происходит со строгими ограничениями по времени выступления каждой команды. В это время команды представляют основные результаты планирования: черновик целей, потенциальные риски и зависимости. Представители от бизнеса, продуктовые менеджеры, остальные команды и заинтересованные лица задают вопросы и дают обратную связь.
Владелец продукта презентует собранный ее командой план на сессии PI-планирования на 100 человек
Рецензирование руководством и решение проблем
Вероятно, планы необходимо будет доработать с учетом ожидаемого объема работ, ограниченности ресурсов и выявленных зависимостей. Во время этой встречи руководство согласовывает объем работ и устраняет недочеты в планах. RTE ведет встречу с участием всех ключевых заинтересованных лиц до тех пор, пока ими не будут определены достижимые цели.
День 2
Изменение планов
На следующий день мероприятие начинается с того, что руководство описывает все изменения в планируемом объеме работ и ресурсах.
Работа команд — 2
Команды продолжают планирование на основе результатов предыдущего дня, внося необходимые изменения. Они финализирует свои цели на PI, а представители от бизнеса оценивают бизнес-ценность этих целей.
Результаты планирования одной из команд на сессии PI-планирования на 100 человек
Презентация итоговых планов
Все команды кратко презентуют свои планы. В конце выступления каждой команды озвучиваются риски и блокеры, однако обсуждать и искать решения в этот столь короткий промежуток времени командам не разрешается. Если план принимается заказчиками, то команда вывешивает флипчарты со своими целями на PI и рисками на самое видное место, чтобы все могли видеть в реальном режиме времени формирование совокупных целей программы.
Риски программы
Во время планирования команды обнаруживают критические риски и блокеры на уровне всей программы, которые могут повлиять на возможность решения командами своих задач. Эти вопросы рассматриваются всеми участниками. Все риски, один за другим, четко, честно и открыто классифицируются по следующим группам:
- Resolved — команда согласилась, что проблема больше не актуальна;
- Owned — вопрос не может быть решен на мероприятии, но кто-то согласился продвигать разрешение этого вопроса далее;
- Accepted — некоторые риски являются фактами или потенциальными событиями, которые просто должны быть всеми поняты и учтены в дальнейшей работе;
- Mitigated — команда может определить план по устранению последствий данного риска или блокера.
Риски программы на сессии PI-планирования на 100 человек
Голосование
После того, как были рассмотрены риски программы, команды голосуют за реалистичность и готовность взять на себя ответственность за достижения этих целей программы на PI. Все члены команд поднимают руку, показывая от одного до пяти пальцев.
Правила голосования на сессии PI-планирования на 100 человек
Если по всем командам в среднем подняты три или четыре пальца, то руководство может принять такие обязательства. Если же в среднем меньше трех пальцев, то в план вносятся необходимые изменения и все планы перерабатываются. Каждый, кто поднимает два или меньше пальцев, должен высказать свои опасения. Это позволяет или идентифицировать новый риск, требующий перепланирования, или просто донести до всех важную информацию.
Голосование на репетиции с участием Скрам-мастеров и владельцев продуктов команд перед сессией PI-планирования на 100 человек
Переделка планов, если нужно
При необходимости команды перерабатывают свои планы до тех пор, пока уровень доверия им не окажется достаточным. Это первый момент за всю сессию PI-планирования, когда временные ограничения уходят на второй план — важнее согласованность планов и готовность команд взять на себя ответственность за их исполнение.
Ретроспектива
В завершение RTE проводит короткую ретроспективную сессию, чтобы определить, что получилось хорошо, что не очень и что можно сделать лучше на следующей сессии PI-планирования.
После этого можно обсудить дальнейшие шаги, занести цели и пользовательские истории в IT-инструменты управления Agile-проектами, запланировать предстоящие ключевые активности и мероприятия… и даже прибраться в помещении!
Результаты
Успешное PI-планирование позволяет получить три основных артефакта.
- Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. По каждой цели представителями от бизнеса определена оценка ее бизнес-ценности.
- Доска программы, на которой видны сроки поставки новых фич, зависимости между командами и зависимости от других ART, а также важные вехи.
Доска программы одного ART
- Согласие всех команд ART с реалистичностью целей PI и их готовность взять на себя ответственность за достижение этих целей.
Практика
В этом видео наша практика PI-планирования:
PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.
