Статья
12 октября 2026 г.
Пятница. Ретроспектива.
Команда подводит итоги спринта. Выясняется, что задачи снова оценили слишком оптимистично, требования менялись по ходу разработки, а тестировщики получили половину задач за день до релиза.
Обсудили. Нашли проблемы и узкие места. Договорились больше так не делать.
Проходит 2 недели.
Пятница. Ретроспектива.
Задачи снова оценили слишком оптимистично, требования снова менялись по ходу разработки, а тестировщики… Впрочем, вы уже догадались.
Если бы за каждое «нам нужно улучшить коммуникацию» выдавали по рублю, некоторые команды давно бы окупили годовую подписку на корпоративное ПО.
А ведь сама идея ретроспективы в том, что команда оглядывается назад не ради коллективной ностальгии по сорванным срокам, но чтобы понять, что мешало работе, сохранить удачные решения и изменить то, что не сработало.
Почему, когда все обсудили, обо всем договорились — через две недели снова те же грабли?
Потому что между «мы поняли, что нужно изменить» и «мы действительно это изменили» целая пропасть. Ну, или рабочий процесс. Который чаще всего и является слабым звеном.
В этой статье разберемся, как ретроспективы попадают во временную петлю — и что нужно сделать, чтобы каждая следующая встреча продолжала изменения, а не вызывала дежавю.
Начнем с того, что делать не надо — «проверенных» способов организовать коллективное топтание на месте.
Команда честно перечислила проблемы, выяснили, что раздражало, что радовало. Все высказались, атмосфера вроде конструктивная. Ведущий благодарит участников за открытость. Занавес.
Только вот обсуждение проблемы еще не означает, что решение принято. Допустим, выяснили, что задачи слишком долго ждут согласования. А дальше что?
Кто разберется с причиной?
Что попробуем изменить?
Когда проверим результат?
Если ответов нет, ретроспектива закончилась примерно в том месте, где должна была начаться самая полезная ее часть.
Универсальное решение, которое одинаково хорошо подходит для команды разработчиков, строительной компании и экипажа космического корабля.
Звучит разумно. Возражать никто не станет. Осталось понять: что конкретно нужно делать?
«Улучшить коммуникацию» может означать что угодно: раньше сообщать об изменениях требований, согласовывать приоритеты до начала спринта, приглашать тестировщиков на обсуждение задач или перестать искать важные решения в переписке трехмесячной давности.
Сравните две договоренности:
Во втором случае хотя бы понятно, что должно измениться. И можно проверить, произошло ли это.
Задача задержалась, потому что Вася не успел. Требования оказались неполными, потому что Маша плохо объяснила. Релиз перенесли, потому что Петя поздно заметил ошибку.
Ретроспектива превратилась в кастинг на роль виноватого.
Удобная картина мира: у каждой проблемы есть имя, фамилия и аватарка в корпоративном мессенджере.
Ок, Вася действительно задержал задачу. Почему? Возможно, он одновременно работал над 5 архисрочными задачами. Или 90% времени ждал решения от другого отдела. Или получил требования, которые потом менялись трижды за неделю.
Это не означает, что личной ответственности не существует. Просто найти виновного и устранить причину — две разные задачи.
А если каждая ретроспектива заканчивается поиском крайнего, сотрудники эволюционно осваивают важнейший навык корпоративного выживания: поменьше рассказывать о проблемах.
После особенно продуктивной ретроспективы команда выходит с внушительным списком улучшений.
Пересмотреть процесс согласования. Обновить документацию. Настроить автоматизацию. Изменить правила оценки задач. Разобраться с техническим долгом. Улучшить онбординг. Заодно навести порядок во Вселенной. И желательно все до следующего вторника.
Все важное. Все нужное. Хорошо бы вчера.
Беда в том, что улучшения конкурируют за время с обычной работой. Если команда и без того перегружена, +15 новых инициатив не прибавят ей свободных часов и уж тем более энтузиазма.
В итоге список изменений живет свою насыщенную жизнь: пополняется на каждой ретроспективе, изредка сортируется по приоритету и постепенно превращается во второй бэклог. Только еще менее популярный, чем первый.
Мораль: лучше выбрать одно-два изменения, которые команда действительно сможет проверить в ближайшем рабочем цикле, чем торжественно пообещать исправить все.
На этот раз все сделали правильно. Выбрали проблему, нашли причину, сформулировали конкретное решение.
Допустим: договорились уточнять критерии готовности задач до начала разработки.
Решение даже записали в протокол (где-то рядом с датой встречи и списком присутствующих).
Через 2 недели выясняется, что никто не помнит, кто должен был этим заниматься. Кто-то думал, что договоренность касается аналитиков. Аналитики были уверены, что разработчиков. Разработчики вообще впервые слышат о протоколе.
Договоренность без ответственного, срока и проверки результата — это скорее пожелание. Причем довольно скромное: оно даже не требует исполнения.
Ретроспектива должна заканчиваться не только списком выводов, но и понятным ответом на вопрос: что именно мы сделаем по-другому до следующей встречи?
Команда может регулярно жаловаться на проблему, которая уже начала решаться. Такую закономерность обнаружили Тимо Лехтинен, Юха Итконен и Каспер Лассениус, изучив 37 ретроспектив в одной распределенной Scrum-организации за 2012–2014 годы. Организация за это время выросла с одной команды до шести, а исследователи сопоставили записи обсуждений с фактическими данными разработки — оценками трудозатрат и числом открытых дефектов.
Результаты оказались любопытными.
Высказывание «оценки были неточными» прозвучало в 35% ретроспектив, но в 30% встреч звучало противоположное — «хорошие оценки». При схожей фактической точности команда то хвалила оценки, то ругала их, а сопоставление с репозиторием подтвердило: обсуждения точности оценок не соответствовали реальным показателям. Улучшения предлагались неоднократно, но заметно повысить точность за три года не удалось.
С дефектами картина другая: высказывание «много багов» встречалось в 18% ретроспектив — и здесь жалобы совпадали с данными. Команды вкладывались в тестирование, но разработка продолжалась и приносила новые дефекты. Проблема повторялась около двух лет, пока число открытых багов не стабилизировалось, — тогда и жалобы прекратились.
Получается, одинаковые на первый взгляд жалобы могут сопровождать совершенно разные процессы. Авторы статьи выделили три типа повторяющихся обсуждений:
Различать эти типы полезно: в первом и втором случае повторяющееся обсуждение — сигнал, что команда тратит время впустую, в третьем — что улучшения идут, но проблема еще в повестке.
Другую закономерность обнаружили авторы исследования Agile Retrospectives: An Empirical Study of Characteristics and Organizational Learning. Они изучили пятилетнюю практику ретроспектив одной команды и провели семь интервью с представителями других команд.
Команды способны успешно внедрять улучшения, а предыдущий опыт влияет на готовность поддерживать следующие изменения: удачные инициативы придают уверенности, неудачные — снижают энтузиазм. Эта петля обратной связи работает в обе стороны — прошлые улучшения могут как помогать будущим, так и мешать им.
Но особенно интересен другой результат: в ретроспективах преобладало обучение по принципу single-loop learning. Команды совершенствовали отдельные действия, продолжая работать по привычным правилам, и гораздо реже пересматривали сами правила. Авторы ожидали увидеть double-loop learning — именно поэтому результат оказался неожиданным.
Представим условную ситуацию. Команда несколько спринтов подряд пытается точнее оценивать задачи: меняет шкалу сложности, уточняет критерии. Но продолжает планировать спринт почти на 100% доступного времени. Любая незапланированная работа нарушает график, и сроки снова сдвигаются.
Пересмотр самого принципа планирования — например, выделение резерва времени на непредвиденные задачи — уже относится к double-loop learning. Здесь команда меняет правило, по которому привыкла работать, а не только действия внутри него.
Оба исследования основаны на наблюдениях за ограниченным числом команд, поэтому обобщать их на все команды нельзя. Но два практических вопроса из этих работ выводятся хорошо: «Что показывают данные?» и «Какие наши правила или предположения могли привести к этой ситуации?» Первый защищает от bias — расхождения восприятия с фактами, второй помогает перейти от правки действий к пересмотру правил. Их полезно задать до того, как команда в очередной раз начнет придумывать решения.
В книге Agile Retrospectives Эстер Дерби, Диана Ларсен и Дэвид Хоровиц описывают пять фаз ретроспективы: подготовить обсуждение, собрать данные, осмыслить их, выбрать действия и завершить встречу. Порядок имеет значение: сначала разобраться, что произошло и почему, а уже потом решать, что менять. Иначе ретроспектива превращается в конкурс советов, где побеждает самый уверенный голос.
Но даже удачная встреча не гарантирует изменений. Договоренности еще нужно выполнить и проверить. Здесь пригодятся рекомендации Бена Линдерса из статьи Getting Retrospective Actions Done.
Мы объединили эти подходы — вместе они образуют полный цикл: от обсуждения проблемы до проверки результата на следующей ретроспективе.
Соберите материалы за прошедший период: завершенные и перенесенные задачи, задержки, блокировки, существенные инциденты. Не нужен подробный отчет — достаточно данных, к которым можно обратиться во время обсуждения.
Поднимите договоренности прошлой ретроспективы и результаты их выполнения. Заранее определите продолжительность встречи, участников и место для записи наблюдений.
Схема составлена на основе: Derby, Larsen, Horowitz — Agile Retrospectives (2-е изд., 2024); Ben Linders — Getting Retrospective Actions Done (2015)
Фаза 1. Начать обсуждение
Обозначьте цель встречи и период, который будете разбирать. Начните с прошлых договоренностей: что удалось выполнить, помогли ли изменения, что осталось нерешенным?
Если улучшения еще не внедрены, выясните, что мешает, прежде чем добавлять новые.
Затем дайте участникам 3–5 минут, чтобы каждый записал на стикерах или виртуальной доске, что мешало работе, а что помогало. Это позволит собрать мнения всех участников, а не только тех, кто первым берет слово.
Фаза 2. Собрать данные
Обсудите наблюдения участников и уточните общие формулировки. Вместо «постоянно срываем сроки» выясните, какие задачи задержались, на каком этапе и насколько.
Если нужно, откройте историю задач, чтобы восстановить ход событий. Пока важно понять, что происходило, а не искать виноватых или предлагать решения.
Фаза 3. Осмыслить данные
Сгруппируйте похожие наблюдения и выберите проблемы, которые чаще повторяются или сильнее всего мешают работе. Не пытайтесь разобрать все за одну встречу.
Чтобы понять причины, обсудите три вопроса:
Не останавливайтесь на объяснениях «не хватило внимательности» или «плохо взаимодействовали». Важно разобраться, что именно приводило к ошибкам или задержкам.
Если причина неясна, определите, что еще нужно проверить. Необязательно находить ответ прямо на встрече.
Фаза 4. Выбрать действия
Определите, какие из выявленных проблем стоит решать в первую очередь. Учитывайте, насколько они мешают работе, что команда может изменить своими силами и сколько времени это потребует.
Не пытайтесь исправить все сразу. Выберите столько улучшений, сколько реально сможете выполнить. Если не уверены, что решение сработает, попробуйте его в течение одной итерации и оцените результат.
Прежде чем завершить обсуждение, превратите каждое решение в конкретную договоренность:
Что делаем
Перед началом разработки согласовываем критерии приемки каждой задачи с тестировщиком
Зачем
Сократить количество задач, возвращенных на доработку из-за неясных требований
Кто отвечает
Аналитик команды
Когда
С 19 октября, в течение следующего спринта
Как проверим
30 октября подсчитаем, сколько задач вернулось на доработку из-за неясных требований, и сравним с предыдущим спринтом
Эту таблицу можно использовать как шаблон для собственных договоренностей. Ответственный за организацию не обязан выполнять все самостоятельно — важно, чтобы у действия был человек, который поможет довести его до результата.
Фаза 5. Завершить встречу
Убедитесь, что всем понятно, какие действия выбраны, кто за них отвечает и когда команда проверит результат. Коротко обсудите, что удалось на самой ретроспективе, а что стоит изменить в следующий раз.
Перенесите согласованные действия в рабочий бэклог или на доску задач, где команда планирует остальную работу. Линдерс рекомендует делать улучшения видимыми и регулярно возвращаться к ним в ходе итерации.
Не забудьте выделить время на саму работу :) Если улучшение не учитывается при планировании нагрузки, оно легко уступит место текущим задачам.
💡 Фиксируйте договоренности уже во время ретроспективы, чтобы не терять контекст и не тратить на это время после. Назначайте ответственных, сроки и все самое важное в taskITnow — прямо на доске, не открывая карточки. Как? Показали в видео.
Во время работы отмечайте, применялся ли новый подход, и собирайте данные, которые понадобятся для оценки результата. Не нужно создавать отдельную отчетность: достаточно информации, о которой договорились на встрече.
Вернитесь к прошлым решениям и выясните:
Учитывайте контекст: один удачный спринт еще не доказывает, что улучшение сработало. Возможно, задачи были проще или изменился состав команды.
По итогам выберите дальнейшее действие: закрепить улучшение, скорректировать, прекратить или продолжить наблюдение, если данных пока недостаточно.
Пятница. Ретроспектива. Та же переговорка, те же люди.
— Ну что, в этот раз хоть что-нибудь изменилось?
Сурок поднимает голову и говорит:
— Да, коммуникация была улучшена.
Подпишитесь на новости и релизы
Нажимая кнопку, я подтверждаю, что согласен с политикой конфиденциальности
