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