Все статьи
PI-планирование в SAFe®
Дата: 17.01.2017
Scaled Agile Framework® (SAFe®) — фреймворк Agile-разработки, разработанный Scaled Agile, по сути база знаний по реализации бережливой Agile-разработки в корпоративных масштабах.
Задачи по разработке продукта невозможно заранее предугадать. Передайте планирование и отслеживание тем, кто может оценить конечный результат и влиять на то, каким он будет.
В SAFe нет никакого волшебства… разве что только PI-планирование.
Один из принципов 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-планирование предоставляет бизнесу множество преимуществ:
- Внутри ART налаживается деловое общение, ведь многие из тех, кому нужно делать совместные проекты, впервые знакомятся вживую.
- Обеспечивается высокая эффективность коммуникации между всеми членами команд и заинтересованными лицами. Проще говоря, если собрать много людей вместе и дать им цель, то это приводит к необычайной энергетике общения. Проверено на нашем опыте! (прим. переводчика)
- Бизнес-заказчики и разработчики наконец-то слышат друг друга и начинают действовать слаженно в соответствии с целями бизнеса.
- Команды начинают видеть «картинку в целом», выявляются зависимости, что подталкивает команды к координации между собой и другими ART.
- Команды выбирают только необходимый минимум требований к архитектуре и пользовательскому интерфейсу. Это позволит уложиться в запланированные сроки и «не наворачивать» избыточный функционал.
- Объем работ планируется с учетом емкости команд, за счет чего устраняется избыток незавершенной работы.
- Форсируется принятие решений.
К сессии готовятся следующие материалы: дорожная карта, концепция, топ-10 приоритетных фич из бэклога программы и другие артефакты для передачи бизнес-контекста.
Основными результатами PI-планирования являются:
- Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. Каждая цель оценена с точки зрения значимости для бизнеса. Цели всех команд объединены в набор целей всей программы на PI.
- Доска программы, на которой показаны новые фичи, ожидаемые сроки их реализации и любые другие вехи, с которыми связаны цели команд.
- Общее согласие с реалистичностью и готовность взять на себя ответственность за достижения этих целей.
Подготовка
PI-планирование — важное событие, которое требует подготовки, координации и коммуникации. Участники мероприятия: продуктовые менеджеры, Agile-команды, архитекторы и инженеры, системные команды, заинтересованные лица — все они должны быть заранее оповещены и прийти на мероприятие хорошо подготовленными.
Успешное мероприятие готовится по следующим направлениям:
- Организация: согласованность бизнеса и разработки по стратегии, готовность команд и всего ART.
- Содержание: подготовленность менеджмента и разработчиков.
- Инфраструктура: место проведения и логистика мероприятия.
Ниже приводится описание подготовки по каждому направлению.
Организация
Важно убедиться, что у программы есть стратегия, которая будет понятна участникам мероприятия, включая заинтересованных лиц и представителей от бизнеса, что работа команд соответствует этой стратегии, что в ART есть люди на всех ключевых ролях.
Ниже примеры вопросов, которые помогают определить эту готовность.
- Объем работы и контекст планирования: «Понятны ли рамки планирования: продукта, системы, технологической области? Знаем ли мы, какие команды нужны для совместного планирования?»
- Согласованность бизнеса: «Согласованы ли приоритеты между представителями от бизнеса?»
- Agile-команды: «Есть ли у нас Agile-команды? Все ли команды укомплектованы разработчиками и тестировщиками? Везде ли определены Скрам-мастер и владелец продукта?»
Содержание
Не менее важно правильно донести концепцию и бизнес-контекст, поэтому на сессии должны присутствовать все необходимые заинтересованные лица. Для этого PI-планирование включает следующие активности:
- Обзор текущего бизнес-контекста от топ-менеджмента.
- Обзор продуктовой концепции, который готовят продуктовые менеджеры на основе топ-10 приоритетных фич из бэклога программы.
- Обзор архитектурной концепции обычно представляет технический директор или архитектор, чтобы рассказать о технологических новинках для поддержки реализации фич, а также о нефункциональных требованиях.
Инфраструктура
Подготовить место проведения и техническую инфраструктуру мероприятия с большим количеством участников не так просто, особенно если есть удаленные участники.
Ниже приведены моменты, которые следует учесть.
- Пространство: в помещении должно быть достаточно просторно для всех участников, включая места для перерывов при необходимости.
- Техническая поддержка: заранее определите людей, которые будут помогать вам с настройкой, тестированием и решением проблем с технической инфраструктурой на мероприятии.
- Каналы связи: распределенные сессии планирования требуют наличия основных и резервных каналов трансляции аудио, видео и презентаций.
Повестка
В целом мероприятие соответствует стандартной повестке, которая показана ниже. Далее мы рассмотрим каждый блок мероприятия подробнее.
Стандартная повестка 2-дневной сессии PI-планирования
День 1
Топ-менеджер или владелец бизнеса описывает текущее состояние бизнеса и то, насколько хорошо текущие решения в перспективе будут удовлетворять потребности клиентов.
Продуктовые менеджеры презентуют текущую концепцию программы, обычно рассказывая про важнейшие 10 предстоящих к реализации фич, про изменения с предыдущего PI-планирования, а также про любые грядущие вехи.
Системный архитектор представляет архитектурную концепцию. Кроме того, старший менеджер разработки может рассказать про изменения в практиках Agile-разработки, к примеру, автоматизации тестирования и непрерывной интеграции, которые нужно учитывать в течение следующего PI.
Ведущий — RTE — объясняет процесс планирования и ожидаемые результаты от мероприятия.
Команды для каждой итерации оценивают объем работ, которые они смогут выполнить (емкость) и определяют элементы бэклога, которые, скорее всего, необходимы для реализации фич. Каждая команда создает черновики планов, которые видны всем остальным участникам, итерацию за итерацией. В это время они выявляют риски и зависимости, определяют черновик целей команды на PI. Также команда добавляет фичи на доску программы.
Рецензирование планов происходит со строгими ограничениями по времени выступления каждой команды. В это время команды представляют основные результаты планирования: черновик целей, потенциальные риски и зависимости. Представители от бизнеса, продуктовые менеджеры, остальные команды и заинтересованные лица задают вопросы и дают обратную связь.
Вероятно, планы необходимо будет доработать с учетом ожидаемого объема работ, ограниченности ресурсов и выявленных зависимостей. Во время этой встречи руководство согласовывает объем работ и устраняет недочеты в планах. RTE ведет встречу с участием всех ключевых заинтересованных лиц до тех пор, пока ими не будут определены достижимые цели.
День 2
На следующий день мероприятие начинается с того, что руководство описывает все изменения в планируемом объеме работ и ресурсах.
Команды продолжают планирование на основе результатов предыдущего дня, внося необходимые изменения. Они финализирует свои цели на PI, а представители от бизнеса оценивают бизнес-ценность этих целей.
Все команды кратко презентуют свои планы. В конце выступления каждой команды озвучиваются риски и блокеры, однако обсуждать и искать решения в этот столь короткий промежуток времени командам не разрешается. Если план принимается заказчиками, то команда вывешивает флипчарты со своими целями на PI и рисками на самое видное место, чтобы все могли видеть в реальном режиме времени формирование совокупных целей программы.
Во время планирования команды обнаруживают критические риски и блокеры на уровне всей программы, которые могут повлиять на возможность решения командами своих задач. Эти вопросы рассматриваются всеми участниками. Все риски, один за другим, четко, честно и открыто классифицируются по следующим группам:
- Resolved — команда согласилась, что проблема больше не актуальна;
- Owned — вопрос не может быть решен на мероприятии, но кто-то согласился продвигать разрешение этого вопроса далее;
- Accepted — некоторые риски являются фактами или потенциальными событиями, которые просто должны быть всеми поняты и учтены в дальнейшей работе;
- Mitigated — команда может определить план по устранению последствий данного риска или блокера.
После того, как были рассмотрены риски программы, команды голосуют за реалистичность и готовность взять на себя ответственность за достижения этих целей программы на PI. Все члены команд поднимают руку, показывая от одного до пяти пальцев.
Если по всем командам в среднем подняты три или четыре пальца, то руководство может принять такие обязательства. Если же в среднем меньше трех пальцев, то в план вносятся необходимые изменения и все планы перерабатываются. Каждый, кто поднимает два или меньше пальцев, должен высказать свои опасения. Это позволяет или идентифицировать новый риск, требующий перепланирования, или просто донести до всех важную информацию.
При необходимости команды перерабатывают свои планы до тех пор, пока уровень доверия им не окажется достаточным. Это первый момент за всю сессию PI-планирования, когда временные ограничения уходят на второй план — важнее согласованность планов и готовность команд взять на себя ответственность за их исполнение.
В завершение RTE проводит короткую ретроспективную сессию, чтобы определить, что получилось хорошо, что не очень и что можно сделать лучше на следующей сессии PI-планирования.
После этого можно обсудить дальнейшие шаги, занести цели и пользовательские истории в IT-инструменты управления Agile-проектами, запланировать предстоящие ключевые активности и мероприятия… и даже прибраться в помещении!
Результаты
Успешное PI-планирование позволяет получить три основных артефакта:
- Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. По каждой цели представителями от бизнеса определена оценка ее бизнес-ценности.
- Доска программы, на которой видны сроки поставки новых фич, зависимости между командами и зависимости от других ART, а также важные вехи.
- Согласие всех команд ART с реалистичностью целей PI и их готовность взять на себя ответственность за достижение этих целей.
