В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.
Почему PBR важен
PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.
Разработчики общаются с клиентами напрямую
Очень часто замечаю дисфункциональные имплементации Скрама, когда между разработчиками и рынком стоят промежуточные лица, препятствующие прямой коммуникации и являющиеся источником потерь. Примеры потерь:
- промежуточные артефакты (BRD, спецификации и т.д.);
- многочисленные передачи, как результат, искажение и потеря информации;
- низкая скорость принятия решений;
- отсутствие эмпатии у разработчиков по отношению к клиентам/пользователям продукта;
- непонимание разработчиками бизнес-домена.
Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки.
Такой подход лежит в основе масштабируемого Скрама. Когда продукт разрабатывают много команд, то у Владельца Продукта не хватает времени на прояснение элементов Бэклога Продукта. Он делегирует эту активность командам и оставляет за собой упорядочивание Бэклога Продукта.
Читать далее «Эффективный PBR часть I»В масштабируемом Скраме команды выясняют детали требований напрямую со стейкхолдерами. Владелец Продукта оставляет за собой упорядочивание Бэклога Продукта.