У Scrum, чи повинні розробники спілкуватися безпосередньо з клієнтами (оминаючи PO)?

Як власник продукту в scrum має вирішувати дуже детальні запитання команди щодо функцій, які вони реалізують, що він не може миттєво відповісти собі? Коли б, очевидно, було швидше рішення для розробника безпосередньо поговорити з самим замовником?

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

Чи є найкраща практика в scrum?

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

Хоча спілкування між PO та замовником повинно бути стандартним (через причини, описані в коментарі @PatrickHughes), ви можете зіткнутися з ситуацією, коли складні вимоги бізнесу повинні бути роз'яснені та пряме спілкування між розробником та a бізнес-експерт значно пришвидшить справи. У такій ситуації слід уникати грати «китайський шепіт» з PO в середині, і дозволити розробнику та бізнес-експерту безпосередньо поговорити один з одним - для цього обмеженого контексту.

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

Це залежить і від залучених людей, і від ситуації. ОП можуть мати достатню довіру до конкретного розробника та експерта замовника, щоб вони дозволили двом поговорити на певну тему та дати йому змогу повідомити про те, що було сказано після цього. В іншій ситуації, якщо інші люди беруть участь, він може вважати за краще брати більш активну участь. Правильне прийняття цих рішень є основою хорошого управління проектами.

Ви повинні пам’ятати, що клієнт компанії, яка працює на вас як розробник, має різні цілі перед компанією, яка працює на вас.

Власник товару повинен представляти цілі вашої компанії, а не цілі замовника. Тож якщо чорти прямують до замовника, вони можуть підірвати їх власну компанію.

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

Ідеальний приклад - це, мабуть, команда, з якою зараз працюю. Власник продукту - це старший кінцевий споживач та доменний експерт з повною повноваженням авторизувати дизайнерські рішення на місці (та готовність та здатність насправді це робити). Він є невід'ємною частиною команди і безпосередньо допомагає аналітику та дизайнеру в написанні історій користувачів, а також програмістів і тестувальників у створенні продукту, надаючи майже миттєвий зворотній зв'язок з питаннями впровадження та тестовими сценаріями.
Рядки не можуть бути коротшими, ніж ваш майбутній користувач сидить поруч із вами під час кодування :)