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

23 мая 2022

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

Мероприятия команды Scaled Agile Framework

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

Цель

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

Программа

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

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

Результаты

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

Участники

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

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

Логистика

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

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

Ежедневный Стендап 

Цель

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

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

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

Программа

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

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

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

Примечание: Ежедневная Встреча не является отчетом перед руководством, Владельцем Продукта или Скрам Мастером!

Результаты

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

 Участники

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

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

Логистика

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

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

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

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

 Цель

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

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

Программа

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

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

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

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

Результаты

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

Участники

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

Логистика

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

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

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

Цель

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

Программа

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

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

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

Результаты

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

Участники

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

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

Логистика

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

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

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

Цель

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

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

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

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

Программа

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

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

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

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

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

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

Результаты

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

Участники

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

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

 Логистика

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

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

 

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

Мероприятия поезда Scaled Agile Framework

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

PI Planning

Цель

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

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

1 день

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

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

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

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

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

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

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

Результаты

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

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

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

Участники

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

Логистика

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

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

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

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

Scrum of Scrums

Цель

Синхронизация Скрам Мастеров (Scrum of Scrums, Скрам Скрамов, SoS) помогает координировать зависимости поезда (ART) и обеспечивает видимость прогресса и препятствий в достижении целей. Это мероприятие объединяет RTE, представителей каждой команды (обычно это Скрам Мастер) и других заинтересованных лиц для рассмотрения прогресса команд в достижении вех и целей Инкремента Программы, а также зависимостей между командами.

Программа

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

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

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

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

Результаты

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

Участники

  • RTE (фасилитирует SoS)
  • Скрам Мастера
  • Другие представители команд (если необходимо)
  • Профильные эксперты (если необходимо)

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

Логистика

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

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

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

PO Sync

Цель

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

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

Программа

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

Результаты

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

 Участники

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

RTE или Менеджер Продукта фасилитирует это мероприятие.

Логистика

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

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

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

ART Sync

 Цель

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

Программа

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

Результаты

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

Участники

  • RTE
  • Менеджеры Продукта
  • Владельцы Продукта
  • Скрам Мастера
  • Некоторые другие представители команд (при необходимости)
  • Другие заинтересованные лица (при необходимости)
  • Эксперты по профильным темам (при необходимости)

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

Логистика

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

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

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

System Demo

Цель

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

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

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

Программа

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

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

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

Результаты

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

Участники

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

Логистика

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

Продолжительность: 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.

Программа

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

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

 Результаты

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

Участники

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

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

Логистика

Подготовка к PI Планированию и Улучшение Беклога Программы должны вестись непрерывно и каждую неделю. Некоторые организации привязывают частоту проведения данного мероприятия к частоте проведения PO Sync, иногда делая это мероприятие продолжением (второй частью) 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 команды
  • RTE
  • Архитекторы Систем и Решения / Инженеры
  • Менеджеры Продукта и Владельцы Продукта
  • Владельцы Бизнеса

Логистика

Частота: в конце каждого Инкремента Программы

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

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

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

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

Мероприятия Решения Scaled Agile Framework

Architect Sync

Цель

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

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

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

Программа

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

Результаты

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

 Участники

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

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

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

Логистика

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

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

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

Solution Demo

Цель

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

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

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

Программа

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

Участники

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

Логистика

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

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

Пре- и Пост-PI Планирование 

Цель

Поезд Решения поддерживает и координирует различные Релизные Поезда Аgile, которые вовлечены в разработку решения. Планирование Инкремента Программы является критически важной точкой синхронизации для каждого Agile Release Train. Поэтому мероприятия Пре- и Пост-Планирования Инкремента Программы (Pre-and Post-PI Planning) на уровне Решения используются для подготовки поездов и поставщиков к PI Планированию и для согласования шагов после его проведения.

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

Пре- и Пост-PI Планирование позволяет Релизным Поездам и Поставщикам в крупных разработческих потоках ценности создать единый план для следующего Инкремента Программы. Эти мероприятия обрамляют PI Планирование Базового Уровня фреймворка (Essential SAFe), где происходит фактическое детальное планирование и где событие PI Планирование включено в календарь итерации Инноваций и Планирования.

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

Пост-PI Планирование используется для интеграции результатов планирования Релизных Поездов в Видение и Дорожную карту для более крупного потока ценности. В конце этого мероприятия должно быть достигнуто соглашение о Целях Инкремента Программы на уровне Решения, которые должны быть реализованы к концу Инкремента Программы и продемонстрированы на следующем Демо Решения.

Результат

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

Программа PrePI Planning

  • Результаты Инкремента Программы
  • Бизнес-контекст и Видение Решения
  • Беклог Решения
  • Финальная разбивка Капабилити на Фичи для Релизных Поездов на следующий Инкремент Программы

Программа PostPI Planning

  • Результаты мероприятия PI Планирования Релизных Поездов
  • Обзор плана, анализ рисков и голосование уверенности
  • Доработка планов при необходимости
  • Ретроспектива Планирования

Участники для обоих мероприятий

  • Представители Поезда Решения: Инженер Поезда Решения (STE), Менеджмент Решения, Архитектор Решения / Инженеры Решения, Команда Системы Решения, Релизный Менеджмент
  • Представители поездов и поставщиков: RTE от каждого поезда, Продуктовый Менеджмент, Архитекторы Систем/Инженеры Систем, клиенты и другие ключевые заинтересованные лица

Логистика

Частота: до и после каждого мероприятия «Планирование Инкремента Программы»

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

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

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

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

Solution Train Sync

Цель

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

Программа

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

Результаты

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

Участники

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

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

Логистика

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

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

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

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

Мероприятия Lean Portfolio Management

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

 Цель

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

Программа

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

Участники

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

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

 Логистика

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

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

Portfolio Sync 

Цель

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

 Программа

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

Участники

Обязательные участники: Топ-менеджеры, Владельцы Бизнеса, APMO, LACE

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

Логистика

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

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

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

Цель

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

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

Программа

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

Результат

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

Участники

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

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

Логистика

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

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

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