Обзор и ретроспектива

Две встречи в конце спринта, которые постоянно путают: одна — про продукт и внешний мир, другая — про команду и её собственную работу.

Обзор спринта (Sprint Review) — встреча с заказчиками и пользователями, где команда показывает готовый инкремент и вместе со стейкхолдерами решает, что делать дальше.
Ретроспектива (Sprint Retrospective) — закрытая встреча команды о том, как она работала и что изменить в самом процессе.

Разница простая: обзор — про то, ЧТО мы сделали. Ретро — про то, КАК мы это делали. На обзоре смотрят на продукт, на ретро — на себя. Когда их сливают в одну встречу («ну, заодно и обсудим, что пошло не так»), пропадают обе: при заказчике команда не станет честно говорить о своих проблемах, а разбор процесса заслонит разговор о продукте.

Обзор спринта: не «сдача работы»

Самое живучее заблуждение — что Sprint Review это защита перед начальством: команда показывает, что не бездельничала, начальство одобряет или ругает.

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

Отсюда правила, которые сильно повышают отдачу:

Показывают работающий продукт, а не слайды. Не «мы отрефакторили сервис оплаты», а живой сценарий: вот я, пользователь, ввожу карту, вот пришёл чек. Если инкремент нечего показать — это отдельный разговор о Definition of Done.
Не показывают недоделанное. Демо «почти работает, только тут заглушка» создаёт у заказчика ложное ощущение готовности. Потом придётся объяснять, почему «уже же было готово месяц назад».
Показывает команда, а не только PO. Разработчик, который сам объясняет пользователю свою функцию, за десять минут узнаёт о продукте больше, чем за спринт чтения задач.
Половина времени — на разговор. Не «показали и разошлись», а вопросы, реакция, обсуждение того, что делать в следующем спринте.

Таймбокс — до 4 часов для месячного спринта, то есть около часа для двухнедельного.

Кого звать

Тех, чьё мнение реально повлияет на продукт: заказчика, представителей пользователей, поддержку (она знает, на что жалуются), смежные команды. Не нужно звать всех подряд «для прозрачности» — чем больше зрителей, тем меньше настоящей обратной связи и тем сильнее соблазн превратить встречу в презентацию.

Ретроспектива: разговор команды о команде

Ретро идёт после обзора, закрытым составом, и отвечает на один вопрос: что мы изменим в своей работе к следующему спринту? Не «что было плохо», а именно что изменим. Разница между этими формулировками — вся разница между полезной ретро и полуторачасовой жалобной книгой.

Классическая канва: собрать факты, найти закономерности, выбрать одно-два улучшения, договориться о конкретных шагах.

Формат 1: старт — стоп — продолжай

Самый простой и потому самый живучий. Три колонки, каждый пишет, что команде стоит начать делать, перестать делать и продолжать делать.

РЕТРО, спринт 35

START (начать)                | STOP (прекратить)             | CONTINUE (продолжать)
------------------------------|-------------------------------|------------------------------
Брать задачу в работу только  | Обсуждать архитектуру         | Парное ревью сложных PR —
после ревью критериев (2)     | в комментариях к PR (3)       | багов стало заметно меньше (4)
                              |                               |
Писать в чат, если PR висит   | Тащить «маленькие» задачи     | Общий канал с поддержкой:
больше 4 часов (4)            | мимо спринта (2)              | быстро узнаём о проблемах (2)

(в скобках — сколько человек проголосовало)

Голосование нужно, чтобы не утонуть: обсуждают две-три темы, набравшие больше всего голосов, остальное остаётся на доске до следующего раза.

Формат 2: 4L

Liked / Learned / Lacked / Longed for — понравилось, узнали, не хватало, чего хотелось бы. Формат мягче и лучше подходит, когда спринт был тяжёлым и есть риск, что «стоп»-колонка превратится в перечисление претензий друг к другу.

Liked (понравилось)	Что сработало и что хочется сохранить	«Дежурный по багам разгрузил остальных»
Learned (узнали)	Что новое поняли о продукте, коде, процессе	«Платёжный провайдер отдаёт ошибки не так, как в доках»
Lacked (не хватало)	Чего не было под рукой, чтобы работать нормально	«Не было тестового стенда с реальными данными»
Longed for (хотелось бы)	О чём мечтали, пусть даже это не в нашей власти	«Чтобы дизайн приходил до планирования, а не в середине спринта»

Есть и другие форматы — «парусник» (что двигает вперёд, что тянет назад), «безумно-грустно-радостно», разбор одной конкретной проблемы через «пять почему». Меняйте формат раз в несколько спринтов: одна и та же форма приедается, и люди начинают писать по инерции те же карточки.

Ретро без действий бессмысленна

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

Лечится одним правилом: ретро заканчивается одним-двумя изменениями, у каждого есть владелец и срок, и они попадают в бэклог спринта наравне с задачами. Не «поработать над коммуникацией», а конкретное действие, про которое через две недели можно однозначно сказать, сделали или нет.

Пустое решение	Рабочее решение
«Лучше оценивать задачи»	«Задачу крупнее 8 SP на планировании обязательно разбиваем. Следит Марат.»
«Быстрее делать ревью»	«PR старше 4 часов — бот пишет в канал. Настроит Дима, до среды.»
«Больше общаться с дизайном»	«Лена зовёт дизайнера на груминг раз в неделю, начиная с этого спринта.»

И берите одно изменение, максимум два. Список из семи улучшений — это гарантированный ноль выполненных. Первым пунктом следующей ретро проверяйте прошлое решение: сделали? помогло? Если раз за разом не делаем — это само по себе тема для разговора, и куда более честная, чем очередная карточка на доске.

Безопасность высказываний

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

Что помогает на практике:

Без начальства. Если на ретро сидит человек, который решает вопрос премии, честного разговора не будет — не потому что люди трусливы, а потому что это разумная осторожность.
Обсуждаем процесс, а не людей. Не «Дима медленно делает ревью», а «PR висят по два дня — что в процессе это позволяет?» Почти за каждым «плохим человеком» стоит плохо устроенный процесс.
Базовая установка ретро. Норм Керт предложил начинать встречу с напоминания: каждый делал свою работу настолько хорошо, насколько мог в тех условиях, с теми знаниями и ресурсами, что у него были. Мы ищем не виноватого, а причину.
Сначала пишем, потом говорим. Если сразу открыть обсуждение, тон зададут двое самых громких. Пять минут молча на стикеры — и мнения тихих тоже попадут на доску.
Что сказано на ретро — остаётся на ретро. Наружу выходят только договорённости, не цитаты.

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

Как это работает

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

Четверг, конец спринта 35

14:00  ОБЗОР (55 мин)
       Лена показывает оплату картой: вводим карту, приходит чек.
       Приходит руководитель поддержки: «А если банк отклонил — что видит
       человек?» Показываем. «Текст ошибки непонятный, к нам будут писать.»
       → В бэклог: понятные тексты ошибок оплаты. PO ставит наверх.

15:00  РЕТРО (60 мин, только команда)
       Формат: старт-стоп-продолжай. 5 минут молча на стикеры.
       Голосуем. Топ-темы: PR висят по два дня; дизайн приходит в середине спринта.

       Решили (в бэклог спринта 36):
         1. Бот пишет в канал о PR старше 4 часов — Дима, до среды.
         2. Дизайнер приходит на груминг по вторникам — Лена, договорится завтра.

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

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

Частые ошибки

Обзор как отчёт о проделанной работе. Слайды вместо продукта, «принято / не принято» вместо обсуждения того, что делать дальше.
Демо недоделанного. «Тут пока заглушка, но выглядит как настоящее» — заказчик запомнит только картинку и будет считать функцию готовой.
Обзор и ретро слиты в одну встречу. При стейкхолдерах команда не станет честно разбирать свои проблемы.
Ретро без действий. Пожаловались, разошлись, доску не открыли. Через месяц команда перестаёт верить в ретро вообще.
Слишком много решений сразу. Семь улучшений за спринт = ноль улучшений. Берите одно-два.
Ретро при руководителе, решающем судьбу премий. Формально безопасно, фактически — все молчат.
Один и тот же формат два года подряд. Люди отвечают на автомате, новые темы перестают всплывать.
Отмена ретро, когда «горит». Именно когда горит, она и нужна: это единственная встреча, которая может починить причину пожара, а не его последствия.

Итоги

Обзор — про продукт и внешний мир, ретро — про команду и её процесс. Это две разные встречи и два разных состава.
Sprint Review не защита работы, а сбор обратной связи, которая меняет бэклог продукта. Показываем живой продукт, а не слайды.
Ретро заканчивается одним-двумя изменениями с владельцем и сроком, и они попадают в бэклог спринта.
Первым пунктом следующей ретро — проверка прошлого решения. Без этого ретро быстро превращается в ритуал.
Форматы (старт-стоп-продолжай, 4L, «парусник») стоит чередовать, иначе люди отвечают по инерции.
Без безопасности высказываний ретро не работает: обсуждаем процесс, а не людей, и без тех, кто раздаёт премии.