Когда видение, стратегия и приоритеты продукта установлены, требуется тщательный контроль над разработкой. Продакт оунер наблюдает за процессом выполнения итераций, планирует следующие, проводит еженедельные стендапы разработчиков, планирование, ретроспективу совместно со SCRUM-мастером, анализирует эффективность, и ставит сроки для следующего спринта, в рамках которого команда будет готова показать ценную реализованную часть продукта. На спринте планируется, какой пул работ будет реализован, а командой проставляются оценки задач в рамках пользовательских историй.
Самое главное не написано, что PO это роль с фреймворке SCRUM и вне его существовать не может.
Да и насчёт того, что "гибкий подход. Он намного эффективнее, чем некогда популярный каскадный" - всё не так однозначно. Намного это насколько? Кто считал, какой мат аппарат применял, сколько раз проводил контрольные замеры, какова выборка? "Каскадная" разработка цвётет и пахнет и помирать не собирается. У ажаля есть жёсткие границы применимости, тут нужно Cynefin "курить" для понимания. Короч, статья слабая, надо стараться лучше.
Всё зависит от проекта. Для некоторых (очень редких) проектов каскад ещё может работать. Для большинства проектов Agile просто необходимость. За 10 лет работы, я заметил что проекты реализованные по Agile самые полезные для клиентов и оказали самое сильное влияние на продуктивность компании клиента.
Комментарий недоступен
Заказчиков может быть много. И их интересы могут конфликтовать.
Господа InfoShell, saas сервисы разрабатываете "под ключ"?
Да, Вячеслав, разрабатываем. Напишите, пожалуйста, на почту kirill@infoshell.ru или сделайте запрос здесь: https://infoshell.ru
Как мы можем связаться с вами?