Есть такое мнение, что ретроспективы — пустая трата времени и бесполезное передвигание карточек. Сегодня я попробую доказать вам, что это мнение в корне неверно и из ретроспектив можно (и нужно!) извлекать огромную пользу. Припас для вас несколько не попавших под NDA кейсов и приемов, которые мы сами применяем в командах разработки. Поехали!

Привет, Хабр. Я старший android-разработчик и скрам-мастер. За годы работы я видел десятки команд, которые относились к ретро как к обязаловке, и столько же тех, которые превратили их в мощный инструмент развития. Разница между ними была не в размере команды или сложности проектов, а в понимании одного простого принципа.

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

Вот три истории из практики.

История первая. Сильный (и заслуженно уважаемый) разработчик предложил свое видение архитектуры. Его проигнорировали без обратной связи. Начались «разговоры у кулера», где его аргументы не встречали контраргументов. Команда раскололась. Разработчик уволился. За ним ушли еще шестеро. Компания потеряла носителей критических знаний о продукте. Проблема? Отсутствие площадки для обсуждения — ретроспектив не было, дейлики игнорировались.

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

История третья. Объединили две команды с разными подходами к работе. Быстро стало ясно, что «двигаться по накатанной» не выйдет. Обсуждение провели на ретро. Команды подробно рассказали о своих процессах, нашли точки соприкосновения, взяли лучшее из обеих практик. Основные процессы синхронизировали за две встречи. Эти два часа сэкономили множество человеко-часов на исправление ошибок и попытки понять друг друга во время спринтов.

Три разные ситуации, но вывод один: ретроспективы работают как предохранительный клапан. Они дают возможность высказать несогласие до того, как оно превратится в конфликт. Без механизма синхронизации конфликт версий неизбежен — как в коде, так и в головах.

Теперь о том, как превратить ретро из посиделок в инструмент.

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

Главное: ретроспектива без метрик не работает. Если не измеряете результаты — не сможете понять, работает ваш подход или вы просто тратите время. Каждая команда уникальна, поэтому метрики стоит подбирать под конкретные задачи. Но есть универсальное правило: без измеримых результатов эффективность неизбежно падает. Нет понимания, влияют ли ретроспективы на работу, — нет мотивации их проводить.

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

• двухнедельный спринт — 45 минут;

• трех-четырехнедельный спринт — около двух часов.

На входе 

• Изменения в компании и на рынке.

• Предложения и проблемы от участников.

• Застрявшие тикеты, узкие места в процессах.

• Реструктуризации и изменения в рабочих процессах.

На выходе

• Задачи в бэклог!

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

• задачи падают сразу в бэклог;

• сначала попадают на доску активности, потом — в бэклог;

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

У нас в команде эта доска, или «график улучшения», выглядит просто и наглядно:

Второй важный показатель, демонстрирующий, как ретроспективы влияют на прозрачность и стабильность выполнения задач, — Burndown chart, график сгорания story points в спринте. Когда процессы выстроены, линия идет ровно к цели без резких провалов и всплесков. 

Например, спринт 11:

А вот спринт 15: 

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

Но начинать нужно с Burndown chart. Если график идет ступенями или не достигает нуля к концу спринта — это сигнал обсудить на ретро проблемы с планированием или прозрачностью задач.

Важно: Burndown chart должен обновляться регулярно, в реальном времени. Если вы обновляете его задним числом или делаете это раз в неделю — данные искажены, и любые расчеты теряют смысл. Команда обманывает сама себя.

Но прежде чем Burndown chart начнет показывать реальную картину, нужно настроить сам процесс работы. У нас это заняло пару спринтов.

Сначала я разобрался с сущностями в Jira: истории, задачи, подзадачи, дефекты, эпики. Потом рассмотрел их в контексте ролей — аналитик, тестировщик, разработчик, Product Owner. На основе этого анализа нарисовал блок-схему нового процесса, созвонился с продактом и аналитиком, они внесли правки, я доработал и снова вернулся с презентацией. Таких итераций было три-четыре.

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

Поэтому спринт 11 (до внедрения процесса) и спринт 15 (после) выглядят по-разному. Это не магия метрик — это результат структурирования командной работы с задачами.

Только когда начнете вести честный Burndown chart, имеет смысл переходить к другим метрикам.

Velocity — количество story points, которые команда реально завершает за спринт. Используйте его для оценки скорости и прогнозирования объема работы в будущем спринте. Берите среднее значение за три-пять итераций, чтобы сгладить случайные всплески.

Важный момент: velocity нельзя сравнивать между командами. Это внутренняя метрика, которая отражает именно вашу систему оценок и темп. Если у соседней команды velocity 80, а у вас 40 — это ничего не значит. У них может быть другая шкала оценки сложности.

Predictability — показатель предсказуемости. Он отвечает на вопрос: насколько фактически выполненный объем работы совпадает с запланированным?

Пример: команда запланировала 50 SP, сделала 45 → predictability = 90%. Это означает, что команда предсказуема: обычно выполняет 90% от обещанного. Если predictability прыгает от 50% до 120%, значит, с планированием проблемы — то переоцениваете возможности, то недооцениваете.

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

Возможно, тестировщики прогоняют слишком много багов? На разработчиков навалилась большая нагрузка? Метрики покажут проблемы или, наоборот, позитивные изменения после внедрения новой практики. Но нужно помнить: за цифрами стоят реальные люди с конкретными проблемами и решениями. Результат дает комбинация метрик и открытого диалога. Метрики показывают объективную картину — хорошую или плохую, а ретро помогают понять причины и найти решения или закрепить успех.

Атмосфера 

Очень важно соблюсти баланс между излишней формальностью и чрезмерной расслабленностью. Иногда попить чай и поболтать о жизни — отлично. Это сплачивает коллектив, снимает напряжение. Но если каждая ретро превращается в чаепитие, толку не будет.

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

Если ваши ретроспективы — это монолог руководителя, вы делаете что-то не так. Вообще, присутствие на ретро начальства выше Product Owner'а обычно ошибка. Люди «закрываются», боятся выступить или задать неудобный вопрос.

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

Удовлетворенность команды

Мы используем простые, но информативные системы оценки качества. В первую очередь — удовлетворенность команды от встречи:

• Была ли она полезной для работы?

• Удалось ли донести свое мнение?

• Была ли качественной коммуникация?

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

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

Негативная энергия никуда не исчезает. Если не решить проблему на ретро, она выплеснется в другие чаты, перекинется на созвоны. Не заметите, как все встречи превратятся в бесконечные споры.

Геймификация

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

Есть целые сайты с тысячами идей для ретроспектив, обычно они так и называются: «генераторы ретроспектив». Можно заранее разбить встречу на блоки и подобрать активность к каждому. Пример: https://retromat.org/ru/.

Не можете найти хорошую идею для ретро? Используйте LLM. Недавно с помощью идеи от ИИ проводили онбординг нового сотрудника, представляя всех членов команды как супергероев. Каждый выбрал себе картинку и суперспособность. Новый сотрудник быстро запомнил всех, а участники команды узнали друг друга с неожиданной стороны.

Напомню тезис из начала статьи: команда — это система в той же мере, что и создаваемый ей код. Связанность элементов системы (членов команды) оказывает колоссальное влияние на качество и скорость выпуска продуктов. Когда команда распределенная и все на удаленке, важность человечных и добрых ретроспектив особенно велика.

Кому доверить модерацию?

Бывают случаи, когда приходится собирать много команд. Например, у нас однажды работа встала на несколько недель из-за невозможности согласовать правила оценки кредитного рейтинга. В таких ситуациях, когда нужно «разрубить гордиев узел», приглашают agile-коуча или других экспертов с правом решающего голоса.

В обычной жизни модератором выступает scrum-мастер (если есть такая роль) или руководитель. Но в зрелой команде можно сделать интереснее — распределить scrum-активности между участниками. Роль модератора становится переходящей, и проводить ретро может любой член команды с подходящими софт-скиллами.

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

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

Подытожим весь этот раздел чек-листом хорошего ретро: 

• Атмосфера открытости: все должны иметь возможность высказаться.

• Вежливость: нельзя перебивать выступающих.

• Уместность присутствующих: стараться не приглашать сотрудников старше Product Owner.

• Разумная частота: как правило, одного раза в спринт достаточно.

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

• ВСЕГДА превращать обсуждения с ретроспектив в задачи.

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

Как внедрить ретроспективы, если команда маленькая и полноценный agile-фреймворк «не помещается» в ваши задачи? Я считаю минимально необходимым выделить промежуток времени, когда все могут собраться и обсудить проблемы. 

Если относиться к ретро с точки зрения «проблемы на вход → задачи в бэклог на выход», даже маленькая команда сможет извлечь из 40–50-минутных встреч пользу. Важно четко ограничить время на эту активность, чтобы она не воспринималась как отдых или отлынивание — ни членами команды, ни руководителями.

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

С точки зрения руководства регулярные ретроспективы могут выглядеть как потеря времени. Все разговаривают, никто не работает, тикеты не закрываются. Как донести важность таких встреч до далеких от разработки руководителей?

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

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

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

Вместо послесловия

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

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

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

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