Обзор Итерации в SAFe: цели, формат, программа, фасилитация

«Немногие видят собственными глазами и чувствуют собственным сердцем»
— Альберт Эйнштейн

Для кого эта статья?

Материал предназначен для лидеров направлений, Менеджеров Продукта и Владельцев Продукта, Скрам Мастеров / Коучей Команды, участников Agile-команд и заинтересованных лиц, вовлечённых в работу с использованием SAFe Scrum.

Кратко о статье

Статья содержит практические рекомендации по проведению Обзора Итерации (Iteration Review) в SAFe Scrum: цели и ожидаемые результаты, входные данные, формат демонстрации, роли участников, программа, практики фасилитации (включая удалённый формат), а также типовые сложности и способы их преодоления.

Определение

Обзор Итерации (Iteration Review) – регулярное мероприятие SAFe Scrum, в ходе которого команда инспектирует инкремент итерации (созданный за период итерации результат), оценивает прогресс и уточняет Беклог Команды на основе обратной связи.

Назначение и ценность для бизнеса

Обзор Итерации – предпоследнее мероприятие итерации, на котором команда демонстрирует работающий инкремент (дополнительную ценность, которую команда создала за итерацию). Мероприятие помогает регулярно получать оперативную, контекстную обратную связь от команды и заинтересованных лиц, своевременно корректировать приоритеты и снижать риск того, что команда делает что-то «не то» или что-то «не так».

Что даёт Обзор Итерации?

• Фиксирует завершение итерации и подводит итоги.
• Делает вклад команды прозрачным и измеримым через работающий результат. Это позволяет членам команды испытывать обоснованное удовлетворение и гордость за результаты своей работы.
• Позволяет раньше скорректировать решение на основе обратной связи.
• Помогает уточнить приоритеты и дальнейшие шаги на основе продемонстрированного результата.

Цель мероприятия

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

Что демонстрируется на Обзоре Итерации?

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

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

Исходные данные и результаты Обзора Итерации

Исходные данные:

• цели Итерации (Iteration Goals) и цели Интервала Планирования (PI Objectives) – для понимания контекста и контроля прогресса;
• инкремент команды, развёрнутый в промежуточной среде (или в производственной, где это уместно/возможно);
• краткий перечень элементов, которые будут продемонстрированы (чтобы синхронизировать ожидания участников).

Результаты:

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

Подготовка к Обзору Итерации

Качественный Обзор Итерации начинается не «в день демонстрации», а ещё на мероприятии Планирования Итерации. Уже на планировании команда согласует, какие результаты будут показаны, в каком виде и какие сценарии лучше всего подтвердят ценность выполненной работы.

Такой подход снижает вероятность того, что демонстрация превращается в «сборку в последний момент», и помогает удерживать фокус на критериях выполненности (Definition of Done, DoD) и ожидаемом эффекте.

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

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

Если предполагается определённая тема встречи (например, фокус на конкретном пользовательском сценарии), имеет смысл заранее подготовить окружение: доступы, тестовые данные, стенды, вспомогательные материалы.

Чтобы обратная связь не терялась, до встречи стоит договориться, где будут фиксироваться вопросы и замечания, и кто отвечает за их перенос в беклог.

«Чем раньше команда договорится о том, что именно покажет в конце, тем проще удержать фокус итерации на ценности и критериях выполненности, а не на попытке собрать демо в последний момент.

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

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Как проходит Обзор Итерации: формат и программа встречи

Ниже представлен рекомендуемый «сквозной» сценарий Обзора Итерации. Его задача – удерживать понятную логику обсуждения: цели → демонстрация → обратная связь → незавершённая работа → обновление беклога.

Фасилитатору важно следить, чтобы встреча не превращалась в отчёт «по статусам», либо в длинный монолог-презентацию без возможности получить полезную обратную связь.

Для двухнедельной итерации рекомендованная продолжительность мероприятия – до 90 минут.

Фасилитацию Обзора Итерации обычно ведёт Скрам Мастер / Коуч Команды или Владелец Продукта, следя за соблюдением программы и времени.

1) Открытие: цели и общий контекст

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

Для согласования ожиданий участников в начале встречи целесообразно уточнить:

• какие элементы команда планирует демонстрировать;
• какие ограничения есть у демонстрации (например, частичная готовность интеграции, работа через feature-toggles, экспериментальный характер решения);
• где будет фиксироваться обратная связь (заметки, доска, онлайн-инструмент), чтобы она не потерялась.

Скрам Мастер / Коуч Команды, являясь основным ведущим или нет, обязательно помогает удерживать структуру и договорённости, а также обеспечивает прозрачность обсуждения (чтобы всем было понятно, что именно показано, что принято к сведению и что станет следующим шагом).

2) Демонстрация выполненной работы (работающий инкремент)

Команда последовательно демонстрирует элементы, завершённые в рамках Итерации:

• пользовательские Истории;
• результаты Спайков, если они проводились;
• результаты рефакторинга;
• выполненные нефункциональные требования (НФТ, NFR);
• другие виды завершённой работы.

Демонстрация должна отвечать на главный вопрос: какую ценность команда добавила в продукт/решение за итерацию и как это приближает её к достижению целей?

Рекомендованный формат демонстрации

• Демонстрации выполняются на базе работающей, протестированной системы, предпочтительно в промежуточной среде, максимально приближенной к производственной.
• Основной формат – показ поведения системы и ключевых сценариев. Слайды допустимы только как поддержка (например, для контекста), но не должны заменять демонстрацию работающего результата.
• Если для Спайков и нефункциональных требований нет пользовательского интерфейса, допустима краткая демонстрация через выводы, измерения и артефакты: результаты тестов производительности, протокол эксперимента, сравнительные замеры, рекомендации, чек-листы, отчёты стратегического анализа и т.д.
• Если команда демонстрирует «работу в процессе», важно явно обозначить статус и ограничения, чтобы обратная связь была корректной и применимой.

«Полезно заранее договориться о порядке демо и отслеживать временные рамки для каждого выступления – это повышает управляемость мероприятия и дисциплинирует подготовку.

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

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Рисунок 1. Agile команда демонстрирует работающий, протестированный инкремент

3) Вопросы и обратная связь заинтересованных лиц

Основная задача этого шага – получить применимую обратную связь по продемонстрированным результатам:

• что работает и соответствует ожиданиям?
• что требует корректировки?
• что нужно уточнить до следующей итерации?
• какие новые идеи или гипотезы появились после просмотра результата?

Важно, чтобы обратная связь фиксировалась сразу и явно (в заметках или онлайн-инструменте), а не оставалась на уровне устных комментариев.

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

4) Разбор незавершённых Историй

После демонстрации команда анализирует, какие Истории/цели не завершены и почему.

Обычно это позволяет выявить:

• препятствия или риски,
• неверные предположения,
• изменения приоритетов,
• ошибки в оценках,
• избыточные обязательства (over-commitment)
• иные проблемы (сбои) в Потоке Команды (Team Flow).

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

5) Риски, препятствия, зависимости и уточнение Беклога Команды

Завершать Обзор Итерации полезно «приземлением» итогов в управляемые действия:

• уточнить новые риски, препятствия и зависимости, которые могут повлиять на достижение целей Интервала Планирования;
• при необходимости применить ROAM к ключевым рискам (Resolved – решённые, Owned – взятые, Accepted – принятые, Mitigated – смягчённые/управляемые);
• на основе обратной связи и выводов обновить Беклог Команды: уточнить формулировки, приоритеты, критерии приёмки, владельцев и следующие шаги.

Смысл финального шага – сделать так, чтобы обратная связь не «осела» в заметках, а была переведена в конкретные элементы беклога или понятные действия (в зависимости от типа замечаний).

Рисунок 2. Пример программы Обзора Итерации

Участники Обзора Итерации

В Обзоре Итерации обычно участвуют:

• Владелец Продукта;
• Скрам Мастер / Коуч Команды;
• все члены команды;
• заинтересованные лица команды и/или эксперты предметной области (SME);
• при необходимости – представители других команд или поездов (Agile Release Train, ART).

Важно: Заинтересованные лица уровня Поезда (Agile Release Train, ART) могут присутствовать на Обзоре Итерации. При этом интеграцию, сквозные сценарии и прогресс на уровне решения обычно эффективнее рассматривать на последующем мероприятии Демонстрации Системы (System Demo).

Фасилитация (активное ведение) Обзора Итерации: практики

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

Задача фасилитатора (ведущего) – удерживать структуру встречи, темп и фиксацию договорённостей. Роль Скрам Мастера / Коуча Команды здесь – не обеспечить формальное «проведение собрания», а обеспечить ритм, прозрачность обсуждения и согласие участников в части договорённостей.

С практической точки зрения фасилитация включает:

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

Практики, которые помогают удерживать темп и фокус

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

Если обзор проходит в удалённом формате

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

За 1-2 дня до встречи фасилитатор направляет участникам предложение подготовить вопросы к демонстрации и проверить доступы к средам и материалам. Это снижает потери времени на мероприятии и помогает быстрее перейти к предметному обсуждению.

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

Для распределённых команд полезна короткая синхронизация перед обзором (15-20 минут): участники подключаются к общему созвону, согласуют порядок демонстраций, проверяют готовность окружения и сценариев.

«Для ведущего в онлайн формате особенно важно контролировать вовлечённость участников в процесс. Организационные проблемы в процессе ведения – худший враг вовлечённости. Поэтому, лучше заранее определить, кто и в каком порядке выступает с демонстрацией, и продублировать это в командном канале/чате – это сделает процесс более управляемым.»

Алексей Ионов, ASPC, Lean-Agile коуч организаций, Ионов и Партнеры

Действия после мероприятия

• обновить Беклог Команды по итогам обратной связи;
• зафиксировать контекст по незавершённым историям: что произошло и какие факторы повлияли;
• перенести ключевые наблюдения на Ретроспективу Итерации и там сформулировать улучшения для следующих итераций;
• уточнить, какие результаты стоит/ещё рано показать на Демонстрации Системы (System Demo), особенно при наличии интегрированной работы;
• вернуть незавершённую работу в Беклог Команды для приоритизации в будущем.

Типовые сложности и как с ними работать

Ситуация 1: команда говорит, что «нечего показывать»

Что помогает:

• поощрять демонстрацию «работы в процессе», если функциональности достаточно для получения обратной связи;
• напоминать, что цель демо – обратная связь и обучение, а не «идеальная подача»;
• заранее, еще на Планировании Итерации, согласовывать, что именно команда будет показывать в конце итерации, чтобы демо не становилось сюрпризом.

Ситуация 2: команда регулярно не достигает целей итерации

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

Что помогает:

• составить краткий перечень фактически доставленной ценности и проверить, входила ли доставленная ценность в цели прошедшей итерации;
• на следующем Планировании Итерации помочь команде формулировать цели итерации через ценность, которую реально планируется доставить и (где уместно) выпустить.

Ситуация 3: обратная связь на Обзоре есть, но в беклоге ничего не меняется

Что помогает:

• в конце встречи выделить 5-10 минут на согласование: какие замечания превращаются в элементы беклога, кто владелец и какой следующий шаг;
• фиксировать обратную связь сразу в рабочем инструменте (или в заметках с последующим переносом) и проговаривать формулировки, чтобы избежать разных трактовок;
• разделять «идеи на будущее» и «обязательные корректировки», чтобы не перегружать ближайшее планирование итерации.

Ситуация 4: демонстрация затягивается, и не остаётся времени на обсуждение беклога будущей итерации

Что помогает:

• согласовать ожидаемую длительность каждого выступления заранее и придерживаться её;
• оставлять отдельное время на вопросы и обратную связь после каждого демо, а не переносить все обсуждения в конец мероприятия;
• если возникает спор, фиксировать вопрос как пункт для последующей проработки и возвращаться к нему в рамках обсуждения беклога или отдельной сессии улучшения/уточнения беклога.

Практические рекомендации (кратко)

• Запланируйте подготовку к Обзору заранее и удерживайте её продолжительность в разумных пределах – как правило, не более двух часов на итерацию.
• Установите максимальную плановую продолжительность мероприятия – около 90 минут.
• Минимизируйте использование слайдов; Обзор Итерации предназначен для получения обратной связи по работающим, протестированным инкрементам команды.
• Убедитесь, что завершённые Истории соответствуют Определению Выполненности/Завершённости (Definition of Done, DoD).
• Демонстрируйте незавершённые Истории, если функциональности достаточно для получения обратной связи.
• Поощряйте конструктивную обратную связь и отмечайте достижения команды.
• Если ключевой стейкхолдер не может участвовать, Владелец Продукта связывается с ним отдельно, чтобы сообщить о прогрессе и получить обратную связь (при этом само мероприятие не отменяется и не переносится).

Примечание о Непрерывной Доставке (CD)

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

Вопросы и Ответы

Зачем компании нужен Обзор Итерации в SAFe Scrum?

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

Что обязательно должно быть на Обзоре Итерации?

Цели итерации, демонстрация работающего результата и фиксация обратной связи, которая затем отражается в Беклоге Команды.

Можно ли показывать незавершённую работу на Обзоре Итерации?

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

Кто отвечает за фасилитацию (активное ведение) Обзора Итерации и кто демонстрирует?

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

Какой ориентир по длительности мероприятия?

Для двухнедельной итерации обычно ориентируются на мероприятие продолжительностью до 90 минут. Если вы сможете укладываться в 60 минут – это будет хорошим результатом.

Чем Обзор Итерации отличается от Ретроспектива Итерации (Iteration Retrospective)?

Обзор Итерации фокусируется на демонстрации результата и обратной связи по продукту/решению, а Ретроспектива Итерации – на улучшении способа работы команды: практик, взаимодействия, качества, потока, предсказуемости.

Оригинал: Scaled Agile, Inc. (вендор), статья «Iteration Review». Материал не является официальным переводом.

Перевод и адаптация: Алексей Ионов, Lean-Agile коуч организаций, Advanced SPC, Ионов и Партнеры. В подготовке статьи использованы дополнительные материалы и опыт практического использования SAFe Scrum.

Основано на версии статьи от 23.11.2022.

Почитать дополнительно:

Agile Команда
Команда SAFe Scrum
Команда SAFe Kanban
Поток Команды
Владелец Продукта
Скрам Мастер / Коуч Команд
Беклог Команды
Истории
Цели на PI
5 видов ценности целей команд на Интервал Планирования
Мероприятия в SAFe (включая мероприятия команды)
Ретроспектива Итерации

© «Ионов и Партнеры» (ИП Ионов Алексей Константинович), 2018-2025. Все права защищены. Цитирование материалов и размещение ссылок на материалы для формирования сторонних баз знаний, рубрикаторов или агрегаторов допускается только с письменного согласия «Ионов и Партнеры».

SAFe® and Scaled Agile Framework® are registered trademarks of Scaled Agile, Inc.