Владелец продукта также является разработчиком в вашей команде?

Я запутался по поводу ответственности ПО здесь. Я был разработчиком в Game Feature Team, но также и в ПО. Ежедневная работа разработчика почти полностью занята, поэтому мне приходится со временем работать, чтобы позаботиться о своей обязанности ПО, и ответственность ПО, по-видимому, противоречит мыслям разработчика.

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

Я новичок в Scrum и Game Dev (около полутора лет), а также новичок здесь и в английском.

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

То, что сводится к тому, «есть ли у вас товары для принятия этих решений?» Если вы думаете, что сделали, сделайте это!

По моему опыту, владелец продукта - либо PM / TPM, либо член бизнес-команды. Хотя ПО не может быть разработчиком, существует некоторая опасность конфликта интересов. Если ваш продукт высокотехнологичный, ПО должно иметь опыт разработки. Если он менее технический и более ориентирован на конечного пользователя, тогда критически важно наличие ПО с опытом работы в бизнесе.

Как программист (если вы хороший), вы будете инвестированы в ваш код. Как владелец или менеджер, вы должны быть инвестированы в продукт.

Это не всегда одно и то же. А когда их нет, у тебя будут большие проблемы.

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

Владельцы должны смотреть на общую картину, программисты должны смотреть на детали. Вы не можете делать и то и другое, если вы не Бог!

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

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

Интересно, что я даю советы парню по имени Чарли, (меня зовут Чарльз), но у меня есть некоторый опыт в роли двойного помощника в качестве разработчика / разработчика, и по моему опыту, ОЧЕНЬ легко зацикливаться на одном роль или другой.

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

В идеале я бы рекомендовал вам не смешивать эти роли, поскольку они, как вы заметили, довольно сильно конфликтуют друг с другом.

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

Я понимаю общие проблемы баланса между двумя ролями, но я не понимаю ваших конкретных проблем.

Развитие - это только постоянная роль, если вы сделаете это так. Если при планировании спринта вы считаете себя всего лишь 50% (при подсчете всех доступных часов / дней для разработчиков), у вас должно быть достаточно времени для выполнения ваших обязанностей по доставке.