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

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

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

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

scrum communication product-owner

— tizenegy
источник

Я должен согласиться с вами, что владелец должен быть единственной точкой контакта между разработчиком и заказчиком. Я не согласен с тем, что причина в том, что владелец продукта не нужен, или что роль обходится быстрее. Я скажу так: в проекте с 10 разработчиками не нужно, чтобы 10 человек постоянно разговаривали с заказчиком и обсуждали функции. Во-первых, это раздражает клиента, во-вторых, от реального развития уходит время. Если вы заблокированы для всех задач, потому что вам нужно больше информации, вам нужно исправить фазу сбора требований, а не пытаться исправить владение.

— Патрик Хьюз

«Когда это, несомненно, будет более быстрым решением ...» Просто хочу указать на очевидное: быстрее не обязательно лучше.

— Эрик Кинг,

Ответы:

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

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

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

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

— Док Браун
источник

«Вся идея Agile-разработки заключается в том, чтобы не придерживаться какого-либо груза культа или учебника, а включить свой мозг и делать все, что лучше всего работает в проекте». Верно, но эта идея не является специфичной для agile.

— Джорджио

+1, если ловко заниматься скрамом, то бизнес-эксперт, вероятно, будет частью команды и в любом случае доступен ...

— Марьян Венема

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

— Gort the Robot

@ StevenBurnap, это означало бы, что ПО должно быть экспертом в этой области с самого начала ... по моему опыту, это не всегда так.

— tizenegy

@ Джорджио: безусловно, ИМХО «Agile development» - это просто модное слово, которое включает в себя некоторые хорошие привычки, которые намного старше термина и не ограничиваются самим собой.

— Док Браун,

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

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

— Ewan
источник

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

— jwenting

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

— Ewan

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

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

— jwenting
источник

«Линии не могут быть короче, чем когда ваш будущий пользователь сидит рядом с вами во время кодирования :)»: сомнительно, всегда ли это хорошо.

— Джорджио

@ Джорджио, конечно, зависит от вовлеченных людей. Но это то, что продвигает SCRUM (и Agile-практики в целом): короткие линии, быстрое принятие решений. В нашем случае это работает, потому что клиент действительно полон энтузиазма и хочет, чтобы продукт преуспел, но он также достаточно реалистичен, чтобы понять, что не все возможно (конечно, не в рамках бюджетных и технических ограничений, с которыми нам приходится работать).

— jwenting

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

— Джорджио

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

— tizenegy