Ретроспектива Итерации (Iteration Retrospective) в SAFe

«Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.» – Agile Манифест

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

Статья содержит практические рекомендации по проведению Ретроспективы Итерации в SAFe: цель мероприятия, входные данные и результаты, рекомендуемая продолжительность, структура мероприятия (в частности использование метрик и работу с улучшениями), форматы проведения и типовые сложности проведения (фасилитации).

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

Статья будет полезна для Скрам Мастеров/Коучей Команд, Владельцев Продукта и участников Agile‑команд в SAFe (Scrum или Kanban); также будет для RTE и руководителей, поддерживающих непрерывные улучшения.

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

Ретроспектива Итерации – регулярное мероприятие на уровне команды, на котором участники:

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

Ретроспектива Спринта и Ретроспектива Итерации: в чём разница?

По сути, это одно и то же событие Скрама – ретроспектива команды в конце рабочего цикла. Разница – в терминологии и контексте фреймворка: в Скраме используется термин «Спринт» (Sprint), а в SAFe базовой единицей планирования и исполнения на командном уровне является Итерация (Iteration). Поэтому в SAFe более корректно использовать термин «Ретроспектива Итерации»: так вы не будете смешивать термины SAFe (Цели Итерации, Планирование Итерации, Обзор Итерации и др.) с базовой терминологией Скрам и снизите риск разночтений.

Термин «Итерация» начал активно использоваться для обозначения периода планирования команды с появлением Экстремального Программирования (XP). Если вы говорите о ретроспективе команды в SAFe, рекомендую использовать полный термин «Ретроспектива Итерации», чтобы все участники одинаково понимали, к какому командному циклу и каким артефактам SAFe относится мероприятие. Связано это с тем, что в SAFe мероприятие ретроспективы можно (и нужно!) проводить на разных масштабах, поэтому лучше избегать путаницы.»

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

Когда проводится Ретроспектива

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

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

Зачем нужна Ретроспектива Итерации

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

Исходные данные и результаты Ретроспективы

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

На ретроспективу, как правило, выносят:

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

Результаты

По итогам успешной ретроспективы команда получает:

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

Подготовка Ретроспективы

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

Рекомендации Алексея Ионова, Advanced SPC, по подготовке фасилитации:

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

Как проходит Ретроспектива Итерации в SAFe: продолжительность, программа и шаги

В ретроспективе участвует вся команда. Скрам Мастер / Коуч Команды открывает мероприятие: напоминает цель ретроспективы и правила безопасного обсуждения, объявляет программу и выбранный формат работы.

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

Часть 1. Количественный обзор (метрики и факты)

Цель части – выровнять понимание результатов только что завершённой итерации и создать общий контекст для обсуждения улучшений.

1. Проверка улучшений с прошлой ретроспективы.
Команда просматривает существующие Истории улучшений/пункты действий: что выполнено, что не выполнено, что мешало, какой эффект заметен.

2. Оценка достижения целей итерации (да/нет).
Команда фиксирует простой факт достижения целей (да/нет) – это помогает быстро перейти к обсуждению причин и действий.

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

Примеры метрик, на которые команда может обращать внимание:

• метрики потока (например, скорость/пропускная способность потока, загрузка потока, распределение потока),
• количество обработанных дефектов,
• покрытие автоматизированными тестами,
• стабильность сборок/непрерывная интеграция (CI) и т.д.

Часть 2. Качественный обзор (обсуждение и улучшения)

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

1. Что получилось?
Команда фиксирует удачные («сработавшие») практики и решения: что нам «понравилось, как мы делали» (процесс) или «понравилось, что мы сделали» (результат)?

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

3. Что мы можем сделать лучше в следующий раз?
Команда формулирует предложения по улучшениям в виде изменений и/или конкретных действий на следующую итерацию.

Здесь очень важно удерживать фокус на том, что команда реально может контролировать сама. Для этого, формулируйте действия в едином формате: например, «Наша команда в следующей итерации может/будет/сделает ______».

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

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

Завершение: приоритизация и фиксация в Беклоге Команды

После обсуждения команда:

• голосует и выбирает 1-2 ключевых улучшения на следующую итерацию (дополнительно, при необходимости, возможны «малые» пункты, если они не перегружают команду);
• оформляет выбранное как Истории улучшений и добавляет их в Беклог Команды;
• обсуждают наиболее вероятных исполнителей внутри команды и критерии выполненности/завершённости, чтобы прогресс был отслеживаемым, оценивают сложность в относительных единицах;
• при выявлении значимой повторяющейся проблемы – проводит анализ корневых причин и фиксирует корректирующие действия (см. раздел «Решение проблем» в статье Инспект-Адапт (Inspect & Adapt);
• в случае уже зафиксированных новых «быстрых» договорённостей – голосует за их включение в правила работы команды и берёт на себя ответственность за их соблюдение.

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

Рисунок 1. Пример программы Ретроспективы Итерации

Форматы проведения ретроспективы (варианты для качественной части)

Команда в том числе может использовать один из распространённых форматов:

• Индивидуальный: участники пишут на стикерах, затем схожие стикеры группируются.
• Благодарности: участники отмечают, кто и чем был полезен команде.
• Одно слово: каждый выбирает одно слово, описывающее итерацию.
• Оценка: команда оценивает итерацию по шкале от 1 до 5 и обсуждает, как сделать следующую итерацию «на 5».
• Простой: открытая дискуссия с фиксацией результатов по 3м разделам:
  1. Что получилось;
  2. Что не получилось;
  3. Что мы можем сделать лучше в следующий раз.

Простой формат – один из самых распространённых: участники размещают стикеры по разделам и проводят структурированное обсуждение и мозговой штурм. Этот формат легко внедряется и делает видимыми все достижения и сложности.

При необходимости можно расширять набор вопросов, группировать их по темам и менять формулировки. Например, использовать формат 4Ls (Что понравилось (Liked) – Чему научились (Learned) – Чего не хватило (Lacked) – Чего хотелось бы (Longed for)), как показано на рисунке 2.

Рисунок 2. Пример результатов ретроспективы итерации в формате 4Ls.

Как поддерживать вовлечённость участников и преодолевать типовые сложности

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

Подходы, которые работают на практике:

• ротация фасилитатора ретроспективы внутри команды (например, когда ретро проводит Скрам Мастер другой команды или кто-то из участников);
• выбор формата ретроспективы очередным ведущим;
• тематические ретроспективы (например, качество, взаимодействие, поток, предсказуемость, DevOps-практики и т.д.).

Приведённые выше подходы помогают повысить совместную ответственность за процесс и сохранить практическую ценность ретроспектив для участников.

Типовые ситуации и приёмы фасилитатора:

• Тема вне зоны влияния команды.

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

• Преобладание негатива и «разбор полётов».

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

• Улучшения не выполняются, а ретроспектива «буксует».

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

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

Участники ретроспективы

В Ретроспективе обычно участвуют:

• Владелец Продукта (Product Owner, PO);
• Скрам Мастер / Коуч Команды (Scrum Master/Team Coach);
• все члены команды;
• при условии одобрения со стороны команды и обеспечения безопасности с точки зрения возможного давления, на отдельные ретроспективы также можно приглашать:
  • при необходимости – заинтересованных лиц и/или экспертов в предметной области;
  • по согласованию – представителей других Agile-команд или Поездов (Agile Release Train, ART), если это помогает улучшениям и не снижает открытость обсуждения.

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

Дополнительные возможности для улучшений (DevOps и Конвейер Непрерывной Доставки)

По мере развития DevOps и Конвейера Непрерывной Доставки (Continuous Delivery Pipeline) у Agile-команд появляется больше возможностей для улучшений, включая:

• развитие встроенного качества;
• повышение автоматизации тестирования (включая разработку на основе тестирования — test-driven development, TDD и разработку на основе поведения — behavior-driven development, BDD) и улучшения непрерывной интеграции;
• автоматизацию развёртывания;
• разделение развёртывания и выпуска (см. Выпуск по требованию)
• внедрение телеметрии и механизмов восстановления системы.

Lean-Agile лидеры поддерживают выделение времени в каждой итерации на развитие навыков и улучшения. Дополнительные возможности для этого даёт Итерация Инноваций и Планирования (IP Iteration).

Рекомендации для удалённой ретроспективы (когда у вас распределённая команда)

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

Краткие вопросы и ответы

Что является главным результатом Ретроспективы Итерации в SAFe?

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

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

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

Кто должен присутствовать на Ретроспективе?

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

Сколько времени должна занимать Ретроспектива?

SAFe рекомендует продолжительность до 1 часа на двухнедельную итерацию. Для иной продолжительности итерации временные рамки обычно масштабируются пропорционально.

Какие метрики лучше обсуждать на Ретроспективе?

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

Сколько улучшений брать в работу после Ретроспективы Итерации?

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

Что делать, если проблема повторяется из итерации в итерацию?

Провести анализ корневых причин и перевести решение в конкретные шаги: владелец, критерии выполненности (DoD), проверка эффекта на следующей ретроспективе.

Какие форматы Ретроспективы лучше использовать для зрелой команды?

Тематические ретроспективы (качество/поток/DevOps), 4Ls, «оценка 1–5», ротация ведущего и эксперименты с вопросами.

Что делать с улучшениями после Ретроспективы (кто владелец и как отслеживать эффект)?

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

Нужно ли проводить Ретроспективу, если итерация прошла «обычно» и без заметных проблем?

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

Как понять, что Ретроспектива была полезной?

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

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

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

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

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

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

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

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