Чому в Scrum не слід поєднувати ролі Власника продукту та ScrumMaster?


19

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

Однак у Scrum ці обов'язки розподілені між власником продукту та ScrumMaster. Власник продукту - це голос замовника. Вони взаємодіють безпосередньо із замовником, створюють історії користувачів, упорядковують і визначають пріоритет щодо відставання продукту та інших проблем, які стоять перед користувачем та замовниками. ScrumMaster опрацьовує процес, контролюючи зустрічі (включаючи оцінку та планування), усуваючи перешкоди та контролюючи загальний стан здоров’я проекту, вносячи корективи за потребою.

Я читав у багатьох джерелах, включаючи Вікіпедію , що роль ScrumMaster та Власника продукту повинні виконувати дві різні люди. Я не тільки читав, але працював над успішними проектами в «традиційному» стилі, де діяльність обох здійснювала одна людина. Насправді, має сенс для однієї-трьох осіб відповідальність за обробку проектів (включаючи людські ресурси / персонал) та завдання на рівні процесів, оскільки вони часто йдуть рука об руку. Зміни процесу впливають на планування, складання бюджету, якість та інші цілі на рівні проекту, і зміни проекту впливають на процес.

Чому Scrum закликає виділити ці дії на дві ролі? Які переваги це насправді забезпечує? Хтось був на успішному проекті Scrum, де Власник продукту та ScrumMaster були однаковими особами?


Крім того, я клянусь, це питання вже було задано, але я не можу його знайти, і я не позначив його як улюбленого. Тут багато питань щодо визначення ролей, але я не бачу PO / SM, який я впевнений, що читаю.
Томас Оуенс

Ви думаєте над цим питанням ?
Адам Лір

@Anna Це виглядає звично, але насправді це не дублікат. Я думаю, що цього конкретного питання, можливо, раніше не задавали.
Томас Оуенс

Як щодо цього ? :)
Адам Лір

1
Я рекомендую прочитати « Успіх з Agile», де це обговорюється більш докладно.
Ладислав Мрнка

Відповіді:


17

Вони можуть (і часто бувають) поєднані і зроблені однією людиною (проти цього немає правила (все-таки її скандал)).

Але вам потрібно ретельно врівноважувати різницю відповідальності, оскільки обидві ролі мають змагання та порядок денний (і для того, щоб обидві могли виконувати обидві функції, потрібна спеціальна людина). Я бачив багато спроб, але мало хто знімає це протягом тривалого періоду часу (його стресова позиція).

  • Для того, щоб бути SM, вам потрібні більше технічних знань, ніж спеціаліст (як ви будете допомагати в організації команди розвитку). Потрібно детальне знання продукту, щоб мати змогу витягувати речі з продуктового продукту до весняного відставання (іноді ви просто не можете витягнути топ 'n' елементів, оскільки це може бути контрпродуктивним).

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

Якщо ви можете знайти людину, яка може виконувати обидві ролі, то я не бачу причин, щоб перешкодити цьому.

Проблеми можуть виникнути, коли замовник витягує замовника в одному напрямку, що спричиняє значні чвари у розробників (адже їм потрібно спочатку побудувати якусь іншу інфраструктуру). Завдання SM - не слідувати примхам замовника, а захистити розробників від їх примх. Об'єктивно зняти це важко.


1
Так, як я бачу, саме конфлікт інтересів викликає проблему. Власник продукту хоче зробити якомога більше зробленого, майстру scrum потрібно керувати очікуваннями власника продукту.

1
Ваш опис СМ неправильний. Ви описуєте щось на кшталт лідера команди, а не SM.
Ладислав Мрнка

1
Я з цим категорично не згоден. PO та SM - це дві дійсно різні роботи. borisgloger.com/2009/12/07/…

@Pierre Це посилання було розміщено у відповіді. Як я вже говорив у відповідь на цю відповідь, всі, крім 3, мають контргументи, які я можу придумати прямо тут і зараз, а 3 є такими загальними, що стосуються кожної посади будь-коли.
Томас Оуенс

3
Також не забудьте перевірити цю публікацію, яка спеціально розповідає про це: blog.mountaingoatsoftware.com/… . Якщо змішування ролей працює для вас, я обіцяю вам, що надішлю вам коробку бельгійських шоколадних цукерок.

4

Я не експерт, але думаю, що майстер Scrum повинен бути адвокатом команди / фасилітатором. Голос замовника повинен мати душевні інтереси замовника. Майстер Scrum повинен бути в тому, щоб допомогти команді отримати те, що потрібно для успішного спринту.


1

Крім того, майте на увазі, найчастіше, ви не працюєте над одним клієнтом одночасно. Власники продуктів можуть керувати кількома клієнтами і можуть сконцентруватися на цій частині бізнесу, а ScrumMasters можуть зосередитись на розробці проектів.

Як і багато хто говорив, обидві ролі мають чіткі інтереси, але спільна мета та різні набори навичок, щоб набути її.


Це може бути правдою. Кожне місце, де я коли-небудь працював, персонал "проекту" (еквівалент ОП та ПМ) був присвячений одному проекту, тож це єдина в мене система орієнтирів. Команда розробників може бути призначена для декількох проектів, але, як правило, навіть розробник призначається одному проекту на повний робочий день і підтримує ролі одного або двох інших.
Томас Оуенс

0

Якщо одна і та ж особа представляє команду розробників та користувачів / клієнтів, єдиний заклик, який ви маєте в суперечці, - це переглянути договір. Хоча в кінцевому підсумку це може прийти до цього, вам краще, якщо представник обох сторін, що мають рівну владу, може розробити угоду.


Якщо організація закупівлі не є організацією замовника (що, наскільки я розумію, часто трапляється), вам все одно доведеться подивитися на договір, якщо між організацією, що розвивається (включаючи PO), і замовником виникає суперечка.
Томас Оуенс

1
Це правда, але якщо клієнтський захисник не може вирішити незгоду, перш ніж він повернеться до замовника. Якщо вони обоє не згодні з замовником, це вже інше питання.
JeffO

0

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.