В Scrum разработчики должны общаться напрямую с клиентами (минуя ПО)?

Как владелец продукта в Scrum должен иметь дело с очень подробными вопросами от команды относительно функций, которые они реализуют, на которые он не может сразу ответить сам? Когда разработчик определенно сможет быстрее связаться с самим клиентом?

Интересно, подрывает ли прямая связь между командой и заказчиком роль владельца продукта? Я чувствую, что ПО должно исключительно представлять клиента и поэтому отвечать на все вопросы, касающиеся требований, даже если это займет больше времени. Обход его, кажется, ослабляет его и в конечном итоге делает его лишним ...

Есть ли лучшая практика в схватке?

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

Хотя связь между ПО и заказчиком должна быть стандартной (по причинам, изложенным @PatrickHughes в его комментарии), вы можете столкнуться с ситуацией, когда необходимо прояснить сложное деловое требование и прямую связь между разработчиком и разработчиком. бизнес-эксперт сильно ускорит процесс. В такой ситуации следует избегать «китайского шепота» с ПО в середине и позволить разработчику и бизнес-эксперту напрямую общаться друг с другом - в этом ограниченном контексте.

Тем не менее, PO никогда не должен быть обойден. В идеале он принимает участие в этом разговоре, вероятно, в качестве модератора. Он может убедиться, что клиент не выдвигает совершенно новые требования на столе во время разговора или требования, противоречащие тому, что было согласовано ранее.

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

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

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

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

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