Что такое PI - планирование?

Что такое PI Planning (Планирование PI)?

PI Planning (Planning Increment, Планирование Программного Инкремента) — это ключевое событие в фреймворке SAFe (Scaled Agile Framework), представляющее собой регулярную (обычно каждые 8-12 недель) двухдневную очную или виртуальную встречу всей Agile Release Train (ART, Гибкий Поезд Поставки). Основная цель — синхронизировать команды, выровнять видение, спланировать работу на следующий программный инкремент и создать обязательства по достижению общих бизнес-целей.

Ключевые цели и результаты PI Planning

• Синхронизация и выравнивание: Все команды ART (обычно 5-12 команд) собираются вместе, чтобы понять общее направление, цели бизнеса (Business Context) и особенности архитектуры.
• Создание плана PI: Формируется детализированный план работ на весь инкремент в виде PI Roadmap и Program Board (Доска Программы).
• Выявление и управление зависимостями: Команды явно определяют межкомандные зависимости и договариваются о способах их разрешения.
• Формирование обязательств: Команды берут на себя обязательство по выполнению набора PI Objectives (Целей PI), согласованных с Business Owners (Владельцами Бизнеса).
• Ускорение обратной связи: Непосредственное общение сокращает время на согласования и устраняет недопонимание.

Участники PI Planning

• Все команды ART (Разработчики, тестировщики, аналитики, Scrum Masters).
• Product Management (Управление Продуктами): представляет Vision (Видение) и Program Backlog (Бэклог Программы).
• System Architect (Системный Архитектор): представляет Architecture Vision (Архитектурное Видение).
• Business Owners (Владельцы Бизнеса): предоставляют бизнес-контекст, устанавливают приоритеты и принимают финальные PI Objectives.
• Release Train Engineer (RTE, Инженер Поезда Поставки): фасилитирует все событие.

Типичная структура двухдневного PI Planning (пример)

День 1:

1. Бизнес-контекст: Выступление лидеров о состоянии рынка, стратегии, целях на PI.
2. Видение продукта и архитектуры: Product Management и System Architect представляют цели и ключевые фичи (Features).
3. Планирование команд №1: Команды расходятся на сессии планирования. Они анализируют Features, разбивают их на User Stories, оценивают их и планируют первую Iteration (Итерацию). На Program Board вносятся истории, зависимости и риски.
4. Draft Plan Review (Обзор чернового плана): Команды представляют свои черновые планы, обсуждают зависимости и получают обратную связь.

День 2:

1. Планирование команд №2: Корректировка планов с учетом фидбека. Планирование оставшихся итераций PI.
2. Final Plan Review (Обзор финального плана) и определение целей PI: Каждая команда представляет финальный план и формулирует PI Objectives — измеримые бизнес-ценности, которые они обязуются交付ить.
3. Управление рисками: Все выявленные риски обсуждаются, для критических назначаются владельцы.
4. Confidence Vote (Голосование уверенности): Все участники анонимно голосуют, насколько они уверены в выполнении плана (обычно показывая определенное количество пальцев). Цель — достичь коллективной уверенности (confidence). Если уверенности нет, риски обсуждаются далее.
5. Ретроспектива планирования: RTE проводит короткую ретроспективу самого события PI Planning для его улучшения в будущем.

Роль QA Engineer в PI Planning

Для QA инженера это событие критически важно:

• Понимание полного контекста: Получение информации о новых Features и архитектурных изменениях из первых рук.
• Влияние на планирование: Активное участие в оценке историй, выявлении тестовых требований и потенциальных рисков качества на раннем этапе.
• Координация усилий: Обсуждение и планирование:

    *   Межкомандного тестирования интеграции.
    *   Нефункциональных требований (производительность, безопасность).
    *   Необходимости автоматизации тестов для новых функциональностей.
    *   Зависимостей от других команд (например, получение тестовых данных или API).

• Формулировка целей по качеству: Включение в PI Objectives команды целей, связанных с качеством, например:

    *   "Достичь 80% покрытия автоматизацией для нового модуля X".
    *   "Провести нагрузочное тестирование сервиса Y до 3-й итерации".
    *   "Снизить уровень дефектов, найденных на стадии UAT, на 15%".

Пример Program Board после PI Planning

gantt
    title PI 4 Program Board (Упрощенный пример)
    dateFormat  YYYY-MM-DD
    section Команда A
    Функция: Поиск (F1)      :active, 2023-10-02, 21d
    История: A-123           :crit, 2023-10-02, 7d
    История: A-124           :2023-10-09, 7d
    История: A-125           :2023-10-16, 7d
    section Команда B
    Функция: Фильтры (F2)   :active, 2023-10-09, 14d
    История: B-456           :crit, 2023-10-09, 7d
    История: B-457           :2023-10-16, 7d

На такой доске визуализируются Features (F1, F2), User Stories (A-123), итерации и, что самое важное, зависимости (например, команда B может начать B-456 только после завершения A-124 командой A).

Заключение

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