В Scrum, почему нельзя объединять роли владельца продукта и ScrumMaster?

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

Однако в Scrum эти обязанности распределены между владельцем продукта и ScrumMaster. Владелец продукта - это голос клиента. Они взаимодействуют напрямую с клиентом, создают пользовательские истории, упорядочивают и расставляют приоритеты в невыполненных продуктах и ​​других проблемах, возникающих у пользователей / клиентов. ScrumMaster управляет процессом, наблюдая за собраниями (включая оценку и планирование), устраняя препятствия и отслеживая общее состояние проекта, внося коррективы по мере необходимости.

Я читал во многих источниках, включая Википедию , что роль ScrumMaster и Product Owner должны выполнять два разных человека. Я не только читал о, но и работал над успешными проектами в «традиционном» стиле, где действиями обоих занимался один человек. Фактически, более разумно, чтобы от одного до трех человек отвечали за управление проектами (включая работу с персоналом / персоналом) и задачи на уровне процессов, поскольку они часто идут рука об руку. Изменения процесса влияют на планирование, бюджетирование, качество и другие цели на уровне проекта, а изменения проекта влияют на процесс.

Почему Scrum призывает разделить эти действия на две роли? Какие преимущества это дает на самом деле? Кто-нибудь участвовал в успешном проекте Scrum, где владелец продукта и ScrumMaster были одним и тем же человеком?

Они могут (и часто) объединяются и выполняются одним человеком (против этого нет правил (в конце концов, это схватка)).

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

• Чтобы стать СМ, вам нужно больше технических знаний, чем ПО (так как вы будете помогать организовать команду разработчиков). Требуются детальные знания о продукте, чтобы можно было вытягивать вещи из задела продукта в залежу пружины (иногда вы просто не можете вытащить верхние элементы 'n', поскольку это может привести к обратным результатам).

• PO требует большего понимания пользовательского конца уравнения, чем их SM. Это не обязательно должно быть так же технически, но требует знания того, как продукт будет использоваться в реальном мире, и направления, в котором клиент хочет принять продукт.

Если вы можете найти человека, который может выполнять обе роли, то я не вижу причин, чтобы это предотвратить.

Проблемы могут возникнуть, когда заказчик вытягивает ПО в одном направлении, что вызывает значительную напряженность у разработчиков (потому что им нужно сначала построить какую-то другую инфраструктуру). Работа SM заключается не в том, чтобы следовать капризам заказчика, а в том, чтобы защитить разработчиков от их капризов. Осуществить это объективно сложно.

Я не эксперт, но я думаю, что Scrum Master должен быть защитником команды / фасилитатором. В голосе клиента должны быть интересы клиента. Scrum Master должен помочь команде получить то, что им нужно для успешного спринта.

Кроме того, имейте в виду, что чаще всего вы не работаете с 1 клиентом одновременно. Владельцы продуктов могут управлять несколькими клиентами и могут сосредоточиться на этой части бизнеса, а ScrumMasters может сосредоточиться на разработке проектов.

Как многие уже говорили, обе роли имеют разные интересы, но имеют общую цель и разные навыки для достижения этой цели.

Если один и тот же человек представляет команду разработчиков и пользователей / клиентов, единственное решение, которое у вас есть в споре, - это посмотреть контракт. Хотя это может в конечном итоге привести к этому, вам будет лучше, если представитель обеих сторон с равной властью сможет выработать соглашение.

Люди в ролях Владелец продукта и Scrum Master могут иметь противоречивые желания, цели, требования и ограничения, более чем 2 случайных программиста. Люди могут или не могут одинаково хорошо оценивать конфликтующие цели и могут с большей вероятностью делать ошибки в суждениях, сталкиваясь с конфликтующими целями. Два человека с немного разными фокусами или уклонами могут с меньшей вероятностью совершить одну и ту же ошибку или одинаковую степень ошибки в суждении.

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