Эффективный PBR часть I

В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.

Почему PBR важен

PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.

Разработчики общаются с клиентами напрямую

Очень часто замечаю дисфункциональные имплементации Скрама, когда между разработчиками и рынком стоят промежуточные лица, препятствующие прямой коммуникации и являющиеся источником потерь. Примеры потерь: 

  • промежуточные артефакты (BRD, спецификации и т.д.);
  • многочисленные передачи, как результат, искажение и потеря информации;
  • низкая скорость принятия решений;
  • отсутствие эмпатии у разработчиков по отношению к клиентам/пользователям продукта;
  • непонимание разработчиками бизнес-домена.

Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки. 

Такой подход лежит в основе масштабируемого Скрама. Когда продукт разрабатывают много команд, то у Владельца Продукта не хватает времени на прояснение элементов Бэклога Продукта. Он делегирует эту активность командам и оставляет за собой упорядочивание Бэклога Продукта.

В масштабируемом Скраме команды выясняют детали требований напрямую со стейкхолдерами. Владелец Продукта оставляет за собой упорядочивание Бэклога Продукта.

Читать далее «Эффективный PBR часть I»