Ретроспектива: особенности проведения

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

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

В рамках ретроспективы команда анализирует:

🟣 Качество выполнения задач.

🟣 Командное взаимодействие и коммуникации.

🟣 Эффективность процессов и подходов.

🟣 Общий командный настрой.

Подготовка к ретроспективе

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

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

Инструменты для проведения ретроспектив

Рассмотрим инструменты, которые могут пригодиться для ретроспективы.

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

• Флипчарты.
• Маркерные доски.
• Стикеры.

Для распределённых или гибридных команд удобны онлайн-инструменты, которые можно разделить на пять категорий:

1. Виртуальные доски (например, Draw.io или FigJam).
2. Сервисы для ретроспектив (EasyRetro, MetroRetro, TeamRetro) — поддерживают разные форматы, анонимный сбор фидбэка и голосование.
3. Средства связи (Zoom, Google Meet, Telegram).
4. Инструменты для хранения результатов (Google Docs, Confluence).

Форматы ретроспектив

Рассмотрим основные форматы проведения ретроспективы проекта.

Start — Stop — Continue

Команда обсуждает идеи в трёх направлениях:

• Старт — что начать делать.
• Стоп — что прекратить.
• Продолжение — что оставить без изменений.

Пример:

• Начать заранее описывать задачи.
• Прекратить ежедневные бесполезные встречи.
• Продолжать привлекать аналитика к проработке требований.

Рад — Огорчён — Зол

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

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

4L

Расшифровывается как Liked, Learned, Lacked, Longed for. Участники делятся тем, что им понравилось, чему они научились, чего не хватало и чего хотелось бы в будущем. Например, полученный опыт можно разделить так:

🟣 Понравилось, что аналитик заранее подготовил всю документацию.
🟣 Научились правильно разбивать задачи на подзадачи.
🟣 Не хватало чётких критериев готовности задач.
🟣 Хотелось бы больше времени на тестирование.

Этапы проведения ретроспективы

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

1. Подготовка. Скрам-мастер за день до ретро напоминает о подготовке. Каждому участнику команды предстоит вспомнить и проанализировать, как именно для него и команды в целом прошёл спринт.
2. Встреча. Скрам-мастер напоминает о цели встречи и устанавливает правила взаимодействия: экологичная коммуникация, отсутствие обвинений и фокус на деталях.
3. Обсуждение спринта. Этап включает анализ собранных данных. Команда обсуждает, что происходило в спринте, какие возникали проблемы, на что стоит обратить внимание. Здесь важно не просто констатировать факты, а начать искать причины происходившего.
4. Генерация идей и предложений. Команда предлагает, что нужно начать делать, что стоит прекратить, а что продолжить.
5. Сортировка и голосование. Чтобы выделить приоритеты, проводится голосование внутри каждой категории. Так команда решает, какие изменения наиболее важны.
6. Фиксация решений. Все выводы фиксируются в одном месте — на доске, в документе или таск-трекере. Это важно для отслеживания прогресса.