PO - 06 - Review

From Gehtsoft USA
Jump to: navigation, search

Цель:

  • Понять зачем PO и команде нужно Review
  • Понять важность DoD для определение Review

Тезисы:

Ревью - для получение feedback. Но какого feedback?

Это НЕ о feedback думает ли заказчик/стейкхолдер/юзер что продукт работает корректно

Проверка что продукт работает корректо - это отвественность команды. Если она перекладывается на пользователя - это значить команда не кросс-функциональна, а пользователь для неё external depdendency.

Это НЕ демонстрация что сделала команда, потому что нас не интересует мнение "сделали ли команда" (если только у нас не было рабочей гипотезы проверить "способна ли конкретная команда сделать")!

Это проверка гипотезы что создание releasable increment достигнет цели спринта.

Соотвествено демонстрация должна быть о том как именно достигаются цели спринты при помощи полученного increment и согласен ли заказчик/пользователь/стейкхолдер что в результате реально можно получить business value.

Полезно еще при планировании спринта СРАЗУ понять как именно мы будем при помощи созданного PBI доказывать цель спринта.

Даже если цель спринта техническая - автотесты, скажем. Полезно показать как автотест находит ошибку. Полезно показать наглядно насколько автотест быстрее. Но просто показ работающего автотеста - это приглашение заказчику 'догадайся сам', так быть не должно.

При планировании показа полезно помнить FURPS, не только показывать что это возможно (F), но и то что это удобно, быстро, устойчиво к ошибкам и легко в поддержке и развитии.

Вторая важная часть review - это получить feedback об уже находящихся в эксплуатации частях продукта (как это нету? а как же КАЖДЫЙ релиз - releasable increment?) и узнать о том, что изменилось в видении продукта заказчиком. ВАЖНО - продукт меняется не только потому что мы его разрабатываем, продукт еще меняется от того, что меняется заказчик и меняется среда вокруг него.