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