Что такое ретроспектива и какие проблемы команды она решает?
Раз в две недели команда собирается на час, обсуждает, что было плохо, создаёт стикеры на доске, например в Miro — и открывает эту доску в следующий раз только затем, чтобы завести новые стикеры. Встреча есть, изменений нет. Разберём, что такое ретроспектива на самом деле, какие потребности команды она закрывает и какие проблемы, кроме неё, не разбирает никакая другая встреча.
Ретроспектива — что это и откуда она взялась
Определение ретроспективы
Ретроспектива — регулярная встреча команды, на которой разбирается не результат работы, а способ работы: процессы, взаимодействие людей, инструменты. Заканчивается она решениями о том, что в этом способе изменить.
Ретроспектива простыми словами: это когда команда останавливается и спрашивает себя не «что мы сделали», а «как мы это делали и что мешало».
Что такое ретроспектива спринта, точнее всего сформулировано в Scrum Guide 2020 (методологическое руководство по Scrum, авторы Кен Швабер и Джефф Сазерленд): в Scrum это отдельное событие спринта, где команда инспектирует прошедший отрезок «with regards to individuals, interactions, processes, tools, and their Definition of Done» и планирует, как повысить качество и эффективность работы. Что именно сделано — предмет другой встречи, Sprint Review.
Откуда взялась практика
Практика проведения подобных встреч старше agile. Проведение ретроспектив это один из вариантов реализации Цикла Деминга: Plan (Планируй) -> Do (Делай) -> Check (Проверяй) -> Act (Действуй / Улучшай). Подробнее описано у работах Уильяма Эдвардса Деминга по непрерывному улучшению в послевоенной Японии: улучшение там устроено как цикл внутри самого процесса.
Для команд разработчиков практику первым формализовал Норм Керт в книге «Project Retrospectives: A Handbook for Team Reviews» (2001). С распространением Extreme Programming и Scrum разбор в конце итерации стал обычным делом, требование «через равные промежутки времени команда размышляет о том, как стать эффективнее, и корректирует своё поведение» попало в 12-й принцип Agile Manifesto, а оттуда — в Scrum Guide.
Так что если считать, что это очередной «scrum-обряд», то это не так. К потребности взглянуть на то, как проходила работа команды, приходят без всяких фреймворков: посидели после релиза, разобрали, что мешало, что пошло не так, договорились в следующий раз делать иначе. Agile дал этой привычке название и место в календаре, а не придумал её.
Чем ретро отличается от ежедневных встреч, планёрок или разбора инцидента
Чем ретроспектива отличается от ежедневных встреч (daily, статус-встречи), планёрки и разбора инцидента — не «фокусом» и не «взглядом под другим углом», а тремя проверяемыми вещами: предметом, вопросом и ритмом.
Daily (планёрка/статус) — короткая регулярная встреча о ходе работ. Предмет: задачи и блокеры. Вопрос: что делаем дальше. Ритм: каждый день. Цена подмены: процессную проблему во время daily физически некуда положить — она не задача и не блокер, у неё нет ни исполнителя, ни срока. Её проговаривают в коридоре и забывают, и она живёт неограниченно долго.
Разбор инцидента — анализ конкретного сбоя после того, как он случился. Предмет: один инцидент. Вопрос: почему упало и как не допустить повтора. Ритм: по факту падения. Цена подмены: не видно всего, что не падает. Неудобный процесс код-ревью, несогласованные ожидания между ролями и ручная рутина инцидента не создают — они месяцами съедают по часу в день, оставаясь ниже порога, на котором кто-то назначает разбор.
Ретроспектива — регулярный разбор способа работы команды. Предмет: люди, взаимодействия, процессы, инструменты, Definition of Done. Вопрос: что менять в процессе. Ритм: фиксированный, независимо от того, случилось что-нибудь или нет.
Зачем нужна ретроспектива команде: какие проблемы она решает
Зачем проводить ретроспективу в команде, видно по классам проблем, у которых нет другого места в её календаре. Таких классов четыре.
Невысказанное знание исполнителя. Человек видит, что решение нерабочее, но молчит, потому что в комнате есть иерархия. В книге «Мама, я тимлид» описан характерный случай: на встрече двух департаментов разработчик, знавший проблему лучше всех, промолчал, а через пятнадцать минут после встречи написал, что принятое решение невозможно воплотить. Его объяснение — «кто я такой, чтобы с ними спорить». Молчание младших в этой книге о работе руководителя названо прямо: не согласие, а невысказанное знание.
Процессные трения. Ревью, которого ждут по два дня. Ручной деплой из пяти шагов, где каждый помнит свои три. Ожидания между ролями, о которых не договаривались вслух: тестировщик ждёт сборку к утру, разработчик считает, что «к вечеру» тоже нормально. По отдельности каждое терпимо — поэтому по отдельности никто и не поднимает.
Решения и контекст, живущие в голове одного человека. Пока он на месте, это не выглядит проблемой.
Устаревание процесса под изменившиеся обстоятельства. Процесс настраивали под тот состав и ту цель, которые были полгода назад. Пришли новые люди или, наоборот, кто-то покинул команду — и договорённости перестали работать: «ревью в течение дня» больше не выполняется, потому что раньше опытных ревьюеров было трое, а теперь меньше. Продукт сменил фокус с новых фич на highload — определение «сделано» без нагрузочного теста устарело в тот же день. Книга «Мама, я тимлид» даёт пару тезисов про этот класс: баланс команды хрупок и ломается постоянно, а каждый новый человек сначала снижает эффективность команды и только потом начинает приносить пользу. В той же книге о работе руководителя IT-команды дано определение bus factor — число участников, после потери которых проект не будет закончен в срок.
Процессная договорённость без повторной сверки распадается точно так же, как забывается и размывается цель, если до неё долго идти.
Где ретро чаще всего ломается
Конкретное действие (action items) — одно конкретное изменение, которое команда решила внести: что делаем, кто отвечает, к какому сроку и по какому признаку считаем сделанным.
Доведение решений до конца (follow-through) — привычка начинать следующее ретро с проверки статуса вопросов и проблем, поднятых в прошлом: что сделано, что застряло и почему.
Ломается каждое по своей причине, как правило возникают такие проблемы:
Истинную проблему трудно выделить из просто фактических состояний. "Долго проходит код ревью" или "Мало коммуникаций внутри рабочей группы" - это состояния, а корневая причина или проблема. А для хорошего решения, как правило, было бы неплохо понять корневую проблему. Измеримое решение трудно сформулировать. Нет четких правил, а использовать фреймворк типа SMART не так то просто. Договорённости забывают не из саботажа, а из вытеснения. У задачи в трекере есть исполнитель, спринт и кто-то, кто спросит о статусе; у пункта с ретро нет ни владельца в рабочем потоке, ни срока — и в конкуренции за время он проигрывает любой задаче, у которой они есть.
Почему формальная ретроспектива хуже, чем её отсутствие
«Ретро — трата времени» — точное наблюдение с неточным диагнозом. Час в календаре — меньшая из потерь. Большая в том, что формальная ретроспектива без результата обесценивает саму идею улучшений: команда на своём опыте выясняет, что называть проблемы вслух бессмысленно, и перестаёт их называть. Встреча остаётся, содержание из неё уходит.
Механизм такой. Человек сформулировал проблему, её записали, ничего не произошло. Возникает ощущение, что нет смысла тратить время на встречи, которые проявляют проблемы, то есть проявляют негативное, но не создают решений этих проблем.
Чинится это не более энергичным фасилитатором, а видимостью и трекингом незакрытых проблем, чтобы снова и снова применять к ним вопросы: «Удалось закрыть или уменьшить проблему?», «Это всё ещё актуально?», «Какие действия мы можем попробовать ещё?».
Насколько это помогает в цифрах, надёжных данных нет. Платформа Easy Agile сообщает по своему продукту TeamRhythm: команды закрывали 40–50% пунктов с ретро, а после того как незакрытые пункты стало видно, — 65%. Это наблюдение вендора о собственной фиче, без раскрытой методики подсчёта и без контрольной группы, так что читать цифру стоит не как доказанный порог, а как иллюстрацию механизма: то, за чем мы перестаем следить, выполняется хуже или не выполняется вовсе.
Вывод: ретро — не встреча, а непрерывный процесс подстройки
Ретроспектива — не час в календаре, а подстройка команды под текущую реальность. Качество этого цикла можно измерять объёмом сформулированных проблем и долей решений, доведённых до конца.