Должен ли владелец продукта следить за более чем одним продуктом?

Question

В команде Scrum или Agile рекомендуется, чтобы владелец продукта участвовал в нескольких продуктах? Хорошо ли иметь владельца продукта для системы предприятия и «суб» владельцев продукта для компонентов этой системы? т. е. у розничного торговца у вас есть ПО для корпоративной системы, которая управляет «под» ПО, например, по розничной торговле, цепочке поставок и производству?

Заинтересованы в том, как другие имеют дело с командами Scrum в корпоративной среде со многими заинтересованными сторонами в функциональных силосах.

Answer 1

In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product? 

Прежде всего, вы должны понимать, что у вас не будет объективного ответа на это в Scrum. Вам придется проверять и адаптироваться. Нигде в «Руководстве по Scrum» (написанном изобретателями Scrum) упоминается, что PO не должен обрабатывать более двух продуктов, но они упоминают, что для успешного завершения работы POP он должен взять на себя полную ответственность за Продукт и организация должна уважать решение ОО. ПО - это «свинья» из отставания продукта, будь то для 1 или 2 или более продуктов, если ПО и Заинтересованные стороны могут справиться с этим, я бы попробовал его и проверил и адаптировал , И есть различные факторы, также как и сложность продуктов, и то, как в них участвует специалист по продуктам, и сколько пропускной способности ПО должно выполнять обязанности PO для более чем одного продукта. Перед тем, как попробовать, учтите все их.

Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system? i.e. In a Retailer would you have a PO for the enterprise system that drives "sub" PO's for say Retail, Supply Chain and Manufacturing? 

Снова вам нужно попробовать в своей организации, чтобы узнать, является ли оно «хорошим». Просто следуйте правильным рекомендациям Scrum при назначении PO или субпользователей. Я попробовал это в своей организации, и это сработало чудеса! У нас было начальное ПО и несколько других PO, которые вы можете назвать вспомогательными PO, но я предпочитаю держать всех на одном уровне, чтобы избежать командного и контрольного поведения, которое при неправильном использовании может испортить проект. Основная задача POs заключалась в том, чтобы удостовериться, что POs успешны в том, что они делают, а также помогают POs при необходимости. Также назначение PO может быть сделано главным ПО вместе с главным SM или SM.Если я могу немного отвлечься, то с той же структурой следуют SM. Задача Главного SM заключалась в том, чтобы помочь СМ преуспеть в выполнении своей работы, например, если СМ не может устранить препятствия, с которыми он или она мог бы заставить Главного СМ прийти к картине, чтобы помочь разрешить ее.

Be interested in how others deal with Scrum teams in an enterprise environment with many stakeholders in functional silos. 

Как я уже говорил выше. У нас было главное ПО и несколько других ПО в нашей корпоративной среде. Был также руководящий комитет, в который вошли заинтересованные стороны. У каждого ПО был своя собственная отсталость продукта для управления. У нас было 2 недели Спринтов. Дважды в месяц у нас было совещание под названием «Совещание Руководящего комитета», в котором все заинтересованные стороны и главные ПО и ПО встречались и управляли продуктом Enterprise в правильном направлении, и каждое из ПО переводило работу в терминах Scrum (потенциально поставляемый пользователь рассказы) для каждой из своих продуктов, главное ПО занимало решающее место в обучении и защите ПО от заинтересованных сторон и членов, которые мало знали о Scrum Framework. Они защищали ПО от угона. У каждого ПО была собственная команда Scrum с SM и членами команды. Я бы предложил, чтобы главный ПО был тренером Agile с хорошим удержанием в организации. Также были размещены PO-адреса, что особенно помогает в разрешении зависимостей и проблем кросс-команды.

Примечание. : Одна вещь, которая не сработала для нас, - это 2 ПО для одной команды с одним отставанием продукта, было слишком много конфликтов s между ПО!

Надеюсь, это поможет.

Answer 2

Владелец продукта может быть в этой роли для нескольких продуктов, в зависимости от их размера. С другой стороны, у вас может быть несколько владельцев продуктов для подкомпонентов более крупного корпоративного приложения. Затем у вас есть «Главный владелец продукта».

Это совершенно правильно и целесообразно.

Все эти понятия подробно изложены в книге Agile Product Management With Scrum: Creating Products That Customers Love, написанной Roman Pichler.

Я видел привет и разговаривал с ним много раз в Scrum Gatherings. Его специализация - Владельцы Продуктов.

Answer 3

Я был ScrumMaster в аналогичной ситуации. У вас могут быть «суб» владельцы продуктов или «совместные» владельцы продуктов для подсистемы ваших усилий по развитию; на предприятии это довольно распространено. Они по сути становятся «командой владельца продукта», которая также может включать бизнес-аналитиков.

Однако у вас должно быть назначенное «руководство» для этой команды владельца продукта; кто может урегулировать разногласия и установить общие приоритеты для отставания. Этот человек должен убедиться, что потребности всех других владельцев продукта выполнены. На практике это обычно было менеджером проекта.

Альтернативный подход разделяет подпроекты в отдельные группы схватки, а затем имеет «схватку схваток»; но я не думаю, что это будет работать для одного проекта разработки, поскольку это создаст более сложный поток информации между командами. Если каждый субпроект не может функционировать независимо друг от друга, я бы предложил первый подход.

Answer 4

В команде Scrum или Agile рекомендуется, чтобы владелец продукта участвовал в нескольких продуктах?

Пока ПО может работать на Отставание (ы) продукта, чтобы получить набор приоритетных Отставание продукта Пункты перед каждым спринте, является максимизация ROI, и доступен для команд (ы) в течение Sprint (другими словами, пока PO выполняет свою работу), это должно быть хорошо. Если это не так, основные препятствия будут быстро подняты.

Хорошо ли иметь владельца продукта для системы предприятия и «суб» владельцев продукта для компонентов этой системы?

Это на самом деле типичный образец при использовании Scrum of Scrums для масштабирования Scrum. И масштабирование Scrum для всей компании, безусловно, выполнимо (Scrum был разработан для бесконечной масштабируемости --Jeff Sutherland), а Scrum уже использовался с огромными командами (более 500 человек).

Но я бы, конечно же, не пытался масштабировать Scrum всей компании напрямую, есть шаги, которые следует предпринять для развертывания Enterprise Scrum/Agile, и не делать этого было бы безумным (хороший рецепт отказа).

У ралли есть IMO удивительные презентации, официальные документы и сообщения в блогах по этой теме (ну, они не единственные, но мне понравилось читать их материал). От всей души предлагаю взглянуть:

• Leaning IT: Applying the Principle of Pull to Scale Agile Teams (белая бумага, требуется регистрация)
• Enterprise Agile Rollout (PDF)
• Rally Agile Services: Flow > Pull > Innovate
• Archived Posts from the Agile Adoption Category

Я уверен, что вы» После ознакомления с некоторыми из этих ресурсов, вы получите лучшую картину.Но я не говорю, что это легко.