
Collegium publicum
Да, внимательные читатели скажут, что я уже писал о ретроспективе. Да, писал и эта статья не устарела. Но мир движется вперёд, а вместе с ним и искусство управления проектами. Давайте разберём современный подход к проведению ретроспективы на основе данных.
Проблемы классического подхода к ретроспективе
Большинство встреченных мной команд (как и собранных), ретроспективы недолюбливали и считали бесполезными, не приводящими к реальным изменениям. Если выделить ключевые причины, это:
- На каждом ретро обсуждаются одни и те же проблемы, которые на деле не решаются руководством.
- Выступают только те, кто «громче всех кричит». Остальные изображают интерес.
- Обсуждение сосредоточено на субъективных ощущениях и мнениях, а не на фактах.
- Если встречи слабо модерируются, они имеют свойство превращаться в бесструктурные перебранки.
- Отсутствие времени на ретро у сотрудников. Им надо пилить таски1, а мы их отвлекаем часом бессмысленной болтовни.
Ключевая мысль — если команда не видит пользы в ретро, она потеряет к ней интерес. Но если организовать всё правильно, можно избежать этого эффекта и превратить ретроспективу в мощный инструмент.
Как превратить ретроспективу в полезное мероприятие?
Ответ в заголовке статьи. Она должна основываться на данных. Тогда получится:
- Вычислить реальные, а не мнимые узкие места в работе команды.
- Исключить догадки и спекуляции.
- Обеспечить прозрачность и равноправие в обсуждениях.
- Сформировать конкретные действия для улучшения процессов.
И прикол в том, что перед ретро надо готовить отчёт со значениями ключевых метрик, о которых мы поговорим ниже.
Какие метрики собирать?
- План-факт — в какие трудозатраты оценили задачи, сколько потратили по факту.
- Time to Market — сколько времени проходит между поступлением задачи в работу аналитику до релиза в прод. Считаю одной из ключевых метрик2 для оценки продакшена.
- Средний размер PR — я считаю, что разработчики должны коммитить относительно часто относительно небольшие объёмы кода. Так проще ревьюить и ниже риски.
- Количество доработок после тестирования — показатель качества кода и его соответствия стандартам команды.
- Процент завершенных задач без блокеров — помогает выявить, насколько часто задачи тормозятся из‑за зависимостей.
- Change Failure Rate — количество багов на релиз.
- Time to Restore Service — время на фикс бага в проде.
В целом, этих метрик достаточно, чтобы составить достаточно чёткое представление о качестве работы команды.
Фреймворк 4L’s для анализа спринта
Самым современным и технологичным фреймворком для ретроспектив является метод 4L’s (Liked, Learned, Lacked, Longed For). Он помогает структурировать обсуждение и направить его на поиск конкретных улучшений.
Что получилось? (Liked)
Иными словами, «что было хорошего за спринт, чего удалось добиться»:
- Что запланировали, то и сделали, нет долгов.
- Точно спланировали сроки.
- Time to Market улучшился.
- Стало меньше возвратов с код-ревью и с тестирования, меньше багов.
- Команды стали лучше взаимодействовать.
Пример:
- Планирование было точным на 80 %.
- Цикл выполнения PR сократился, 95 % PR оказались меньше 100 строк кода.
- Внедрение автоматизации позволило сэкономить на тестировании два дня работы.
Обязательно нужно разбирать причины успехов. Это мотивирует команду.
Чему научились? (Learned)
Этот раздел позволяет команде проанализировать, какие новые инсайты появились в процессе работы. Например:
- Внедрили новый инструмент для код-ревью, уменьшилось время на код-ревью, повысилось его качество.
- Выявили новые факторы, влияющие на время работы над задачами.
Пример:
- Уровень внедрения TypeScript вырос на 35 %, что сократило количество багов.
- Доля работы над новыми фичами увеличилась на 25 %.
- Анализ прогнозов показал, что проект может задержаться на две недели.
Очень важно фиксировать выученные уроки, чтобы учесть их при планировании следующих спринтов.
Чего не хватало? (Lacked)
Здесь обсуждаем препятствия, которые уменьшили эффективность команды, мешали достичь целей спринта:
- Недостаток специалистов или компетенций в команде.
- Ключевые специалисты были слишком сильно загружены работой.
- Долгие согласования работы с соседними командами.
Пример:
- Нам накидали новых задач в спринт, а у прожекта не хватило яиц заставить заказчика вытащить из спринта эквивалентные по объёму таски.
- Из-за неполного штата специалистов, сроки замедлились.
- Загруженность тимлида, медленный код-ревью.
Выявляем такие участки — принимаем меры по их устранению.
Чего хотелось бы? (Longed For)
Тут спрашиваем у команды рекомендации по улучшению.
Пример:
- Внедрение линтеров3 для контроля качества оформления кода.
- Перераспределение ресурсов, чтобы снизить нагрузку на ключевые команды.
- Добавить несколько новых программистов уровня мидл или выше.
Слушаем предложения, формируем список улучшений на будущее.
Как провести эффективную ретроспективу: пошаговый процесс
Так что в итоге? Как проводить ретроспективу, основанную на данных?
- Начало встречи
- Обсудите, какие были цели спринта, каких достигли ключевых результатов.
- Установите позитивный настрой.
- Анализ данных
- Представьте собранные метрики.
- Обсудите тренды и выявленные паттерны.
- Обсуждение по фреймворку 4L’s
- Что получилось?
- Чему научились?
- Чего не хватало?
- Чего хотелось бы?
- Определение действий
- Выберите два‑три ключевых улучшения.
- Назначьте ответственных за внедрение.
- Закрытие встречи
- Подведите итоги и подтвердите список улучшений.
- Поблагодарите команду за участие.
Как внедрять изменения после ретроспективы
Предложения по улучшению нужно обязательно фиксировать. В частности:
- Все решения должны быть записаны и опубликованы. Заведите в Конфлю или Ноушене специальный раздел под ретро.
- Улучшения должны иметь ответственных и дедлайны.
- Через один‑два спринта нужно оценить, помогли ли изменения, зафиксировать работающие как постоянные практики, отказаться от не оправдавших себя.
Заключение
Если подходить к ретроспективе структурно и основываться на данных, она не будет формальной встречей.
Подкрепление наблюдений данными отлично работает.
В целом, применяйте и извлекайте пользу.
- Так не везде. Работал в одной весёлой компании, где сотрудники открыто говорили, что предпочтут час поразговаривать, чем час впахивать. ↩︎
- Артём Летюшев спрашивал меня в Линке, полностью ли эта метрика характеризует эффективность работы команды. К сожалению, нет. Команда может с большим энтузиазмом и отличным TTM пилить то, что не нужно рынку или заказчикам. Но эта проблема за рамками настоящей статьи. ↩︎
- Линтер (от англ. слова lint) — это инструмент программирования, который используется для анализа исходного кода программного обеспечения с целью выявления потенциальных проблем, структурных ошибок, стилевых нарушений и других недочётов. Линтеры облегчают процесс разработки, помогая программистам улучшить качество своего кода, делая его более читаемым, поддерживаемым и безопасным. ↩︎