Ревью спринта для Scrum-команды — ответственное событие, которое может нарушать устоявшуюся зону комфорта у незрелых команд. Плюс, все эти сложности со сбором стейкхолдеров, половина которых не имеет представления о Scrum и не понимает повестку. В общем, это широкое поле работы для Agile-евангелистов, но сегодня мы обсудим один антипаттерн, который может возникнуть на этом фоне.
Антипаттерн — детальная подготовка к ревью спринта. С другой стороны следующая крайность — команда приходит на ревью спринта, как в гости, и не представляет, что от нее требуется. В этой статье мы разберёмся, как готовиться к ревью или демо.
Майк Кон часто рассказывает следующий пример. Он встретил команду, которая основательно репетировала своё ревью. За день до официального события, Scrum-мастер собирал команду и призывал их практиковать встречу, иногда по два раза.
Это зашло так далеко, что несколько членов команды играли роль стейкхолдеров и старались придумать обратную связь и вопросы, которые могли бы задать реальные заинтересованные стороны. Остальная часть команды в это время практиковалась в ответах, которые они могли бы дать.
Это была бы отличная идея, если бы это был театр. Но смысл в том, что обзоры спринтов не нужно репетировать. Несмотря на состав участников, это всё ещё неформальное событие. Ревью спринта — это снимок состояния продукта и его прогресса на текущий момент. Мы выделяем для него отдельное время, но в целом, любой разработчик должен уметь сказать и показать, что он уже сделал, в любой день спринта.
Доскональная репетиция не нужна. Тем не менее, вам понадобятся базовые договорённости и небольшой план, чтобы не терять время и снизить стресс.
- Решите заранее, кто что показывает, и какие истории требуют показа, а какие можно пропустить или оставить под конец. В общем, определите скоуп и добавьте эти пункты в приглашение на встречу.
- Определите порядок, в котором будут демонстрироваться фичи.
- Определите, кто ответствен за показ, кто будет демонстрировать, кто рассказывать, нужна ли дополнительная помощь, можно ли отдать мышку стейкхолдеру и т. д.
- Определите, какие тестовые данные нужно подготовить и оставить нетронутыми (и главное, кто их подготовит!) Мы неоднократно наблюдали, как выбранный для теста юзер подвергался изменениям со стороны другой команды, так что приходилось терпеть неприятную заминку во время ревью.
- Не показывайте работу в прогрессе, потому что она может несколько раз измениться.
Эти решения можно принять накануне или утром в день перед ревью. Останьтесь на 10 минут после стендапа, чтобы закрыть эти вопросы.
И никаких генеральных репетиций =)