Спринт заканчивается ревью и ретроспективой. Часто ревью ограничивается только демо: разработчики показывают свою работу, заинтересованные стороны смотрят на инкремент, затем все расходятся. Это типичная картина, когда ревью подменяется демонстрацией. Как вычислить плохое ревью и как его исправить?
Вот признаки такого заблуждения:
- ревью воспринимается только как возможность продемонстрировать инкремент,
- заинтересованные стороны сидят в отдалении от команды, как в зрительном зале,
- присутствуют презентации в виде скриншотов предположительно работающего продукта,
- никто из присутствующих на встрече не пользуется продуктом на самом деле,
- заинтересованные стороны не приносят весомый вклад (без них можно обойтись),
- никто из них не пользуется продуктом на ревью, только смотрят,
- когда демо заканчивается, все тут же расходятся.
Слишком много scrum-команд рассматривают ревью как встречу, на которой они должны показать прогресс. Читайте, как «они хотят показать, что сделали».
Настоящая цель ревью
Руководство по Scrum описывает Обзор спринта как событие, которое «проводится в конце Спринта, чтобы проверить Инкремент и, если необходимо, адаптировать Бэклог Продукта». Подчеркивается, что «команда и заинтересованные стороны сотрудничают в отношении того, что было сделано в спринте <...> Участники совместно работают над следующими задачами, которые можно сделать, чтобы оптимизировать ценность».
Сотрудничество между Scrum-командой и её заинтересованными сторонами является ключевым во время обзора спринта. Это событие — важнейшая возможность в Scrum получить представление о проделанной работе и использовать её для следующих шагов в разработке. Он посвящён тому, чтобы обеспечить прозрачность инкремента и бэклога. Таким образом, результат ревью — это корректировки бэклога. В некотором смысле, обзор посвящен ответу на вопрос: «Что делать дальше на основании того, что мы узнали в этом спринте?»
Оптимально, обзор имеет следующие характеристики:
- Заинтересованные стороны и члены команды работают совместно, без деления на своих и чужих;
- Участники могут высказать своё мнение, предложения и идеи;
- Бэклог занимает видное место во время ревью и корректируется по мере появления новых идей;
- Обзор касается всей команды (включая Владельца продукта), которая делится Инкрементом с заинтересованными сторонами;
- Владелец продукта обсуждает бэклог продукта и сообщает вероятные прогнозы, основываясь на достигнутом прогрессе;
Советы
- Напомните команде цель обзора спринта. Убедитесь, что люди понимают, что мероприятие посвящено сбору обратной связи и корректировке совместного пути, а не «продаже продукта» или «принятию проделанной работы».
- Попросите членов команды объединиться с заинтересованными сторонами и вместе проверить инкремент. Вместо того, чтобы разработчик демонстрировал продукт на планшете, ноутбуке или компьютере, отдайте устройство стейкхолдеру.
- Избегайте использования Powerpoint и других замен настоящего работающего ПО.
- Убедитесь, что все разработчики посещают обзор.
- Используйте активные форматы, не садитесь за стол,чтобы поглядеть на экран. Для этого есть масса техник.
- Пригласите реальных пользователей на обзор. Они наиболее способны определить, «работает ли продукт» хорошо.
- Изменяйте формат ревью в зависимости от контекста.
- В рамках закрытия спросите участников, что можно сделать для (дальнейшего) повышения ценности этого мероприятия.
- Пригласите участников с объяснением, почему их присутствие важно.
- Будьте открыты и прозрачны в отношении невыполненной работы.
