Вот Сергей. Он — владелец продукта. У него есть видение, как все должно работать, какие проблемы продукт решит, для кого он и зачем. В технической части Сергей не силен.
А вот заинтересованные лица/пользователи/стейкхолдеры. Они будут использовать, поддерживать продукт, вносить свои идеи и предложения.
Пожелания заинтересованных сторон к продукту выражены в пользовательских историях. Например, что «в системе бронирования авиабилетов пользователь может посмотреть даты прямых рейсов», «администратор интернет–магазина может удалять, добавлять и редактировать позиции в каталоге».
Но идей у стейкхолдеров много. И Сергей помогает оформить их в пользовательские истории.
Все эти задумки кто–то должен реализовать. И тут на сцену выходит команда разработки. Они могли бы посмотреть на пользовательские истории, начать пилить продукт, а через несколько месяцев (а, может, год или больше) представить его готовым и упакованным заинтересованным лицам. Но нет. Команда работает по гибкой методологии Agile. Поэтому не делает весь продукт сразу. Они стараются с самого начала выпускать готовый функционал. По кусочкам. И тут же демонстрирует его стейкхолдерам и всем заинтересованным. На практике у большинства команд разработки получается делать по 4-6 пользовательских историй в неделю. На каждую историю команда создает автотесты.
И все бы хорошо, но у заинтересованных лиц идей больше, чем 4-6 в неделю. Если команда будет делать все, что они хотят, то придется выпускать в неделю по 10-12 пользовательских историй. Члены команды начнут жестко стрессовать, часто переключаться между задачами, жертвовать качеством, чтобы все успеть.
Пробил час владельца продукта. Он все обсуждает со стейкхолдерами и командой. Вместе они выбирают, какие 4-6 историй команда будет «пилить» на следующей неделе. Проще говоря, расставляют приоритеты.
Каким–то идеям владелец продукта должен будет сказать: «нет». Какие–то — поставит на первое место в очереди на разработку. Ценность и размер истории также обсуждается с командой и стейкхолдерами.