Что такое ретроспектива проекта в Agile и как правильно проводить ретро в команде

В Scrum Guide ретроспективам уделен буквально один абзац. Но когда дело доходит до этого мероприятия, у команды и организатора возникает масса вопросов. Отвечаем на все!

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

Ниже разберемся в деталях.

Что такое ретроспектива

Ретроспектива (в англ. retrospective) – это командная встреча, на которой участники анализируют прошедший период работы (итерацию/спринт), выявляют проблемы, отмечают успешные практики и решения, определяют конкретные шаги по улучшению существующих процессов.

Слово состоит из двух частей:

• «Ретро-» (retro-) — от латинского наречия retro, что означает «назад», «в прошлом», «обратно». Кто здесь подумал про ретроградный Меркурий?
• «-спектива» — происходит от латинского глагола specere (или его формы spectum), что означает «смотреть» или «видеть».

То есть дословно это «взгляд назад» или «смотреть в прошлое».

Ретроспективный анализ может применяться не только в АйТи или в разработке ПО. Он используется в:

•        психологии и психотерапии – для понимания корней текущих проблем, а также для составления картины самовосприятия и сложившегося опыта человека.
•         педагогике и образовании – для планирования обучения и оптимизации, улучшения имеющихся программ.
•         научных исследованиях и экономике – ретроспектива позволяет оценивать сложившиеся модели и системы связей.
•         искусстве – для анализа уже изданных произведений и статистики их продаж. Актуально для художественного кино, документальных фильмов и других произведений. Благодаря ретроспективе авторы получают новые идеи и заранее прогнозируют их востребованность у аудитории, выбирают подходящий формат и каналы дистрибуции.
•         менеджменте и управлении бизнесом – благодаря анализу прошлого опыта руководство компании может разрабатывать план улучшения любых рабочих процессов.

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

Что такое ретроспектива в Agile

В реальности слово ретроспектива не упоминается ни в принципах, ни в ценностях манифеста Agile (он же манифест гибкой разработки ПО). Однако идейной основой для проведения ретроспектив легко можно назвать 12-й принцип Манифеста:

В оригинале (на английском):

«At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.»

В русском переводе:

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

По сути, ретроспектива — это практическая реализация этого принципа.

Единственная предметная методология, применяемая в ИТ и в работе над проектами, в которой упоминается ретроспектива, – Scrum. Здесь для этого выделена отдельная церемония (событие) в конце каждого спринта.

В реальности в других Agile-практиках мероприятие с анализом действий, необходимое для усвоения хорошего опыта и разбора полетов, может называться по-разному. Например, обзор процесса, анализ итерации, итоги и т.п., но суть везде одна и та же.

Когда и как ретроспектива вошла в Agile?

В 2002–2003 годах Agile-сообщество начало активно внедрять регулярные разборы полетов. Ключевую роль сыграли книги:

• Норм Керт, «Project Retrospectives» (2001) – хотя книга вышла в год Манифеста, она не была его частью, зато дала название новой успешной практике.
• Эстер Дерби и Диана Ларсен, «Agile Retrospectives» (2006) – эта книга уже окончательно закрепила ретроспективу как стандартную практику Agile.

Также стоит упомянуть, что Алистер Кокберн, один из соавторов Манифеста, еще в 1998 году предлагал проводить «рефлексивные мастерские» (reflection workshops) – это был прообраз ретроспективы, и именно он, скорее всего, способствовал появлению в манифесте 12-го принципа.

Зачем проводить ретроспективу

Главная задача ретроспективы – непрерывное совершенствование процессов. Такой принцип продвигается многими концепциями управления: Шесть сигм, lean-разработка (бережливое производство) и т.п.

При системном подходе ретроспектива помогает оптимизировать будущие действия и качественно управлять эффективностью работы команд:

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

При регулярной ретроспективе формируется особая культура отношений. А еще команда получает эффективный инструмент накопления знаний и закрепления успешного опыта.

Где пригодится проведение ретроспективы

Если говорить только о проектной деятельности, то ретроспективы активно применяются в следующих ситуациях и сферах:

• Разработка ПО и программных продуктов. Для разбора полетов после спринтов, крупных релизов или других важных этапов развития / реализации проекта.
• Маркетинг и продажи. Например, для анализа рекламных мероприятий и масштабных кампаний.
• Производство. В основном для оптимизации цепочек поставок, сбыта и внутренних процессов.
• Службы поддержки клиентов / клиентские сервисы. Для анализа качества обслуживания и улучшения показателей работы.
• Образование и инфобизнес. Для сбора обратной связи по результатам обучения и улучшения учебных программ.
• HR-службы. Для повышения эффективности мероприятий по привлечению новых сотрудников и по адаптации персонала после найма.

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

Типы ретроспектив

Предметной классификации для ретроспектив не существует. Но если вспомнить, что термин употребляется только в методологии Скрам, то сразу говорим, что обсуждаем в статье только один формат этой практики – ретроспективу спринта (Sprint Retrospective).

Ее цель — запланировать повышение качества и эффективности, она всегда завершает спринт. Дальше – только заход на новый цикл с планированием, ежедневными дейли-скрамами и ревью.

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

• Ретроспектива релиза — может проводиться после выпуска новой версии продукта. Основное внимание уделяется качеству поставки, соблюдению сроков, взаимодействию между командами и обратной связи от пользователей.
• Ретроспектива проекта / этапа — проводится после завершения проекта или его крупного этапа. Ее задача — зафиксировать извлеченные уроки и сформировать рекомендации для будущих инициатив.
• Тематическая ретроспектива — она может быть посвящена отдельному процессу или проблеме: тестированию, взаимодействию с заказчиком, управлению требованиями, качеству коммуникаций и другим аспектам работы.
• Ретроспектива инцидента — выполняется после серьезных сбоев, ошибок или кризисных ситуаций. Цель встречи — определить первопричины произошедшего и предотвратить повторение аналогичных проблем.

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

К слову, в книгах, которые популяризировали практику, ретроспективы не классифицируются. Они рассматриваются как повторяемый процесс или как один из этапов работы. Авторы фокусируют внимание на описании процедур проведения и на используемых инструментах.

Плюсы ретроспективы для бизнеса

Ретроспектива – это действенный инструмент повышения продуктивности. Он обеспечивает получение следующих положительных эффектов:

• Снижение числа ошибок – особенно системных и критических, а также упреждение новых.
• Сокращение времени и увеличение скорости работ, а также снижение затрат – как логичное следствие отсутствия проблем (не нужно тратить время на исправление ошибок и дефектов).
• Оптимизация процессов и повышение качества продукта/услуги – благодаря непрерывному совершенствованию. Рост удовлетворенности клиентов – как следствие.
• Накопление полезных знаний и детальная документация внутри команды / компании.
• Стимулирование атмосферы открытости и культуры продуктивной обратной связи.

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

Без этого встреча превращается в обычную беседу по душам.

Минусы и ограничения

Недостатки ретроспективы:

• Такие события занимают много времени и сил, особенно, если брать в расчет подготовку и организацию, а не только само проведение.
• Вместо конструктивного обсуждения и поиска точек роста ретроспектива может превратиться в аналог судебного процесса – с поиском виноватых и их прилюдным наказанием. На мотивации такие встречи будут сказываться крайне негативно.
• Риск проведения для галочки – как еще один бессмысленный ритуал, который нужно пройти для завершения спринта.
• Замалчивание реальных проблем – как раз из-за риска наказания.
• Неверные выводы и оптимизации – из-за низкого уровня знаний участников или из-за отсутствия опыта участия в таких мероприятиях, без проявления нужной инициативы.
• Хаотичное обсуждение – очень многое зависит от организатора (фасилитатора) и авторитета участников. На очных встречах многие могут растеряться и не донести важную точку зрения и факты до остальных, а именно они могут оказаться критическими.
• «Проклятье ретроспективы» – оригинальная логическая ловушка. При взгляде назад легко можно увидеть влияющие на ситуацию факторы и закономерности, но непосредственно в ситуации, изнутри, эти факторы не видны или имеют высокую степень неопределенности. Соответственно, в следующей аналогичной ситуации они также могут не поддаваться прогнозированию.
• Устаревание контекста – закономерности в отдельных процессах и сферах редко остаются статичными. Соответственно, усвоенные знания быстро теряют актуальность и становятся бесполезными.
• Субъективизм. Наиболее близкая аналогия – ошибка выжившего. Если вы получили положительный опыт в конкретном проекте и в определенных условиях, это не значит, что это система. При малейшем изменении условий, а также по независящим от вас причинам исход может стать резко негативным, а вам просо повезло в прошлый раз. Оказаться в нужном месте и в нужное время – ценный опыт, но он практически не воспроизводится.

Кому подходит ретроспектива

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

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

Ретро не даст никакой пользы:

•         в токсичных командах.
•         в командах, которые собираются для работы над разовым проектом (полученные знания и выводы нужны только до момента сдачи результата, потом они теряют смысл).
•         в командах, которые не управляют своими рабочими процессами. Дополнительные встречи будут только забирать силы и время.

Как провести ретроспективу: этапы

Команда может самостоятельно определить алгоритм проведения ретроспективы – в соответствии со своими предпочтениями и особенностями самого проекта.

Классический подход к проведению ретроспективы описан в книге Agile Retrospectives. Здесь обозначено пять обязательных этапов. О них ниже.

Этап 1. Set the Stage – подготовка

Этот этап посвящен созданию комфортной и безопасной атмосферы для открытого обсуждения. Участники должны иметь возможность переключиться с повседневных задач на совместный анализ своей работы.

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

Правильно проведенный этап подготовки задает вектор дальнейшего общения и достаточный уровень доверия.

Этап 2. Gather Data – сбор данных, информации и обратной связи

Далее команда собирает факты, события и наблюдения, относящиеся к анализируемому периоду – спринту или итерации.

Участники вспоминают наиболее важные события, полученные результаты, а также отдельно формируют списки проблем, изменений в требованиях и инцидентов. Особое внимание – успешным решениям.

Здесь важно опираться только на объективные данные и факты. В качестве источников могут использоваться:

• отчеты и метрики;
• данные систем управления проектами;
• результаты тестирования;
• статистика обращений пользователей;
• записи встреч;
• заметки участников команды
• и т.п.

Для структурирования информации часто применяются профильные техники и инструменты, о которых мы расскажем ниже отдельно.

Этап 3. Generate Insights – генерация идей

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

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

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

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

Результат – конкретные выводы о том, какие аспекты работы требуют изменений.

Этап 4. Decide What to Do – составление плана дальнейших действий

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

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

Про SMART-подход

Для них можно определить приоритеты, создать разные списки – что внедрять сразу, что отложить на потом. Логично также назначить ответственных за реализацию.

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

Этап 5. Close the Retrospective – завершение ретроспективы

Здесь подводятся итоги и закрепляются достигнутые договоренности. Фасилитатор кратко резюмирует основные выводы встречи, фиксирует согласованные действия, ответственных лиц и сроки новых задач.

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

Но какой инструмент использовать для фиксирования результатов ретроперспективы и вообще управления командой?
На российском рынке сейчас много локальных предложений, например Projecto.  Это система управления проектами и задачами со встроенным мессенджером, диаграммой Ганта, канбан-досками и CRM-системой. Она автоматизирует рутинные процессы, сделает делегирование удобным и освободит вам и вашим сотрудникам часы для действительно важной работы. Попробовать можно от 14 дней бесплатно.

Методы и подходы для проведения ретроспектив

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

Диаграмма Исикавы (Fishbone Diagram)

Она же «рыбья кость» – из-за схожей структуры связей, от общего к главному.

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

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

Подробный материал о диаграммах Исикавы.

Метод «5 Почему»

Метод основан на последовательном поиске первопричин с помощью повторяющегося вопроса «Почему это произошло?». Говорят, что если продолжать задавать этот вопрос, можно дойти до основ сотворения мира. Собственно, по той же причине введено ограничение на пять уровней.

Команда выбирает конкретную проблему и задает вопрос «Почему?» до тех пор, пока не будет выявлена ее корневая проблема. Обычно достаточно пяти итераций, однако их количество можно увеличить или уменьшить – в зависимости от ситуации, но будьте осторожны.

Start — Stop — Continue (Начать — Прекратить — Продолжить)

Это один из самых простых и популярных форматов. Участники делят свои идеи на три категории:

• Start — какие практики или действия стоит начать использовать.
• Stop — от каких привычек, процессов или подходов следует отказаться.
• Continue — какие успешные практики необходимо сохранить.

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

4Ls – Liked, Learned, Lacked, Longed for (Понравилось, узнали, не хватило, хотелось бы)

Техника глубокого анализа. Участники распределяют свои наблюдения по четырем категориям:

• Liked — что понравилось в процессе работы.
• Learned — чему удалось научиться.
• Lacked — чего не хватало для эффективной работы.
• Longed for — что хотелось бы изменить или получить в будущем.

Подход будет интересен для ретроспективы после крупных и сложных проектов.

Какие подходы можно еще попробовать

• Mad — Sad — Glad (Раздражало — Огорчало — Радовало), максимально эмоциональный вариант обсуждения, лучше других помогает разобраться в коммуникациях.
• Sailboat («Парусник») – рисуется парусник (это проект), остров (цель проекта), а также ветер (факторы, которые обеспечивают достижение цели), якоря (факторы, которые тормозят процесс) и рифы (риски и глобальные ограничения).
• Таймлайн – на линию времени наносятся ключевые решения, релизы, инциденты, изменения требований и значимые достижения. Дополнительно обсуждаются связи между разными элементами.
• Glad — Learn — Try (Радовало — Узнали — Попробуем), команда выясняет что прошло успешно, какие выводы удалось сделать, что еще предстоит проверить.
• DAKI (Drop — Add — Keep — Improve). Метод позволяет оценить текущие процессы через четыре категории: от чего следует отказаться, что необходимо добавить, что важно сохранить и что требует улучшения.

Сколько длится ретро?

Согласно официальному руководству Scrum, для проведения ретроспективы должно выделяться не более 3 часов при условии, что спринт длится около месяца.

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

Но команда сама может назначить оптимальное время таких встреч – все будет зависеть от объема обсуждений, количества участников и других факторов.

Кто должен проводить ретроспективу?

В Scrum Guide этот вопрос не освещается. Но в норме, как и в случае с другими событиями, такая обязанность должна быть у Скрам-мастера. Так как именно он отвечает за фасилитацию.

Вместе с тем, провести ретроспективу могут и любые другие участники команды. Например, владелец продукта – это тоже идеальный кандидат. Технически организатором может быть даже внешнее лицо, что бывает иногда полезно.

Что можно обсуждать на ретро?

• Что сработало, а что нет.
• Какие идеи или подходы оказались успешными.
• Что мешало в реализации и блокировало усилия команды.
• Какие проблемы обнаружились в процессах.
• Что можно улучшить – в коммуникациях, процессах, инструментах.
• Что можно предпринять для локализации или обхода выявленных / нерешенных проблем на будущий спринт (спринты).
• Каким было эмоциональное состояние участников – их переживания, мотивация, загруженность.
• Эффективность оценок и текущих критериев успешности продукта / проекта.