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

Erid: 2SDnjex9JNH

Ретроспектива — обязательный этап в Scrum. Она нужна, чтобы команда разобрала, что пошло не так в спринте, нашла узкие места и договорилась, как работать лучше. Но часто ретро превращается в формальность: поговорили, разошлись и ничего не поменялось.

Вот как сделать ретроспективу действительно полезной.

Подготовьтесь заранее

Не надо приходить на ретро без конкретной повестки. Ведущий (часто это Scrum-мастер) должен заранее:

• собрать фидбек у команды;
• подготовить повестку;
• выбрать формат — не обязательно классическое «что хорошо/плохо/можно улучшить».

Формат можно менять: попробовать Start-Stop-Continue, 4Ls (Liked, Learned, Lacked, Longed for) или Mad-Sad-Glad. Это помогает команде взглянуть на спринт с разных сторон.

Создайте безопасную атмосферу

Без доверия нет откровенности. Если команда боится говорить о проблемах, ретро бесполезно проводить.

Что помогает:

• Четкие правила: не обвиняем, не перебиваем, обсуждаем действия, а не людей.
• Участие всех — даем слово каждому, особенно интровертам.
• Фасилитация, где ведущий следит за тем, чтобы разговор не скатился в жалобы или повседневное обсуждение.

Обсуждайте конкретику

Плохо работаем или много багов — это вода. Выясните:

• что именно пошло не так;
• когда это произошло;
• какие последствия были.

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

Фиксируйте решения

Решения должны быть записаны и назначены ответственные, иначе все забудется на следующий день. Лучше вести список улучшений в таск-трекере. Так вы сможете отслеживать, что внедрили, а что — нет.

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

Анализируйте прогресс

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

Пример

Команда пожаловалась: «У нас снова не хватило времени на тестирование». Вместо того чтобы просто согласиться, ведущий задал уточняющие вопросы:

— Когда именно начались задержки?
— Что повлияло на сроки?
— Сколько задач не прошли тест?

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

Фото предоставлено ООО «Кайтен Софтвер».

Реклама. ООО «Кайтен Софтвер». ИНН 7714426252 kaiten.ru