Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом

Почему ретроспективы не работают?

Многие команды недолюбливают спринт‑ретроспективы, считая их бесполезными или формальными встречами, которые не приводят к реальным изменениям. Основные причины этого недовольства включают:

• Отсутствие видимого эффекта от ретроспектив. Команда обсуждает одни и те же проблемы, но ничего не меняется.

• Доминирование отдельных участников. Самые громкие голоса в комнате диктуют повестку, в то время как остальные просто соглашаются или молчат.

• Нехватка объективных данных. Обсуждение строится на субъективных впечатлениях, а не на фактах.

• Слабая модерация. Без четкой структуры обсуждение превращается в хаос или бессмысленный обмен мнениями.

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

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

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

Чтобы ретроспектива была продуктивной, она должна основываться на данных, а не на субъективных ощущениях. Использование объективных показателей позволяет:

• Выявить реальные узкие места и причины проблем.

• Исключить догадки и спекуляции.

• Обеспечить прозрачность и равноправие в обсуждениях.

• Сформировать конкретные действия для улучшения процессов.

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

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

1. Точность планирования — насколько команда выполнила запланированные задачи. Отклонение от планов может указывать на проблемы с оценкой задач или изменяющиеся приоритеты.

2. Объем работы в процессе (WIP) — сколько задач команда выполняла одновременно. Если этот показатель слишком высок, возможно, команда перегружена и нужно скорректировать объем работы.

3. Цикл поставки (Cycle Time) — сколько времени проходит от начала работы над задачей до ее завершения. Если цикл слишком длинный, это может указывать на узкие места в процессе разработки.

4. Средний размер PR — если пул‑реквесты слишком объемные, это может замедлять код‑ревью и интеграцию изменений.

5. Количество доработок после код‑ревью — показатель качества кода и его соответствия стандартам команды.

6. Процент завершенных задач без блокеров — помогает выявить, насколько часто задачи тормозятся из‑за зависимостей.

7. Обратная связь от команды (Sentiment Data) — позволяет выявить субъективное восприятие процесса.

Эти показатели дают четкое представление о том, что в работе команды идет хорошо, а где есть проблемы.

Фреймворк 4L’s для анализа спринта

Одним из наиболее эффективных подходов к проведению ретроспектив является метод 4L»s (Liked, Learned, Lacked, Longed For). Он помогает структурировать обсуждение и направить его на поиск конкретных улучшений.

Что получилось? (Liked)

Этот раздел фиксирует положительный опыт команды за спринт. Сюда могут входить:

• Успешное выполнение запланированного объема работы.

• Повышение точности планирования.

• Ускорение цикла поставки.

• Снижение числа багов и доработок.

• Улучшение взаимодействия между командами.

Пример:

• Планирование было точным на 78 процентов.

• Цикл выполнения PR сократился, 95 процентов PR оказались меньше 200 строк кода.

• Внедрение автоматизации позволило сэкономить два дня работы.

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

Чему научились? (Learned)

Этот раздел позволяет команде проанализировать, какие новые инсайты появились в процессе работы. Например:

• Улучшение процесса код‑ревью благодаря новым инструментам.

• Влияние новых технологий на производительность.

• Выявление новых факторов, влияющих на выполнение задач.

Пример:

• Уровень внедрения TypeScript вырос на 35 процентов, что сократило количество багов.

• Доля работы над новыми фичами увеличилась на 25 процентов.

• Анализ прогнозов показал, что проект может задержаться на одну‑две недели.

Фиксация этих инсайтов помогает учитывать их в будущих спринтах и корректировать подход.

Чего не хватало? (Lacked)

Этот раздел помогает команде выявить препятствия, мешающие эффективной работе. Например:

• Недостаток ресурсов в ключевых командах.

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

• Слишком долгие согласования и зависимости между командами.

Пример:

• Объем работы в процессе увеличился на 15 процентов, что замедлило выполнение задач.

• На проекте ABC не хватало специалистов, что повлияло на сроки.

• Среднее время ожидания код‑ревью увеличилось на 15 процентов.

Выявление таких проблем позволяет принимать меры для их устранения.

Чего хотелось бы? (Longed For)

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

Пример:

• Автоматизация код‑ревью для ускорения процесса.

• Перераспределение ресурсов, чтобы снизить нагрузку на ключевые команды.

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

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

Как провести эффективную ретроспективу: пошаговый процесс

1. Начало встречи

   • Обсудите цели спринта и ключевые результаты.

   • Установите позитивный настрой.

2. Анализ данных

   • Представьте собранные метрики.

   • Обсудите тренды и выявленные паттерны.

3. Обсуждение по фреймворку 4L’s

   • Что получилось?

   • Чему научились?

   • Чего не хватало?

   • Чего хотелось бы?

4. Определение действий

   • Выберите два‑три ключевых улучшения.

   • Назначьте ответственных за внедрение.

5. Закрытие встречи

   • Подведите итоги и подтвердите список улучшений.

   • Поблагодарите команду за участие.

Как внедрять изменения после ретроспективы

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

• Все решения должны быть записаны и опубликованы.

• Улучшения должны иметь ответственных и дедлайны.

• Через один‑два спринта нужно оценить, помогли ли изменения.

Заключение

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

Если ваша команда хочет повысить точность планирования, сократить время выполнения задач и минимизировать риски, стоит ориентироваться на объективные показатели и конкретные действия после ретроспективы.

Если вы хотите внедрить data‑driven ретроспективы, повысить предсказуемость разработки и улучшить процессы в команде, приглашаю на менторство. Помогу выстроить эффективные ретроспективы, оптимизировать планирование и устранить узкие места в работе.

Также актуальные навыки для улучшения процессов в команде можно получить на открытых уроках в Otus:

• 5 февраля: «Как не треснуть при росте: расширяем команду по уму». Подробнее

• 6 февраля: «Цифры решают все: как внедрение метрик и KPI ускоряет достижение целей». Подробнее