Scrum: Что, если у Владельца продукта есть задачи?

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

Целесообразно ли смешивать задачи владельца продукта (которые в основном включают исследования) с задачами команды (некоторые из которых - исследования и некоторые разработки).

Эксперты в Scrum очень твердо заявляют, что Владельцем продукта и Scrum Master должны быть два разных человека. Тем не менее, не существует такого правила, исключающего из команды разработчиков. Примечание в Scrum Guide :

Размер команды разработчиков

Оптимальный размер команды разработчиков достаточно мал, чтобы оставаться гибким, и достаточно большим, чтобы выполнить значительную работу. Менее трех членов команды разработчиков снижает взаимодействие и приводит к меньшему повышению производительности. Меньшие команды разработчиков могут столкнуться с ограничениями навыков во время спринта, из-за чего команда разработчиков не может предоставить потенциально выполнимый Прирост. Наличие более девяти членов требует слишком большой координации. Большие команды разработчиков создают слишком много сложностей для управления эмпирическим процессом. Роли «Владелец продукта» и «Scrum Master» не включаются в этот счет, если они также не выполняют работу журнала «Спринт».

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

Тем не менее, делайте все возможное, чтобы ваша работа была выполнена хорошо.

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

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

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

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

Итак, попробуйте. Сделайте ретроспективу, чтобы вы могли постоянно улучшать свой процесс. Не позволяйте ранее придерживаться какой-либо методологии, чтобы помешать производительности вашей команды.