PI планирование 💎 — OnAgile Consulting
Опубликовано

PI планирование

Что такое PI планирование, или Планирование инкремента продукта, когда используется и как его проводить.

PI planning — что это?

Pi planning, или Планирование инкремента продукта, — это регулярное мероприятие, призванное синхронизировать все команды, работающие над одним продуктом, и помочь им придерживаться общей миссии и видения. Обычно представляет собой двухдневную рабочую сессию.

Понятие pi планирование пришло из фреймворка масштабирования SAFe. Дополнительный термин, который нам понадобится для понимания Планирования инкремента — Agile Release Train (ART) —  долгосрочная команда, состоящая из Agile команд, которые вместе с другими заинтересованными лицами постепенно разрабатывает, поставляет и, если применимо, эксплуатирует одно или несколько решений (solutions) в рамках value stream.

Что дает Планирование инкремента

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

Планирование помогает существенно снизить риски, что разработка продукта или его частей “пойдет не туда” и, соответственно, временные и финансовые потери на исправление. К другим преимуществам PI планирования можно отнести:

  • Синхронизация по видению решений, продукта/ сервисов и список приоритизированных фич
  • Видение архитектуры, эпик классов, нефункциональных требований, общих фреймворков
  • Обсуждение объема работ, проблем, стоящих перед планом, рисков и препятствий
  • Укрепление кросс-функционального общения
  • Приведение разработки в соответствие с бизнес-целями с бизнес-контекстом
  • Быстрое принятие решений
  • Анализ рисков и ограничений
  • При необходимости корректировка объема задач и ресурсов

Как провести pi планирование

Участники Планирования инкремента: команда ART, RTE (Release Train Engineer), архитекторы, стейкхолдеры и внешние заказчики, линейные руководители, Владельцы продуктов, Скрам-мастера, ведущий (обычно это внутренний или внешний agile-коуч).

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

К таким исходным данным относятся: 

  • Бизнес-контекст будущего Инкремента
  • Видение и дорожная карта продукта (Program Increment Roadmap)
  • Видение архитектуры, в том числе новых компонентов, функций и нефункциональных требований
  • Топ-10 фич программного бэклога (Program Backlog)

Результатом Планирования должны стать:

  • обязательные цели Программного инкремента: набор SMART целей для каждой команды, соответствующие бизнесовым целям продукта
  • Program board: доска, на которой отражены все фичи планируемого инкремента по всем командам, даты их поставки и зависимости между ними.

Само PI планирование занимает не менее двух рабочих дней и имеет типовую повестку, которая включает:

  • презентацию контекста и ожидаемого результата планирования
  • бизнес-контекст
  • видение продукта
  • архитектурное видение
  • работа в командах над формированием целей предстоящего программного инкремента
  • обзор и согласование планов команд
  • работа с рисками
  • ретроспектива PI и обратная связь от стейкхолдеров
Пример расписания pi планирования

Согласно общим рекомендациям SAFe и практике agile-сообщества, проводить Планирование лучше в офлайн формате. Некоторые компании предпочитают собирать всех участников планирования вне офиса,например, выезжать за город на несколько дней, чтобы дополнительно помочь сфокусироваться на PI.

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

Разбор кейсов PI планирования

Практическими рекомендациями, как проводить PI планирование, делится старший консультант OnAgile Артём Гринякин.

«Как и любая другая встреча, PI планирование требует знаний в области фасилитации,  а также, безусловно, опыта. Давайте рассмотрим два сценария с разным количеством участников.

Кейс №1: Компания Х, работающая в сфере платежных систем, минимальное количество участников начинается с отметки в 40 специалистов

Особое внимание нужно уделить подготовке топ-10 фич, без которых невозможно провести качественное планирование. Для этого стоит организовать ряд встреч с продуктовым офисом и убедиться, что у каждой фичи есть четкие критерии приемки, а также понятен концепт получения бенефитов. Другими словами, мы можем ответить на вопросы: что мы должны получить? как мы поймем, что это именно то, что мы хотели? и что мы получим, если сделаем это?

Второй момент, требующий внимания, это ваши Скрам-мастера. К сожалению, без обучения они не смогут в сжатые сроки, а именно за 4 часа, предусмотренные PI планированием, справиться с верхнеуровневой декомпозицией и составлением плана на суперспринт. Для подготовки Скрам-мастеров обычно мы рекомендуем сыграть в Pi- planning game, позволяющую в форме игры проработать ключевые моменты предстоящего планирования.

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

  • стоит уделить больше времени на командное планирование в первый день,
  • не стоит пушить команды сразу использовать относительные метрики для оценивания,
  • также мы рекомендуем привлечь к проведению PI как минимум одного ассистента Скрам-мастера.

И последний момент: заложите время на то, чтобы объяснить участникам PI планирования, чем отличаются командные риски от программных рисков, как работает доска зависимостей. Мой вам совет — запишите ряд обучающих видео и отправьте их заранее, чтобы увеличить шансы на успех.

Кейс №2: Компания Y, работающий в сфере энергоресурсов, количество участников более 70

Масштаб изменился, а значит нам нужно выполнить необходимые адаптации в PI планировании. Первое, о чем стоит подумать, – как вы будете работать с зависимостями и как обеспечите качественный обмен информацией и запросами, особенно если мы говорим о виртуальном PI. Забегая вперед  советую рассмотреть концепт проведения в 3 дня, а также использовать 2 доски – одна для постановки зависимостей, вторая уже для финального согласования между командами.

«Кого стоит позвать из топ-менеджмента?» — крайне важный вопрос. Нужно четко определить, без кого план не может быть утвержден и кто может предоставить ценную обратную связь в рамках PI.

При большой численности участников планирования, понадобится несколько ассистентов из расчета 1 на 20 участников, максимально — 1 на 30 частников.

В ходе PI планировани постоянно курсируйте между командами и инспектируйте происходящее, чтобы вовремя успеть сделать необходимые корректировки.

Ну и напоследок, помните, что первый PI самый сложный, а дальше все будет проще. Держите в голове, что первые 2 планирования всегда не идеальны, и их нужно использовать для адаптации.

Если вам нужна консультация по PI планированию или помощь в его проведении, наши коучи с радостью вам помогут. Оставить заявку: +7 495 221 87 39, info@onagile.ru

Еще публикации по Agile в Управление продуктом

Публикация
Промышленность
Проектирование продукта: пример сильных вопросов для Customer Development
Проектируя новые продукты, мы фокусируемся на изучении потребностей будущих потребителей. Один из лучших инструментов для понимания потенциального клиента — интервьюирование.
Публикация
Управление продуктом
«Управление продуктом в Scrum». Советы для бизнеса из книги Р.Пихлера
Какие ошибки мешают создавать успешный продукт. Как развивать видение продукта и работать с бэклогом. Важные цитаты из книги «Управление продуктом в Scrum: Agile-методы для вашего бизнеса» Романа Пихлера.
Публикация
Разработка ПО
Подборка книг о проектировании и запуске прорывных продуктов
Эта подборка книг — для тех, кто связан с проектированием, запуском и развитием продуктов в компаниях.
Публикация
Управление продуктом
Практика Scrum: как создать бэклог продукта
Пошаговый алгоритм создания бэклога продукта для Scrum-команд.

Мы помогаем организациям с 2004 года

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!