Владелец Продукта в SAFe®

Это устаревшая версия статьи, вместо нее рекомендуем читать обновленную версию: Владелец Продукта в SAFe® 6.0.

Вольный перевод статьи: Product Owner — Scaled Agile Framework.

«На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе».

Agile-манифест

Владелец Продукта

Product Owner (PO) или Владелец Продукта — это член Agile-команды, который отвечает за определение Историй и их приоритета в Бэклоге Команды в целях оптимизации выполнения первоочередных задач программы, сохраняя при этом концептуальную и техническую целостность Фич или компонентов для команды.

PO играет важную роль в максимальном увеличении ценности продукта, создаваемого командой, и обеспечении того, чтобы реализованные Истории отвечали потребностям пользователя и соответствовали Критериям Готовности (Definition of Done). Для большинства предприятий, переходящих на Agile, это новая и важная должность, обычно предполагающая полную занятость, так как один PO требуется для поддержки каждой Agile-команды (или, самое большее, двух команд).

Эта роль имеет важные связи и обязанности за рамками локальной команды, включая работу с Продуктовым Менеджментом (Product Management), Клиентами (Customers), Представителями Бизнеса (Business Owners) и другими заинтересованными лицами.

Владелец продукта — член Agile-команды, который выступает в роли доверенного лица клиента, ответственного за работу с Продуктовым Менеджментом и остальными заинтересованными лицами, включая других PO, для определения и приоритизации Историй в Бэклоге Команды. Это позволяет Решению (Solution) — продукту, услуге или системе, эффективно определять приоритеты Программы (Фичи и Enablers), сохраняя при этом техническую целостность. В идеале PO находится в одном месте с остальной командой, обычно разделяя с ними единые подходы к менеджменту, стимулам и культуре. Но PO также посещает соответствующие мероприятия Продуктового Менеджмента для планирования, уточнения Концепции (Vision) и Бэклога Программы (Program Backlog).

Обязанности 

PO выполняет следующие обязанности:

Подготовка и участие в PI-планировании 

• Как член расширенной команды Продуктового Менеджмента, PO активно участвует в уточнении Бэклога Программы и подготовке к Планированию Инкремента Программы (PI-планированию), а также играет важную роль в самом мероприятии по планированию. Непосредственно перед этим мероприятием PO, как правило, анализирует Бэклог Команды и вносит свой вклад в концепцию программы, Дорожную Карту (Roadmap) и содержание презентаций.
• Во время мероприятия PO участвует в определении Историй, предоставляя необходимые разъяснения, чтобы помочь команде с оценкой Историй и порядком их реализации. Agile-команда вместе с входящим в нее PO в сотрудничестве друг с другом работает над определением командных целей для предстоящего Инкремента Программы (Program Increment (PI)).

Выполнение Итерации

• Поддержка Бэклога Команды — при участии Системного Архитектора/Инженера (System Architect/Engineering) и других заинтересованных лиц, PO несет основную ответственность за формирование, изменение и поддержание в актуальном состоянии Бэклога Команды. Состоящий в основном из пользовательских Историй, бэклог также включает дефекты и Enablers. Элементы Бэклога распределяются по приоритетам на основе пользовательской ценности, времени и других зависимостей команды, определенных во время PI-планирования и уточняемых во время реализации PI.
• Планирование Итерации — PO просматривает и изменяет приоритеты Бэклога в рамках подготовительной работы к Планированию Итерации, включая координацию зависимостей с другими PO. Во время Планирования Итерации PO сообщает подробности Истории и приоритеты, а также обеспечивает согласованность и утверждение командой окончательного плана Итерации.
• Своевременная разработка Историй — большинство элементов Бэклога разрабатываются в формате пользовательских Историй. Это может произойти в любое время до начала Итерации, во время планирования Итерации или во время Итерации. Любой член команды может разрабатывать Истории и их Критерии Готовности, но PO поддерживает надлежащий ход этой работы.
• Применение BDD (Behavior-Driven Development) – Владельцы Продукта сотрудничают со своей командой, чтобы детализировать Истории с Критериями Готовности и примерами в форме приемочных тестов.
• Приемка Историй — РО работает с командой, чтобы согласовать приемлемый вариант завершения Истории. Это включает проверку: наличие соответствующих постоянных приемочных тестов и что в остальном она соответствует Критериям Готовности. При этом PO также обеспечивает определенный уровень качества, ориентируясь в первую очередь на пригодность к использованию.
• Понимание работы Enabler — хотя не ожидается, что Владельцы Продукта будут управлять технологическими решениями, они должны понимать объем предстоящей работы Enabler и сотрудничать с Системным Архитектором/Инженером, чтобы помочь с принятием решений и определением последовательности критически важных технологических инфраструктур, которые будут обеспечивать реализацию нового бизнес-функционала. Зачастую лучше всего этого добиться, установив распределение нагрузки.
• Участие в командной демонстрации и ретроспективе  — PO сотрудничают со своей командой и любыми другими заинтересованными лицами на командной демонстрации. Они также принимают участие в Ретроспективе Итерации, где команды собираются, чтобы улучшить свои процессы, и активно участвуют в сессии Инспекции и Адаптации (Inspect and Adapt, I&A) Agile Release Train (ART).

Выполнение Программы

• Итерации и Agile-команды служат важной цели: частый, надежный и непрерывный выпуск решений с добавленной ценностью. Во время каждого PI Владелец Продукта координирует зависимости с другими POs. Это часто происходит во время еженедельных мероприятий PO Sync.
• PO также играет важную роль в подготовке Системной Демонстрации (System Demo) для заинтересованных лиц программы и потока создания ценности (Value Stream).

Инспекция и Адаптация 

• Команды решают свои наиболее серьезные проблемы на I&A-встрече. Там PO работает с командами, чтобы определить и внедрить истории улучшений, которые повысят скорость и качество Программы.
• Системная Демонстрация PI (PI System Demo) является частью I&A-встречи. Владелец Продукта играет важную роль в организации и проведении Системной Демонстрации PI для заинтересованных лиц Программы.
• Чтобы гарантировать показ наиболее важных аспектов решения заинтересованным лицам, Владельцы Продуктов также участвуют в подготовке Системной Демонстрации PI.

Состав полномочий

SAFe® использует ряд артефактов, таких как Фичи, Истории, Нефункциональные Требования, артефакты дизайна и прочее, чтобы направлять ART во время создания решения. Бэклог Программы и Бэклог Команды определяют приоритетность этих рабочих элементов. Продуктовый Менеджер (Рroduct Мanager) и Владелец Продукта управляют Бэклогами и их приоритетами. Это сотрудничество работает наиболее эффективно при использовании дизайн-мышления (Design Thinking) и таких инструментов Непрерывного Изучения как Персоны (Personas), Карты Эмпатии (Empathy Maps), Карты Пути Клиента (Customer Journey Maps), Карты Историй (Story Maps), которые приносят открытия и больше понимания.

Ниже приведены рекомендации по разграничению обязанностей между этими ролями. В зависимости от размера и архитектуры решения (и в некоторой степени от культуры организации) полномочия могут стать более децентрализованными, смещаясь вправо. Например, стабильные Agile-команды, которые становятся все более осведомленными о проблемах клиентов и контексте решения, способны напрямую вносить непосредственный вклад в Фичи и Истории для управления продуктом (см. Принцип SAFe № 9 — Децентрализация принятия решений).

Модель взаимодействия Менеджера Продукта, Владельца Продукта и Agile-команд

Успешная разработка в крупной организации — это отчасти игра в числа. Без нужного количества людей на нужных ролях «узкие места» будут сильно ограничивать скорость. Следовательно, количество Менеджеров Продукта, Владельцев Продукта и Agile-команд должно быть примерно сбалансированным, чтобы управлять ART. Иначе вся система будет тратить большую часть своего времени в ожидании определения, разъяснения и принятия решений. Вместо этого SAFe рекомендует модель разветвления, как показано на рисунке ниже.

Как правило, в схеме взаимодействия в рамках единой концепции участвуют:

• Менеджер Продукта, ориентированный на рынок/клиента.
• Владелец Продукта, ориентированный на решение, технологию и команду.
• Agile-команды, ориентированные на реализацию.

Каждый Менеджер Продукта обычно может поддерживать до четырех Владельцев Продукта, каждый из которых может отвечать за Бэклог одной или двух  Agile-команд.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.