Ретроспектива — встреча, на которой команда обсуждает не продукт, а собственную работу: что мешало, что помогало и что менять дальше. Слово пугает новичков сильнее, чем стоило бы. Разберём, как эта встреча устроена изнутри и почему на ней вообще безопасно говорить.
Дальше по порядку: как ретро проходит по шагам, кто её ведёт, как часто и сколько длится, что на ней стоит говорить и как отличить рабочую формулировку от жалобы. Закончим форматами, примерами хороших и плохих решений и разбором трёх типичных страхов.
Что такое ретроспектива и зачем она нужна?
Ретроспектива — регулярная встреча команды, на которой разбирают процесс работы за прошедший отрезок. Не код, не фичи и не people review. Предмет обсуждения — то, как команда работала: где ждали, где переделывали, где не поняли друг друга.
Формально ретроспектива — одно из событий Scrum. Scrum Guide редакции ноября 2020 года описывает её так: цель ретроспективы спринта — спланировать способы повысить качество и эффективность. Команда смотрит, что шло хорошо, с какими проблемами столкнулась и как эти проблемы решались или не решались.
Ключевое отличие от соседней встречи: на обзоре спринта команда показывает продукт заказчику, на ретроспективе разбирает свой процесс между собой. Путать их дорого: если ретро съезжает на обсуждение фич, процессные проблемы копятся дальше. Как устроен Scrum целиком, мы разбирали в отдельной статье — ретроспектива там лишь одно из четырёх событий.
Идея старше Scrum. Двенадцатый, последний принцип Agile-манифеста 2001 года в официальном русском переводе звучит так: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы». Ретроспектива — и есть тот самый регулярный анализ, вынесенный в отдельную встречу.
Насколько это распространено, сказать сложнее, чем кажется. Последняя проверяемая цифра — из пятнадцатого отчёта State of Agile: 83% опрошенных назвали ретроспективы среди практик, применяемых в их организации. Опрос проводили в феврале-апреле 2021 года, полных ответов собрали 1 382.
Свежее этой цифры нет ни у кого. Начиная с семнадцатого отчёта Digital.ai убрал вопрос про Agile-практики из исследования: в полном тексте отчёта слово «retrospective» не встречается ни разу. Так что статьи, ссылающиеся на «свежие данные State of Agile» про ретро, ссылаются на 2021 год.
Теория заканчивается здесь. Дальше — как встреча выглядит, если прийти на неё в четверг вечером.
Как проходит ретроспектива на практике?
Ретроспектива идёт по фазам, и порядок в них не случайный. Самая известная схема — пять фаз из книги «Agile Retrospectives: Making Good Teams Great» Эстер Дерби и Дайаны Ларсен, вышедшей в 2006 году с предисловием Кена Швабера. В феврале 2024 года вышло второе издание, уже с третьим соавтором Дэвидом Горовицем, и структура в нём сохранилась.
- Задать рамку (Set the Stage). Ведущий напоминает, зачем собрались, и даёт каждому сказать хоть одну фразу. Смысл прозаический: кто промолчал в первые пять минут, промолчит и дальше.
- Собрать данные (Gather Data). Команда выкладывает факты прошедшего отрезка: события, цифры, сорванные сроки, удачные решения. Пока без выводов и без поиска виноватых — только то, что было.
- Понять причины (Generate Insights). Здесь факты группируют и ищут, что за ними стоит. Три похожих стикера про «ждали ревью» — уже не три случайности, а закономерность.
- Решить, что делать (Decide What to Do). Из закономерностей выбирают одну-две и превращают в конкретные действия с ответственными. Не десять, а одну-две: остальные не переживут спринт.
- Закрыть встречу (Close the Retrospective). Проговаривают, что решили и кто за что взялся. Полминуты, но без них половина договорённостей испарится к утру.
Многие команды ведут ретро не на бумаге и стикерах, а на онлайн-доске: колонки видны всем, карточки перетаскиваются, ничего не теряется при уборке переговорки. В Strive для этого можно собрать канбан-доску под нужный формат и работать на ней прямо во время встречи.
Порядок фаз понятен. Осталось разобраться, кто в этой встрече участвует.
Кто там будет и кто ведёт встречу?
На ретроспективу приходят те, кто вместе работал над отрезком. Scrum Guide в разделе про ретроспективу называет только Scrum-команду: владельца продукта, Scrum-мастера и разработчиков. Отдельного списка приглашённых или требований к гостям в Гайде нет.
Ведёт встречу фасилитатор — чаще всего Scrum-мастер, если он в команде есть. Его зона — процесс, а не содержание: следить за временем, давать слово молчащим, возвращать разговор к теме и не давать ему съехать на личности. Scrum Guide закрепляет за Scrum-мастером обязанность следить, чтобы события проходили продуктивно и укладывались в тайм-бокс.
Бывают и нестандартные конфигурации. В командах без Scrum-мастера ведущего назначают по очереди — тогда каждый хоть раз побывает в роли того, кто удерживает рамку. Иногда зовут внешнего фасилитатора: это разумно, если команда крупно поссорилась и своими силами разговор не вытянет.
Отдельный вопрос — начальство. Присутствие руководителя, от которого зависит премия, меняет разговор: люди начинают выбирать формулировки вместо того, чтобы называть проблемы. Scrum Guide про это молчит, запрета в нём нет, так что решает команда — но эффект стоит понимать заранее.
Состав понятен. Следующий вопрос, который задают новички: как часто это всё повторяется.
Как часто проводится ретроспектива?
Ретроспектива проводится каждый спринт и завершает его. Scrum Guide формулирует прямо: ретроспектива закрывает спринт, а обзор спринта назван предпоследним событием. То есть в цикле ретро стоит последней, после демонстрации продукта.
На практике это раз в одну-две недели — по длине спринта, принятой в команде. Команды на месячных спринтах собираются раз в месяц, но платят за это объёмом: за четыре недели накапливается столько, что половину придётся отбросить.
Частоту стоит поднимать, когда процесс лихорадит: новая команда, свежий состав, переход на другой стек, серия инцидентов. И наоборот, у команды с устоявшимся процессом каждая вторая ретро может проходить вхолостую — тогда честнее собираться реже, но по делу.
Отдельно от спринтовых бывают ретро по событию: после релиза, после крупного инцидента, в конце проекта. Они длиннее и разбирают не две недели, а весь путь.
Раз есть ограничение по частоте, есть и ограничение по времени.
Сколько длится ретроспектива?
Максимум три часа для месячного спринта — это прямая норма из Scrum Guide. Для более коротких спринтов, добавляет Гайд, встреча обычно короче. Конкретных пропорций он при этом не даёт, так что все формулы вида «45 минут на двухнедельный спринт» придуманы не Гайдом.
Для сравнения, у соседних событий тайм-боксы такие: планирование спринта — максимум восемь часов, обзор спринта — максимум четыре, ежедневный Scrum — пятнадцать минут. Ретро в этом ряду посередине.
Реальная длительность зависит от размера команды и от того, сколько накопилось. Пять человек после спокойного спринта уложатся в час. Десять человек после провального релиза не уложатся и в два, и это нормально. Ненормально другое: когда встреча идёт третий час, решения принимает уже усталость, а не команда.
Время и состав — рамка. Внутри неё начинается то, ради чего всё затевалось: разговор.
Что следует говорить на ретроспективе?
Говорить на ретроспективе стоит о событиях, а не о людях. Критиковать процесс можно и нужно — ровно за этим и собрались. Критиковать коллегу нельзя, и дело не в вежливости: как только разговор переходит на человека, он начинает защищаться, а не разбираться, и встреча кончилась.
Разница между жалобой и обратной связью — в проверяемом факте. «У нас плохой процесс» — оценка, с ней нечего делать: непонятно, что именно плохо и что менять. «Релиз ушёл с багом, потому что тестировать начали за час до выката» — факт, следствие и уже почти готовое решение.
Рабочая формулировка складывается из трёх частей: что произошло, к чему это привело, что предлагаю. Третья часть необязательна — если решения нет, достаточно первых двух, команда придумает вместе. А вот первая часть обязательна всегда: без события высказывание превращается в настроение.
Если сказать нечего — принесите факт. Не обязательно проблему: «за спринт ни разу не переделывали задачу после ревью» — тоже данные, и они объясняют, что в процессе работает. Молчание на ретро чаще означает не «всё хорошо», а «не придумал, что сказать» — а факт придумывать не надо, он просто был.
Сказанное на ретро не растворяется в воздухе: фасилитатор тут же фиксирует его в карточку. Фраза «мы плохо тестируем перед релизом» на глазах у всех превращается в конкретное действие с исполнителем — и дальше живёт как обычная задача. В Strive такую карточку можно сразу завести задачей с ответственным и сроком, не переписывая потом из протокола.
Формулировки — половина дела. Вторая половина — на какой доске их раскладывают.
Популярные форматы ретро, которые вы можете встретить
Формат ретро — это разметка доски: колонки задают, о чём команда будет думать. Разберём четыре, которые встречаются чаще всего.
- Start / Stop / Continue. Три колонки: что начать делать, что перестать, что продолжать. Собирает действия, а не эмоции, поэтому хорош, когда проблема в процессе. Самый распространённый формат — при этом общепринятого автора у него нет, он сложился в практике.
- Mad / Sad / Glad. Колонки по эмоциям: что злило, что расстраивало, что радовало. Берут, когда в команде копится напряжение и разговор о процессах его не вытаскивает. Автора у формата тоже нет, хотя его регулярно приписывают то одной книге, то другой.
- 4L: Liked, Learned, Lacked, Longed for. Что понравилось, что узнали, чего не хватило, чего хотелось. Формат про опыт, а не про сбои — уместен после большого этапа или новичку в конце онбординга. Его связывают с Мэри Горман и Эллен Готтесдинер из EBG Consulting.
- Лодка. Команда рисует лодку: ветер — что двигает, якорь — что тормозит, рифы — риски. Вырос из игры Speed Boat, которую Люк Хоманн описал в книге «Innovation Games» 2006 года; правда, у самого Хоманна это был инструмент сбора обратной связи от клиентов, а версия про парусник — более поздняя переделка сообщества.
Один и тот же формат каждый спринт перестаёт работать месяца через три: команда начинает отвечать на автомате, не задумываясь. Форматы имеет смысл чередовать — но пересобирать доску каждый раз с нуля утомительно.
Готовых шаблонов ретро в Strive нет, и придумывать их мы не будем. Зато шаблон делается из вашего же проекта: разметили доску под Start / Stop / Continue один раз — и дальше можно сохранить её как шаблон проекта, чтобы следующая ретро начиналась с готовой разметки, а не с пустого экрана.
Доска размечена, стикеры собраны. Дальше решает то, во что они превратятся.
Примеры хороших и плохих action items
Action item — конкретное действие, которое команда решила сделать по итогам ретро. Плохой отличается от хорошего одним признаком: по хорошему видно, кто его делает и когда он считается сделанным. Разница на примерах:
| Было (не сработает) | Стало (сработает) |
|---|---|
| Улучшить коммуникацию в команде | Ира заводит в чате тред под каждый релиз и пишет туда статус — со следующего спринта |
| Лучше тестировать | Добавить шаг «прогнать смоук-тесты» в чек-лист релиза — Дима, до конца недели |
| Не брать задачи без оценки | Задачи без оценки не переносим в спринт: проверяем на планировании — договорились все, следит Саша |
| Начать делать ретро полезнее | На следующей ретро пробуем формат 4L вместо Start/Stop/Continue — готовит Ира |
Видно закономерность: слева намерения, справа действия. У намерения нет ответственного, нет срока и нет признака готовности — а значит, нет и способа проверить, сделали его или нет. Через спринт оно вернётся на доску в той же формулировке.
Второе правило — ответственный всегда один человек. «Команда договорилась» не работает: задача, за которую отвечают все, не сделана никем. Один ответственный не означает, что он делает всё сам — он означает, что есть с кого спросить статус.
Третье — количество. Две-три задачи с ретро команда донесёт до конца спринта, десять не донесёт ни одна. Лучше одно изменение, которое приживётся, чем список, который все прочитают один раз.
И главное: хороший action item мало сформулировать, важно, чтобы он не потерялся после встречи. Протокол в документе читают один раз, задача в трекере попадается на глаза каждый день — поэтому решения с ретро имеет смысл заводить туда же, где лежит остальная работа команды.
Столько правил, что первый раз идти страшновато. Разберём, чего именно боятся.
Частые страхи новичков на ретроспективе
Страхи у всех примерно одинаковые, и все три разбираются одинаково быстро.
«А если я подставлю коллегу?» Это самый частый страх, и вырастает он из путаницы: ретро принимают за разбор полётов. Предмет ретроспективы — процесс, а не человек. «Релиз задержался, потому что задача три дня ждала ревью» никого не подставляет — это описание того, как устроена работа.
На этот случай есть прямая опора. Норм Керт, автор книги «Project Retrospectives» 2001 года, сформулировал Основную директиву ретроспективы: независимо от того, что мы обнаружим, мы понимаем и искренне верим, что каждый делал свою работу настолько хорошо, насколько мог, — с учётом того, что он знал на тот момент, его навыков, доступных ресурсов и сложившейся ситуации.
Директиву во многих командах читают вслух перед началом. Выглядит как ритуал, работает как договор: раз мы заранее согласились, что все старались, то любая найденная проблема автоматически про обстоятельства, а не про чью-то халатность.
«А если я скажу глупость?» Глупость на ретро — только оценка без факта. Если вы приносите событие, которое действительно было, глупостью оно быть не может: событие или произошло, или нет. Мнение можно оспорить, факт — нет.
«А что если ретро — просто формальность?» Иногда так и есть, и врать тут смысла нет. Проверяется просто: посмотрите, что стало с решениями прошлой встречи. Дошли до задач с ответственными и сроками — ретро живая. Остались в протоколе, который никто не открывал — формальность, и говорить об этом надо вслух на ближайшей же ретро.
Страх снимается не уговорами, а результатом. Разберём, из чего он складывается.
Как извлечь пользу из ретро?
Пользу из ретро приносит не сама встреча, а то, что происходит вокруг неё. Короткий чек-лист:
- До встречи. Заметили что-то за спринт — запишите сразу, не надейтесь вспомнить в четверг. Двух строк в заметках хватит.
- На встрече. Говорите о событиях, а не о людях. Принесли проблему — принесите и факт под ней. Нет решения — нормально, для этого и собрались вместе.
- На встрече. Следите, чтобы ваше высказывание превратилось в карточку. Не превратилось — значит, вас услышали, но не записали, а это одно и то же, что не услышали.
- После встречи. Проверьте, что у каждого решения есть ответственный и срок. Одно-два решения на спринт, не десять.
- Признак, что сработало. На следующей ретро прошлые решения закрыты, а проблемы не повторяются дословно.
- Признак, что нет. Те же стикеры, что месяц назад, и никто этого не замечает.
Ретроспектива держится на одном условии: сказанное должно доходить до работы. Пока action items живут в протоколе встречи, ретро остаётся разговором. Как только они становятся задачами с ответственным и сроком, встреча начинает менять процесс.
Инструмент для этого не обязан быть отдельным — достаточно того, где команда и так ведёт работу. Если у вас такого пока нет, попробуйте Strive: внедрять его не нужно, доска под ретро собирается за минуту, а решения со встречи сразу попадают в задачи команды и не теряются до следующего спринта.
