Мероприятия Scaled Agile Framework®

1. МЕРОПРИЯТИЯ КОМАНДЫ

Планирование Итерации

Цель

Целью Планирования Итерации (Iteration Planning) является определение, организация и фиксация работы, которую команда будет выполнять в рамках итерации.

Программа

• Определение ёмкости команды на итерацию
• Анализ и оценка историй с помощью сторипоинтов, разработка критериев приёмки
• Детализация историй – договоренность о том, как команда обеспечит создание ценности
• Разработка целей итерации, достижение согласия по целям
• Взятие обязательств (обычно с помощью голосования) за выполнение целей итерации

В программу также рекомендуется включить обсуждение того, как именно каждая история будет продемонстрирована на Обзоре в конце итерации, а также какая часть из созданной ценности будет вынесена на ближайшую Демонстрацию Системы всего Agile Release Train, следующую за Обзором итерации.

Результаты

• Беклог итерации, состоящий из запланированных историй на предстоящую итерацию, с четко определенными критериями приёмки
• Сформулированные цели итерации, обычно по одному или двум предложениям для каждой из них, с указанием бизнес-целей итерации
• Команда взяла обязательства за выполнение целей итерации
• Зависимости с другими командами определены

Участники

• Владелец Продукта
• Скрам Мастер / Коуч Команды (обычно фасилитирует мероприятие)
• Все члены команды
• Любые другие заинтересованные стороны по мере необходимости, включая представителей других agile команд или Agile Release Train, а также профильных экспертов

Примечание: это мероприятие проводится командой и для команды!

Логистика

Продолжительность (для двухнедельной итерации): около 1,5 часа (при должном уровне проработки беклога до мероприятия планирования) и не более 4х в других случаях

Частота проведения: каждые две недели (в первый день новой итерации)

Синхронизация Команды (ранее ежедневный стендап)

Синхронизация Команды (Team Sync) — это новый термин для ежедневной встречи команды в соответствии с SAFe 6.0, который заменяет ранее используемое название — Ежедневная встреча (стендап) команды (Daily Standup, DSU).

Цель

Целью Синхронизации Команды (Team Sync) является синхронизация и координация действий команды, а также поднятие блокирующих вопросов и зависимостей, многие из которых необходимо будет решить после этого мероприятия.

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

Примечание: хотя ежедневная встреча является событием Скрам, многие Канбан команды также проводят такое мероприятие перед своей доской Канбан для координации работы и выявления узких мест или проблем НЗР (незавершенная работа, work in process, WIP).

Программа

На ежедневной встрече каждый член команды отвечает на вопросы:

1. Что я сделал вчера, чтобы продвинуться к выполнению Целей Итерации?
2. Что я буду делать сегодня, чтобы продвинуться к выполнению Целей Итерации?
3. Есть ли какие-то препятствия, которые не позволят команде выполнить Цели Итерации?

На каждого участника отводится по 1 минуте или меньше. В рамках Синхронизации Команды возможно задать любые краткие уточняющие вопросы. Все, что требует более глубокого и длительного обсуждения, фиксируется Скрам Мастером / Коучем Команды и решается на отдельной встрече за пределами этого мероприятия только вовлеченными участниками.

Примечание: Синхронизация Команды не является отчетом перед руководством, Владельцем Продукта или Скрам Мастером / Коучем Команды!

Результаты

• Выравнивание по ранее выполненным работам и по работам на предстоящий день
• Выявленные риски и/или препятствия, которые блокируют команду
• Определение тем, которые выносятся на встречу-после, или определение последующих шагов по решению поднятых вопросов

 Участники

• Все члены команды
• Скрам Мастер / Коуч Команды (фасилитирует проведение встречи)
• Владелец Продукта в качестве слушателя, может выступить в рамках «своей» минуты для синхронизации по своей части работы в команде

Из других участников допускается присутствие Agile коуча, в редких случаях — гостей из других команд, но не «руководства для контроля».

Логистика

Частота: каждый рабочий день в одно и то же время

Продолжительность: 10-15 минут

Примечание: Синхронизация Команды наиболее полезна, когда проводится перед доской команды, чтобы члены команды могли выделить истории, на которые они ссылаются. Важно, чтобы все вводные и обсуждения выносились за рамки Синхронизации Команды на Встречу-после. Например, начинались строго после явного объявления Скрам Мастером / Коучем Команды о завершении Team Sync.

Уточнение Беклога

 Цель

Мероприятия по Уточнению Беклога (Улучшению Беклога, Backlog Refinement) позволяют командам начать формировать общее понимание и согласовывать в общих чертах работы на следующие итерации, начать выявлять зависимости, сообщать о приоритетах беклога и начать выдвигать гипотезы о том, как команда может решить будущие задачи.

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

Программа

• Обсуждение самых важных элементов работы (обычно это истории, которые пойдут в ближайшую итерацию)
• Обсуждение историй-кандидатов для будущих итераций
• Оценка размера историй, декомпозиция историй при необходимости
• Обсуждение критериев приемки
• Определение зависимостей с другими командами
• Расстановка приоритетов

Программа также может включать в себя подготовку и обсуждение историй для предстоящего PI Планирования (PI Planning). Чем ближе к мероприятию, тем больше времени должно отводиться на подготовку.

Подготовка к мероприятию

• Подготовить беклог команды
• Собрать список Фич, Целей на Интервал Планирования (PI Objectives) и зависимостей с другими командами
• Определить Истории-Кандидаты для включения в следующую итерацию
• Определить аллокацию ёмкости команды по типам/группам работ

Результаты

• Согласованность относительно объёма работ и усилий для достижения целей команды в предстоящую итерацию (или итерации)
• Общее понимание того, как может быть выполнена предстоящая работа
• Истории, оцененные в сторипоинтах, с разработанными критериями приемки, готовые для разработки в следующей итерации
• Спайки для дальнейшего исследования
• Выявленные зависимости либо урегулированы, либо определены шаги для последующих действий
• Риски и препятствия текущего плана были выявлены и обсуждены

Участники

• Все члены команды
• Владелец Продукта или Скрам Мастер / Коуч Команды обычно фасилитирует это мероприятие
• Эксперты в предметной области (при необходимости)
• Заинтересованные лица, включая Менеджмент Продукта, Архитекторов, представителей других команд и Релизных Поездов Agile (Agile Release Train, ART)

Логистика

Частота: один-два раза за итерацию (команды также могут скорректировать частоту и продолжительность по мере необходимости)

Продолжительность: около 2 часов на итерацию (может корректироваться в большую сторону при необходимости)

Обзор Итерации

Цель

Цель Обзора Итерации (Iteration Review) – это сделать обзор результатов, подвести итог за прошедшую итерацию. На мероприятии Владельцу Продукта и другим заинтересованным лицам демонстрируются работающие истории, чтобы получить от них обратную связь о прогрессе в достижении цели продукта и определить дальнейшую работу. Обзор Итерации позволяет членам команды продемонстрировать вклад, который они внесли в продвижение к целям Интервала Планирования (PI Objectives), и почувствовать удовлетворение и гордость за свою работу.

Программа

• Обзор бизнес контекста и целей итерации
• Демонстрация и обратная связь по каждой Истории, спайку, рефакторингу и Нефункциональным требованиям
• Обсуждение Историй, которые не были выполнены в Итерацию, и почему
• Определение рисков и препятствий
• Пересмотр беклога команды и целей команды на Интервал Планирования (при необходимости)

Подготовка к мероприятию

• Подготовка к обзору итерации начинается во время планирования итерации, когда команды начинают думать о том, как они будут демонстрировать истории, за выполнение которых они взяли на себя обязательства. «Начинать дело, представляя конечную цель» облегчает планирование и обеспечивает выравнивание итераций, помогает лучше понять до начала итерации, какая нужна функциональность.
• Подготовка к обзору должна быть ограничена по времени 1-2 часами. Желательно не использовать слайды презентации, а работать из системы управления (репозитория) Историй и/или Интента Решения (Намерения Решения, Книги Правды Решения).

Результаты

• Истинное понимание прогресса в достижении целей путем демонстрации работающего функционала программного обеспечения, аппаратных компонентов и т.д.
• Определены риски и препятствия
• При необходимости пересмотрено выполнение целей команды на Интервал Планирования и ее беклог

Участники

• Все члены команды
• Скрам Мастер / Коуч Команды обычно фасилитирует Обзор Итерации, а члены команды представляют свою работу на Демо.
• Все лица, заинтересованные в результатах работы команды

Примечание: если основное заинтересованное лицо, обычно кто-то из менеджмента, не может присутствовать на Обзоре Итерации, то мероприятие все равно проводится, а Владелец Продукта должен донести до него информацию в индивидуальном порядке.

Логистика

Частота: один раз за итерацию (в конце итерации).

Продолжительность: 1-2 часа (на 2-х недельную итерацию)

Ретроспектива Итерации 

Цель

Ретроспектива Итерации (Iteration Retrospective) – это регулярное мероприятие, на котором Agile команда обсуждает результаты итерации, что работает хорошо, а что нет и что команда может сделать лучше в следующий раз.

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

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

Ретроспектива Итерации помогает формировать концепцию неустанного улучшения — одного из столпов Бережливого мышления SAFe. Таким образом, каждая итерация способствует некоторым небольшим улучшениям.

Программа

• Представление целей и выбор формата проведения ретроспективы
• Обратная связь и идеи от каждого члена команды:

Часть 1: Количественная

1. Рассмотрение существующих элементов по улучшению в беклоге, запланированных на эту итерацию. Они все выполнены?
2. Фиксация выполнения командой поставленных целей (да/нет)?
3. Сбор и просмотр согласованных метрик Итерации

Часть 2: Качественная

1. Что получилось?
2. Что не получилось?
3. Что мы можем сделать лучше в следующий раз?

• Обсуждение идей
• Голосование и выбор 1-2 элементов для улучшений в следующую итерацию
• Фиксация элементов для улучшений в беклоге команды, если они требуют времени для выполнения, либо изменение каких-либо установок внутри команды «на месте»

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

Результаты

• 1-2 элемента для улучшения, занесенные в беклог команды
• Обратная связь от команды по проведению мероприятия (техники, темы, опросы и т.д.)

Участники

• Все члены команды
• Скрам Мастер / Коуч Команды (обычно фасилитирует мероприятие)

Примечение: ретроспектива – это закрытое мероприятие команды и участие в нем должно быть ограничено строго членами Agile команды.

Логистика

Частота: один раз в итерацию (в конце итерации)

Продолжительность: 1 час или меньше

2. МЕРОПРИЯТИЯ ПОЕЗДА

Интервал Планирования (Planning Interval, PI) — это новый термин в SAFe 6.0., который используется вместо Инкремента Программы (Program Increment, PI).

Интервал Планирования (PI) — это временной интервал, в течение которого Релизный Поезд Agile (Agile Release Train, ART) доставляет инкрементальную ценность в виде работающего, протестированного программного обеспечения и систем. Интервал Планирования обычно длится 8-12 недель. Наиболее распространенным вариантом является продолжительность Интервала Планирования в 10 недель: четыре итерации разработки, за которыми следует одна итерация инноваций и планирования (Innovation & Planning Iteration, IP Итерация).

PI Planning

Цель

PI Планирование (PI Planning) – это мероприятие, которое основано на каденции и задает «сердечный» ритм Релизному Поезду Agile, выравнивая все команды AgileRelease Train (ART) в соответствии с общей Миссией и Видением. Цель мероприятия — создать приоритизированный список высокоуровневых целей и взять на себя ответственность за совместные действия по их достижению на уровне всего поезда (Agile Release Train, ART).

Программа мероприятия

1 день

• Выступление топ-менеджмента: представление бизнес-контекста
• Выступление продуктовой команды: представление видения продукта/решения. Опционально: представление дорожной карты, ключевых моментов в разработке Фич, продуктового контекста и персон пользователей (personas)
• Выступление со стороны команды архитекторов: архитектурное видение и практики разработки. Опционально: представление архитектурной части дорожной карты, технического контекста и ключевых нефункциональных требований
• #1 Прорыв команд – создание первоначальных договоренностей и предварительных планов (целей)
• (для онлайн мероприятия здесь обычно заканчивается первый день)
• Представление (обзор) предварительных планов
• Рассмотрение планов на уровне менеджмента и решение проблем

2 день (офлайн)

• Корректировка планирования (при необходимости)
• #2 Прорыв команд – создание финальных договоренностей и планов (целей)
• (для онлайн мероприятия здесь обычно заканчивается второй день)
• Представление (обзор) финальных планов
• Обсуждение рисков поезда на Интервал Планирования
• Голосование уверенности относительно возможности выполнения Интервала Планирования
• Доработка при необходимости (#3 Прорыв – доработка финальных планов)
• Ретроспектива мероприятия

Примечание: мероприятие в онлайн-формате рекомендуется планировать на 3 дня с некоторыми корректировками к офлайн-программе:

• 1-й день обычно завершается с окончанием 1-го прорыва команд.
• 2-й день начинается с представления (обзора) предварительных планов и заканчивается с окончанием 2-го прорыва
• 3-й день начинается с представления (обзора) финальных планов

Подготовка к мероприятию

• Видение определено
• Беклог Поезда (ART Backlog) с приоритизированными Фичами подготовлен
• Топ 10 Фич выделены
• Социализация Фич среди команд поезда проведена. Обычно это означает, что командами подготовлены и оценены большинство Историй в этих Фичах.
• Команды подготовили предварительный список зависимостей, и он использован для приглашения на мероприятие гостей из других подразделений, от партнеров и контрагентов

Результаты

• Согласованные цели на Интервал Планирования для каждой команды, за выполнение которых команды взяли на себя обязательства
• Согласованные цели на Интервал Планирования для всего поезда, в достижении которых со стороны Agile Release Train присутствует как минимум «рабочий» уровень уверенности
• Доска Планирования Поезда, содержащая все ключевые зависимости, понятна и принята всеми участниками мероприятия
• Риски поезда на Интервал Планирования определены и обсуждены на уровне Поезда

Преимущества

• Установление коммуникаций со всеми членами поезда и заинтересованными лицами
• Выравнивание разработки в соответствии с бизнес-целями в бизнес-контексте, Видением и Целями на Интервал Планирования уровня Команды/Поезда
• Выявление зависимостей и эффективное взаимодействие между командами и поездами
• Обеспечение возможностей для «только необходимого количества» архитектуры и требований со стороны Бережливого Опыта Пользователя (Lean User Experience, UX)
• Соответствие требований и пропускной способности, устранение избытка НЗР (WIP)
• Быстрое принятие решений по многим вопросам

Участники

• Все члены команд
• Release Train Engineer, RTE (Инженер Релизного Поезда)
• Менеджмент Продукта
• Архитекторы Систем
• Заинтересованные лица поезда (иногда их называют «гости»)
• Владельцы Бизнеса
• Топ-менеджмент

Release Train Engineer фасилитирует PI Планирование.

Логистика

Каждый Интервал Планирования начинается с мероприятия PI Планирования (PI Planning).

Продолжительность: 2 дня (в онлайн варианте обычно проходит 3 дня или более)

Частота проведения: каждые 8-12 недель (обычно 10 недель)

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

Coach Sync (ранее Scrum of Scrums)

Синхронизация Коучей (Coach Sync) — это новое название мероприятия в соответствии с новой версией SAFe 6.0., которое заменяет название Scrum of Scrums.

Цель

Синхронизация Коучей (Coach Sync) помогает cкоординировать зависимости, обозначить препятствия и синхронизировать понимание прогресса в достижении целей на уровне Скрам Мастеров / Коучей Команды. 

Программа

Скрам Мастер / Коуч Команды кратко рассказывает, что нового произошло в ходе работ его команды, отвечая на следующие вопросы:

• Что выполнила команда с момента последней встречи?
• Что выполнит команда до следующей встречи?
• Есть ли какие-то блокирующие проблемы?
• Блокирует ли команда работу кого-либо еще?

Примечание: в рамках мероприятия возможны любые краткие уточняющие вопросы.

Все, что требует более глубокого обсуждения, должно быть перенесено на Встречу-после.

Результаты

• Синхронизация в работе команд
• Прозрачность прогресса и препятствий в достижении целей Интервала Планирования

Участники

• Скрам Мастера / Коучи всех команд
• Release Train Engineer (Инженер Релизного Поезда, RTE)
• Другие представители команд (если необходимо)
• Профильные эксперты и гости (если необходимо)

Release Train Engineer фасилитирует мероприятие Синхронизация Коучей.

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

Логистика

Частота: 1-2 раза в неделю

Продолжительность: 30-60 минут

За этим мероприятием часто следует «Встреча-после» для более глубокого обсуждения и решения отдельных вопросов.

PO Sync

Цель

Синхронизация Владельцев Продукта (PO Sync) — это регулярное мероприятие для Владельцев Продукта (Product Owner, PO) и Менеджеров Продукта (Product Manager, PM), которое позволяет решить несколько важных задач. Во-первых, PO Sync обеспечивает понимание того, насколько хорошо Agile Release Train продвигается к достижению своих целей Интервала Планирования. Во-вторых, позволяет оценить необходимые корректировки. И в-третьих, помогает выявить любые возможности и вызовы с разработкой Фич.

Это мероприятие также может быть использовано для подготовки к следующему Интервалу Планирования и включать мероприятие «Улучшение Беклога Программы» и приоритизацию Фич с помощью WSJF перед следующим PI Планирования.

Программа

• Обсуждение Фич, которые разрабатывают команды
• Обсуждение зависимостей, блокировок или рисков
• Владелец Продукта от каждой команды кратко рассказывает, насколько его/её команда продвинулась в достижении целей на Интервал Планирования
• Озвучивание цели Интервала Планирования или Фичи, выполнение которых находится под угрозой или заблокировано
• Мероприятие «Уточнение Беклога Программы» и расстановка приоритетов Фич для следующего PI Планирования по WSJF (когда отсутствует отдельное мероприятие для подготовки к следующему PI Планированию на уровне Поезда)

Результаты

• Синхронизация в работе расширенной продуктовой команды
• Прозрачность прогресса и препятствий в достижении целей на Интервал Планирования
• Возможность оценить любые корректировки объёма работ

 Участники

• Владельцы Продукта
• Менеджеры Продукта
• Release Train Engineer (RTE, Инженер Релизного Поезда)
• Владельцы Бизнеса (при необходимости)
• Архитекторы, другие заинтересованные лица (при необходимости)
• Эксперты по отдельным темам и гости (при необходимости)

RTE или Менеджер Продукта фасилитирует PO Sync.

Логистика

Частота: еженедельно или чаще

Продолжительность: 30-60 минут

За этим мероприятием часто следует «Встреча-после» для более глубокого обсуждения и решения вопросов, поднятых на PO Sync.

ART Sync

 Цель

Поезд (Agile Release Train, ART) может решить объединить PO Sync и Coach Sync в одно событие. В этом случае событие называется Синхронизация Релизного Поезда (ART Sync). Это возможность собрать лидеров ART и команд, обсудить зависимости, риски и препятствия, выравнять действия команд в поезде, а также синхронизировать понимание прогресса в достижении целей. 

Программа

• Обсуждение Фич, над которыми работают команды
• Обсуждение зависимостей, блокировок или рисков
• Обзор планов по развертыванию и релизам
• Выравнивание всех команд относительно Доски Планирования Поезда
• Подготовка к PI Планированию
• Обзор прогресса Agile Release Train в достижении целей на Интервал Планирования

Результаты

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

Участники

• Владельцы Продукта
• Менеджеры Продукта
• Скрам Мастера / Коучи Команд
• Release Train Engineer (RTE, Инженер Релизного Поезда)
• Владельцы Бизнеса (при необходимости)
• Архитекторы (при необходимости)
• Некоторые другие представители команд (при необходимости)
• Другие заинтересованные лица и гости (при необходимости)
• Эксперты по профильным темам (при необходимости)

RTE или Продуктовая Команда фасилитирует Синхронизацию Поезда (ART Sync).

Логистика

Частота: по необходимости, каждую неделю должны как минимум происходить отдельно PO Sync и Coach Sync или совместный ART Sync.

Продолжительность: корректируется по мере необходимости, обычно не более 1-2 часов.

 За этим мероприятием может следовать «Встреча-после» для более глубокого обсуждения и решения отдельных вопросов.

System Demo

Цель

Демо Системы (Демонстрация Системы, System Demo) – это ключевое событие, которое демонстрирует самые важные интегрированные результаты, доставленные Поездом за прошедшую (завершенную) итерацию.

Каждая демонстрация дает заинтересованным лицам Agile Release Train объективную оценку прогресса поезда в рамках Интервала Планирования. Кроме этого, это мероприятие позволяет оценить текущее состояние Решения, получить незамедлительную обратную связь от людей, выполняющих работу, а также от владельцев бизнеса, спонсоров, заинтересованных лиц и клиентов.

 Участие в Демо Системы требует некоторой подготовки со стороны команд. Но это единственный способ получить быструю обратную связь, необходимую для создания правильного решения.

Программа

• Краткий обзор бизнес-контекста и Целей на Интервал Планирования
• Краткое описание каждой новой Фичи перед демонстрацией
• Демонстрация каждой новой фичи в комплексном/сквозном варианте использования
• Идентификация текущих рисков и препятствий
• Открытое обсуждение вопросов и обратной связи
• Подведение итогов и резюме по прогрессу, обратной связи и вопросам, требующих решения

Подготовка к мероприятию

• Фичи функционально завершены или отключены «toggled off», чтобы не срывать демонстрацию функциональности
• Новые фичи работают друг с другом и вместе с существующей функциональностью
• Демо из среды, максимально повторяющей производственную
• Минимальное время на подготовку к Демо. Демонстрация работающих, протестированных элементов, не слайдов презентации

Результаты

• Реальное измерение доставленной ценности, пропускной способности и прогресса в достижении целей Интервала Планирования
• Быстрая обратная связь, необходимая для создания правильного решения

Участники

• Менеджеры Продукта и Владельцы Продукта (они обычно отвечают за проведение мероприятия)
• Члены Команды Системы (они обычно отвечают за техническую сторону проведения Демо в промежуточной среде)
• Владельцы Бизнеса, спонсоры, клиенты и прокси-клиенты
• Архитекторы Систем, ИТ специалисты, другие участники разработки
• Члены команд Agile Release Train участвуют по мере возможности

Логистика

Частота: каждую итерацию. Обычно проходит сразу после завершения обзора итерации внутри всех команд (может отставать максимум на одну итерацию)

Продолжительность: 1 час

Примечание: важно стараться укладываться в 1 час, чтобы обеспечить участие ключевых стейкхолдеров на регулярной основе (1 раз в две недели) и продемонстрировать профессионализм команды и готовность системы

В конце каждого Интервала Планирования Agile Release Train проводит еще одну финальную Демонстрацию Системы за весь Интервал Планирования (Демо Системы Интервала Планирования, PI System Demo), которая показывает все фичи, разработанные за завершившийся Интервал Планирования. Поскольку его охват больше, аудитория может быть шире и включать клиентов, представителей портфеля и других дополнительных заинтересованных лиц. Эта демонстрация обычно является частью события Инспект-Адапт (Inspect & Adapt, I&A), которое включает в себя ретроспективу и различные показатели прогресса Интервала Планирования, в том числе «меру предсказуемости поезда» и «метрики эффективности поезда».

Подготовка к PI Планированию

Хотя подготовка к следующему PI Планированию (Prepare for PI Planning) и выделяется как отдельное событие уровня Поезда, на самом деле, подготовка к предстоящему мероприятию и Улучшение Беклога Программы (Program Backlog Refinement) является непрерывным процессом.

Три основные области подготовки, на которые направлено внимание:

• управленческое выравнивание и готовность организации к планированию
• Беклог и готовность контента (собственно Улучшение Беклога Программы)
• Логистика проведения мероприятия «PI Планирование»

Каждый из трех факторов требует тщательного внимания, так как может повлиять на эффективность и успех PI Planning.

Программа

Если мероприятия организуется в явном виде, желательно, чтобы оно включало в себя следующие темы повестки:

• Текущий бизнес контекст (что мы узнали к настоящему моменту?)
• Обзор Эпиков в работе
• Обзор дорожных карт (Дорожная Карта Решения и Дорожная Карта Интервала Планирования – для мероприятия уровня ART)
• Обзор Канбан доски Фич
• Сессия Улучшения Беклога Фич
• Сессия WSJF приоритизации Фич
• Планирование дальнейших действий
• Встреча-после

 Результаты

• Обновленная Дорожная Карта Интервала Планирования (PI)
• Обновленная Канбан доска Фич
• Обсужденные новые Фичи
• Фичи приоритизированы по WSJF

Участники

• Менеджеры Продукта
• Release Train Engineer (RTE, Инженер Релизного Поезда)
• При необходимости, Владельцы Бизнеса
• При необходимости Архитекторы Систем
• При необходимости Владельцы Продукта (все или выборочно)
• Некоторые другие представители команд (при необходимости)
• Другие заинтересованные лица (при необходимости)
• Эксперты по профильным темам (при необходимости)

RTE или Продуктовая Команда фасилитирует мероприятие подготовки к PI Планированию.

Логистика

Подготовка к PI Планированию и Улучшение Беклога Программы должны вестись непрерывно и каждую неделю.

Компании обычно используют один из следующих вариантов проведения мероприятия:

• Регулярное выделенное мероприятие
• Как продолжение мероприятия PO Sync
• В виде непрерывного процесса взаимодействия Владельцев Бизнеса, Менеджеров Продукта, Архитекторов и Владельцев Продукта

Inspect and Adapt

Цель

Инспект-Адапт (Inspect & Adapt, I&A) является значимым и заслуживающим самого большого внимания событием, проводимым в конце каждого Интервала Планирования. На мероприятии показывается текущее состояние Решения, демонстрируя ключевые интегрированные результаты, которые были доставлены Поездом за весь Интервал Планирования. Результаты достижения целей оцениваются поездом. Инспект-Адапт способствует неустанным улучшениям с помощью регулярного обсуждения и определения мер для совершенствования, которые вносятся в беклоги Поезда и Команд, они необходимы для повышения пропускной способности, качества и стабильности следующего Интервала Планирования.

Так же, как Agile-командам рекомендуется проводить ретроспективы команд в конце каждой итерации, Релизные Поезда должны планировать мероприятие Инспект-Адапт в конце каждого Интервала Планирования.

Результат

• Понимание истинного текущего состояния Решения по результатам Интервала Планирования
• Фичи или Истории для дальнейших улучшений определены и добавлены в беклог на предстоящее PI Планирование. Таким образом, каждый Agile Release Train (ART) улучшает выполнение каждого последующего Интервала Планирования.

Программа

Это событие состоит из трех частей:

1. Демо Системы за Интервал Планирования (PI System Demo) для демонстрации текущего состояния Решения
2. Количественная и качественная оценка текущего состояния Решения
3. Ретроспектива и Мастерская решения проблем (Problem Solving Workshop, PSW)

Участники

• Agile команды в полном составе
• Release Train Engineer (RTE, Инженер Релизного Поезда)
• Архитекторы
• Менеджеры Продукта и Владельцы Продукта
• Владельцы Бизнеса и заинтересованные лица

Release Train Engineer фасилитирует Inspect & Adapt.

Логистика

Частота: в конце каждого Интервала Планирования

Продолжительность:

Это событие состоит из трех частей (время указано для очного проведения):

1. Демо Cистемы за Интервал Планирования для демонстрации текущего состояния Решения – не более 60 минут
2. Количественная и качественная оценка текущего состояния Решения – 20-45 минут
3. Ретроспектива и Мастерская решения проблем – 30 минут и 60 минут соответственно (при необходимости Мастерская решения проблем может проходить более 1 часа)

3. МЕРОПРИЯТИЯ РЕШЕНИЯ

Architect Sync

Цель

Синхронизация Архитекторов (Architect Sync) служит нескольким целям. Мероприятие позволяет всем архитекторам и заинтересованным сторонам согласовать техническую часть для поддержки Видения Решения и принятия высокоэффективных решений.

Architect Sync обеспечивает прозрачность технического подхода и архитектурных намерений по всему Решению. Синхронизация Архитекторов также дает всем разработчикам Решения представление о деталях дизайна Решения, что помогает определить, как дизайн может повлиять на разработку в части ограничений либо, наоборот, создать потребность возникновения растущей архитектуры (emerging architecture) «по месту» со стороны команд.

Данное мероприятие не является «классическим» Архитектурным Комитетом, выполняющим административную разрешительно-согласующую функцию для запрашиваемых действий со стороны команд!

Программа

• Обсуждение прогресса и препятствий в текущей работе над Энейблерами
• Обзор технического дизайна, получение обратной связи и корректировка
• Социализация и обсуждение ключевых вопросов дизайна, выравнивание команд в соответствии с дизайном
• Обсуждение технических аспектов разработки Фич и Историй, какая поддержка необходима командам
• Обзор способности архитектуры поддерживать долгосрочное Видение Решения для выявления рисков и корректировки Архитектурного Русла
• Обзор беклога Архитектурного Русла и расстановка приоритетов

Результаты

• Выравнивание в соответствии со стратегией
• Дизайн Архитектурного Русла
• Устранение рисков и препятствий
• Обзор проблем и решений

 Участники

Участники Architect Sync будут варьироваться в зависимости от повестки дня. Лидеры Поезда Решения и некоторые члены Agile Release Train, скорее всего, будут присутствовать на большинстве синхронизаций архитекторов. Другие участвуют по мере необходимости, чтобы внести свой вклад в принятие решений и получить обратную связь от группы.

• Архитекторы Систем, Решения, Предприятия
• Менеджмент Продукта/Решения
• Владельцы Бизнеса
• Другие стейкхолдеры (при необходимости)
• Другие технические лидеры (при необходимости)
• Владельца Продукта и некоторые члены команд (при необходимости)
• Эксперты по ключевым областям (при необходимости)

Release Train Engineer (RTE, Инженер Поезда Решения) или «Главный Архитектор» часто фасилитирует это мероприятие. Допустима фасилитация со стороны Solution Train Engineer (STE).

Логистика

Частота: обычно еженедельно

Продолжительность: 30-60 минут

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

Solution Demo

Цель

Демонстрация Решения (Демо Решения, Solution Demo) объединяет усилия по разработке со стороны всех Agile Release Train (ART, Релизных Поездов Agile) и поставщиков в Поезде Решения для каждого Интервала Планирования и делает их видимыми для клиентов и других заинтересованных лиц.

Демо Решения является критически важным событием для Поезда Решения (Solution Train), так как позволяет получить объективную оценку и обратную связь. Это также мероприятие, чтобы отпраздновать достижения последнего Интервала Планирования.

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

Программа

• Краткий обзор Целей Интервала Планирования для Поезда Решения
• Демонстрация каждой цели и капабилити Интервала Планирования в сквозном сценарии использования
• Определение бизнес-ценности, выполненной для каждой цели на Интервал Планирования
• Вопросы и комментарии
• Подведение итога и краткое формулирование прогресса, обратной связи и плана действий

Участники

• Менеджмент Решения
• Solution Train Engineer (Инженеры Поезда Решения, STEs)
• Архитекторы Решения и Систем
• Клиенты
• Представители Поездов
• Менеджмент Продукта
• Команда Системы
• Владельцы Продукта
• Представители Agile команд (чтобы услышать обратную связь от клиентов из первых рук)
• Представители Lean Portfolio Management (LPM)
• Стейкхолдеры Большого Решения SAFe, спонсоры и высший менеджмент
• Представители команд или подразделений, отвечающих за интеграцию и развертывание, если такие имеются

Логистика

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

Продолжительность: 1-2 часа

Inspect and Adapt уровня Решения

Если  Agile Release Train (Релизный Поезд, ART) является частью Поезда Решения (Solution Train), то проведение мероприятия Инспект-Адапт (Inspect & Adapt, I & A) только на уровне каждого ART иногда бывает достаточно, так как на них часто участвуют ключевые заинтересованные лица уровня Large Solution.

При этом часто, когда речь идет о более крупных и глубоко связанных потоках создания ценности, может потребоваться проведение дополнительного события Inspect &Adapt уровня Крупного Решения в том же формате. В Поезде Решения задействовано большое количество людей, из-за чего мероприятие Инспект-Адапт уровня Крупного Решения не может включить всех. Поэтому для участия в мероприятии Инспект-Адапт для Крупного Решения выбираются заинтересованные лица, которые лучше всего подходят для решения проблем, с которыми сталкиваются Поезда Решений. Обычно в эту группу входят основные заинтересованные лица Поезда Решения, а также представители различных Agile Release Train и Поставщиков.

Solution Train Sync

Цель

Поезд Решения всегда объединяет PO Sync и Coach Sync в одно событие на своем уровне, и оно называется «Синхронизация Поезда Решения» (Solution Train Sync). Это возможность собрать лидеров Поезда Решения с представителями Agile Release Train (ARTs), сосредоточиться на разрабатываемых Возможностях (Капабилити) и прогрессе в достижении целей Интервала Планирования на уровне Решения, а также согласовать действия Релизных Поездов в Поезде Решения.

Программа

• Обсуждение Капабилити, над которыми работают Поезда
• Обсуждение зависимостей, блокировок или рисков
• Обзор планов по интеграции результатов работы Поездов, развертыванию и релизам
• Выравнивание всех Поездов относительно Доски Поезда Решения
• Подготовка к PI Планированию (разработка и улучшение беклога Капабилити)
• Обзор прогресса Поезда Решения в достижении целей Поезда Решения на Интервал Планирования

Результаты

• Синхронизация Solution Train
• Прозрачность прогресса и препятствий в достижении целей Интервала Планирования на уровне всего Решения
• Подготовка к следующему PI Планированию

Участники

• Solution Train Engineer (STE)
• Менеджеры Решения
• При необходимости Архитекторы Решения
• Менеджеры Продукта поездов внутри Поезда Решения
• При необходимости Архитекторы Систем поездов внутри Поезда Решения
• Release Train Engineer (RTE) поездов внутри Поезда Решения
• Некоторые другие представители поездов (при необходимости)
• Другие заинтересованные лица (при необходимости)
• Эксперты по профильным темам (при необходимости)

Solution Train Engineer (STE) или Продуктовая Команда Решения фасилитирует Solution Sync.

Логистика

Частота: по необходимости, желательно хотя бы раз в Итерацию (каждые 2 недели)

Продолжительность: корректируется по мере необходимости

 За этим мероприятием может следовать «Встреча-после» для более глубокого обсуждения и решения отдельных вопросов

4. МЕРОПРИЯТИЯ ПОРТФЕЛЯ (LPM)

Стратегический Обзор Портфеля 

 Цель

Основная цель мероприятия «Стратегический Обзор Портфеля» (Strategic Portfolio Review) – это выравнивание стратегии, бюджета и обеспечение “здоровья”портфеля. Мероприятие направлено на продвижение и реализацию видения портфеля, а также достижения целей портфеля. Для того, чтобы потоки создания ценности могли подготовиться и реагировать на любые изменения, мероприятие обычно проводится ежеквартально на основе каденции, по крайней мере, за месяц до следующего PI Planning.

Программа

• Оценка контекста портфеля
• Поддержка видения портфеля
• Обзор стратегических тем
• Обзор инвестиционных горизонтов и других Бережливых бюджетных направляющих
• Обзор метрик и KPI портфеля
• Обзор дорожной карты портфеля

Участники

Обязательные участники: Топ-менеджеры, Владельцы Бизнеса, Архитектор Предприятия, Менеджеры Портфеля Решения

Опциональные участники: Владельцы Эпиков, Менеджеры Продукта и Менеджеры Решения, Инженеры Релизных Поездов (Release Train Engineer, RTE)

 Логистика

Частота: как минимум один раз в течение Интервала Планирования (примерно ежеквартально) и, по крайней мере, за месяц до следующего PI Планирования.

Продолжительность: столько, сколько необходимо для прохождения всей программы мероприятия. Может проводиться в несколько сессий.

Portfolio Sync 

Цель

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

 Программа

• Обзор находящихся в разработке эпиков, оценка MVP и принятие решений
• Продвижение эпиков по Канбан системе
• Блокирующие вопросы и препятствия
• Координация вопросов между потоками создания ценности
• Сбор метрик портфеля и KPI потоков ценности
• Обновление дорожной карты портфеля

Участники

Обязательные участники: Топ-менеджеры, Владельцы Бизнеса, VMO (Value Management Office), LACE (Lean Agile Center of Excellence)

Опциональные участники: Инженеры Релизных Поездов (Release Train Engineer, ART), Скрам Мастера / Коучи Команд, Владельцы Эпиков

Логистика

Частота: каждые две итерации (приблизительно ежемесячно). Если в этот месяц проводится Стратегический Обзор, то «обычная» синхронизация может не проводиться.

Продолжительность: столько, сколько необходимо для прохождения всей программы мероприятия. Может проводиться в несколько сессий.

Самобюджетирование (Инициативное Бюджетирование)

Цель

Самобюджетирование SAFe (Participatory Budgeting, на русском также используется термин «Инициативное Бюджетирование») — это мероприятие, на котором команда Lean PortfolioManagement (LPM) и заинтересованные лица решают, как распределить портфельный бюджет по потокам ценности (Решениям и Эпикам).

 Полученные данные используются для финальной доработки бюджетов потоков ценности. Как правило, бюджеты корректируются два раза в год (либо каждый второй Интервал Планирования) с использованием Самобюджетирования (Инициативного Бюджетирования). Если этот процесс происходит реже, то расходы фиксируются на слишком длительный срок, что ограничивает гибкость. Может показаться, что еще более частые изменения бюджета повышают гибкость, но на самом деле, еще более частая смена бюджетов может создавать слишком большую неопределенность и неспособность взять на себя обязательства по какому-либо краткосрочному плану действий.

Программа

• Обзор бизнес-контекста и стратегических тем портфеля
• Краткое представление Эпиков и Решений
• Презентация процесса организации форума самобюджетирования
• Мероприятие «Самобюджетирование» (Инициативное Бюджетирование, Participatory Budgeting)
• Представление результатов и обсуждение следующих шагов
• Ретроспектива мероприятия Participatory Budgeting и создание элементов улучшений для внесения в беклог

Результат

• Портфель корректирует бюджеты для поддержки быстро меняющихся потребностей клиентов ирынка
• Лидеры получают информацию и мнения от нескольких заинтересованных лиц о существующих решениях и предлагаемых эпиках
• Согласованность и поддержка при трудном выборе объёмов и принятия решений по финансированию, повышая мотивацию, вовлеченность и моральный дух сотрудников
• Повышение ответственности за бюджеты, более реалистичные и достижимые бюджеты, (по сравнению с теми, которые навязываются сверху вниз)
• Обмен информацией и знаниями между лидерами и командами

Участники

• Команда Бережливого Управления Портфелем (LPM)
• Менеджмент Продукта и Менеджмент Решения
• Владельцы Эпиков
• Архитекторы Решения и Архитекторы Предприятия
• Владельцы Бизнеса
• Другие стейкхолдеры (финансы, маркетинг, продажи)

Примечание: SAFe рекомендует создавать группы из 5-8 участников для этого мероприятия.

Логистика

Частота: два раза в год (или каждый второй Интервал Планирования)

Продолжительность: около 4 часов при очном формате

5. КАЛЕНДАРЬ МЕРОПРИЯТИЙ SAFe®