Ретроспектива это в Agile: форматы для гибридных команд и Derby-заметка

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

Если вы только входите в IT или вы джун с годом опыта, ретро выглядит как странный корпоративный кружок “поговорим о чувствах”. На деле это техобслуживание процесса: как смена масла, только для команды. И да, в гибриде (часть в офисе, часть на удалёнке) ретроспектива agile ломается первой: кто-то не слышит, кто-то молчит, кто-то «потом допишет в чат». В итоге вы не улучшаете процесс, а аккуратно консервируете проблемы.

Мой практический ориентир: хорошая ретроспектива — та, после которой у команды появляется измеримое действие и владелец этого действия. Плохая — та, после которой остаётся красивый Miro-борд и ощущение, что “ну мы поговорили”. Ирония в том, что рынок это ценит: по вакансиям в РФ ретро и “continuous improvement” чаще всего требуют от Scrum Master/Agile Coach/PM, но по факту даже продуктовые команды ждут, что вы умеете как проводить ретроспективы без цирка.

Что именно делает ретроспектива (и почему бизнесу не всё равно)

Тезис: ретро снижает стоимость ошибок — особенно для новичков

Обоснование: в спринте ошибки — это не “ошибка навсегда”, а “ошибка на 1–2 недели”. Если команда регулярно вытаскивает причины сбоев (не симптомы), она меньше тратит времени на переделки, ручные проверки, “почему опять сломалось” и вечные согласования. В гибридных командах основной налог — коммуникационный: больше потерь на контекст, дольше реакция, выше риск “мы думали, ты сделаешь”.

Практический вывод: задача ретроспективы — не «высказаться», а договориться об эксперименте, который улучшит скорость/качество/предсказуемость.

Подводный камень: превращать ретро в отчёт перед руководством. Как только люди понимают, что за слова прилетит, ретро заканчивается. Остаётся театральная постановка “у нас всё нормально”.

Тезис: ретро — это часть цикла PDCA, а не “разговорная терапия”

Обоснование: классика улучшений — Plan–Do–Check–Act (планируй–делай–проверяй–действуй). Sprint Review смотрит на продукт, а ретроспектива agile — на способ работы. Это разные оси.

Практический вывод: если после ретро нет “Act” (конкретного изменения), вы делаете “Check ради Check”.

Подводный камень: брать 10 улучшений за раз. На практике взлетает 1–3, зато доведённые до конца.

Форматы ретроспектив Agile: что выбрать для гибрида

Правило гибрида №1: сначала выравниваем голос, потом рисуем стикеры

Если часть команды в переговорке, а часть в Zoom/Яндекс Телемост — удалённые автоматически превращаются в “картинки на телевизоре”. Поэтому базовый лайфхак: даже офисные подключаются каждый со своего ноутбука (наушники — да), а в переговорке остаётся только один “общий” микрофон как запасной вариант. Это мелочь, но она решает половину токсичных ретро.

Формат	Когда подходит	Плюсы	Минусы/риски	Для гибрида
Start / Stop / Continue	Команда “нормальная”, но буксует	Быстро, понятно новичкам	Скатывается в “перечень хотелок”	Отлично, если заранее есть таймбоксы
Glad / Sad / Mad	Много эмоций, конфликт/выгорание	Вытаскивает напряжение	Без фасилитации превращается в жалобную книгу	Нужны правила безопасности и модерация
4L (Liked, Learned, Lacked, Longed for)	Хочется баланса “факты+выводы”	Хорошая структура, много инсайтов	Может затянуться	Подходит, если команда дисциплинирована
Timeline / Journey	Спринт был “как сериал”, много событий	Восстанавливает картину причин	Риск уйти в детали	Супер, если у удалённых плохой контекст
5 Why (5 почему)	Есть явная проблема (например, срывы сроков)	Идёт в причину, а не симптом	Можно “обвинить человека”, если неаккуратно	Работает, если есть нейтральный фасилитатор

Как проводить ретроспективы: сценарий на 60 минут (универсальный)

Set the stage (5 мин): цель встречи + правила. Например: “критикуем процесс, не людей”.
Сбор наблюдений (10–15 мин): выбранный формат (Start/Stop/Continue или 4L). Пишем молча 3–5 минут, потом группируем.
Выбор темы (5 мин): голосование точками (dot-voting). Берём топ-1–2.
Разбор причины (15–20 мин): 5 Why / fishbone (диаграмма Исикавы) / “что именно пошло не так”.
Action items (10 мин): 1–3 действия, у каждого владелец, критерий “как поймём, что стало лучше”, срок.
Закрытие (2–3 мин): quick feedback: “что было полезно/что улучшить в следующей ретро”.

Подводный камень: записать action items в Confluence/Jira/Яндекс Трекер и забыть. В следующем спринте выделяйте 5 минут в планировании: “что из ретро делаем и где это в бэклоге”. Иначе ретро превращается в ежегодный ритуал “мы снова обещаем”.

Derby-заметка: формат, который спасает ретро от болтовни

Derby (как “гонка”) — это не канонический термин из Scrum Guide, а практичный способ держать ретроспективу в тонусе: мысли короткие, скорость высокая, решения приземлённые. Смысл — не обсуждать всё, а быстро отобрать пару тем, по которым реально можно “ускориться на круг”.

Как выглядит Derby-ретро (45–60 минут)

Круг 1 — факты (7 мин): каждый пишет 3 события спринта: “упало”, “ускорились”, “застряли”. Без оценок.
Круг 2 — ставки (5 мин): голосуем за 2 события, которые сильнее всего влияют на скорость/качество.
Круг 3 — причина (15 мин): на каждое событие делаем мини-5Why, но следим, чтобы “почему” не превращалось в “кто”.
Круг 4 — пит-стоп (10 мин): формулируем 1 действие на тему, которое можно сделать за спринт.
Круг 5 — таймер результата (5 мин): чем измерим улучшение (lead time, количество возвратов с тестирования, доля незапланированной работы, время реакции на инцидент).

Почему это хорошо для гибрида: люди меньше спорят, больше фиксируют. Удалённые не теряются в “голосовой доминации” переговорки, потому что сначала все пишут молча, а потом — короткая модерация.

Где брать шаблоны: делайте в Miro или в Яндекс Документах таблицей — не принципиально. Принципиально: чтобы результат попал в систему работы (Jira/Яндекс Трекер), а не остался “на доске”. Если хотите ещё форматы ретроспектив agile и разбор живых кейсов команд, это регулярно появляется в базе материалов на https://itokno.ru — без инфоцыганских фанфар, просто практики.

Кейсы из практики (успех и провал)

Кейс “взлетело”: гибридная команда, которая перестала срывать спринты

Команда (аналитик, 3 разработчика, тестировщик, продакт) жила в режиме “в конце спринта всё красное”. На ретро они жаловались на “много внезапных задач”. Когда сделали Timeline + Derby-заметку, выяснилось: 60–70% “внезапности” — это не бизнес, а баги старых релизов и ручные проверки, потому что автотестов почти нет. Action item был скучный: “каждый спринт 1 день на стабилизацию + чек-лист релиза в Confluence”. Через 3 спринта количество хотфиксов упало, план-факт стал ближе, а главное — исчезло ощущение вечной катастрофы.

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

Кейс “провалилось”: ретро как суд

В другой команде ретроспектива была в присутствии руководителя направления. Формально — “просто послушать”. Фактически — “понять, кто виноват”. Через две встречи люди начали писать нейтральные стикеры уровня “надо лучше планировать”. Проблемы (зависимости от соседней команды, отсутствие критериев готовности) так и не вылезли. Итог: ретро стало витриной благополучия, а потом случился большой срыв релиза — внезапно, конечно.

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

Экспертный вердикт и инструмент: чек-лист ретро, которое работает

Пункт	Как проверить за 2 минуты	Если “нет” — что сделать
Есть 1–3 action items	В конце встречи назовите их вслух	Режьте до 1–3, остальное в “парковку”
У каждого действия есть владелец	Имя рядом с задачей	Назначьте ответственного, иначе это “ничьё”
Есть метрика/критерий улучшения	“Поймём по…”	Выберите измеритель: время цикла, дефекты, WIP
Есть место в плане спринта	Задачи в трекере и оценены	Добавьте в бэклог/планирование
Удалённые говорят не меньше офисных	Кто чаще звучал последние 10 минут	Сначала молчаливый сбор, потом круг по очереди

Если вы “перебежчик” в IT (из другой сферы): учитесь фасилитации и формулировке действий. Это быстрый способ стать полезным даже без глубокого кода.
Если вы джун/мидл (1–3 года): тренируйте навык “перевести боль в гипотезу”. На ретро не “всё плохо”, а “мы теряем 6 часов на ручной регресс — давайте автоматизируем 3 критичных сценария”.

Частые вопросы

Сколько должна длиться ретроспектива в Agile?

Ориентир: 45–90 минут на двухнедельный спринт. Если регулярно не укладываетесь — вы либо обсуждаете слишком много тем, либо нет структуры (таймбоксов и выбора топ-1–2 проблем).

Что делать, если на ретро все молчат?

Начните с молчаливого сбора заметок 3–5 минут и анонимного голосования точками. Ещё помогает вопрос не “что было плохо?”, а “где мы потеряли больше всего времени?” — людям проще говорить фактами.

Нужен ли Scrum Master, чтобы проводить ретроспективы?

Желательно, но не обязательно. Нужен модератор, который держит структуру и безопасность. В маленьких командах это может быть тимлид или продакт, но тогда важно не превращать ретро в разбор полётов.

Как проводить ретроспективы в гибридной команде, чтобы удалённых не “задавили” офисные?

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

О чём нельзя говорить на ретроспективе?

Запрещать темы не нужно, но нельзя переходить на личности. Формулировка “Петя всё сломал” заменяется на “у нас нет code review/тестов/Definition of Done, поэтому дефекты попадают в релиз”.

Как понять, что ретро приносит пользу, а не занимает время?

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

Derby-заметка — это обязательно? Или можно без неё?

Можно без неё: это просто дисциплина “коротко → выбрать главное → сделать пит-стоп”. Если ваши ретроспективы уже дают 1–3 внедрённых улучшения за цикл — поздравляю, вы и так катаетесь быстро.