Le Product Owner est-il également développeur dans votre équipe?

Je suis confus quant à la responsabilité du PO ici. J'étais développeur dans une équipe de fonctionnalités de jeu, mais également PO. Le travail quotidien du développeur est presque à plein temps, je dois donc travailler au fil du temps pour prendre soin de mon devoir de PO, et la responsabilité de PO semble aller à l'encontre des pensées du développeur.

En tant que PO, je choisirai plus de fonctionnalités au prochain sprint. Sinon, je me dirai de ne pas le faire, car je suis un membre de l'équipe pour développer ces fonctionnalités. Cette situation me rend confus, donc je veux entendre des idées de vous.

Je suis nouveau dans Scrum et Game Dev (environ 1 an et demi), et aussi nouveau ici et en anglais.

Cela peut sembler un peu gênant, mais il ne devrait vraiment pas y avoir de raison de combiner ces rôles. D'une part, quelqu'un vous a fait confiance pour ce rôle, donc votre équipe doit le respecter. Deuxièmement, vous êtes maintenant dans une position où vous pouvez hiérarchiser le travail qui doit être fait afin que vous puissiez toujours expliquer pourquoi les choses se passent comme elles sont. Troisièmement, vous faites partie de l'équipe et vous transportez donc votre part de la charge de travail. Enfin, c'est un travail, si vous devez travailler dur, c'est très bien. Une équipe doit toujours se rappeler d'ajouter de la valeur à son projet, il ne s'agit pas de distribuer gratuitement.

Cela revient à dire: "Avez-vous les marchandises nécessaires pour prendre ces décisions?" Si vous pensez que oui, faites-le!

D'après mon expérience, le propriétaire du produit est soit un PM / TPM ou un membre de l'équipe commerciale. Bien qu'il ne soit pas impossible pour l'OP d'être un développeur, il existe un risque de conflit d'intérêt. Si votre produit est très technique, le bon de commande doit avoir une formation en développement. S'il est moins technique et plus axé sur l'utilisateur final, un bon de commande avec une expérience biz est essentiel.

En tant que programmeur (en supposant que vous êtes un bon), vous serez investi dans votre code. En tant que propriétaire ou gestionnaire, vous devez être investi dans le produit.

Ce ne sont pas toujours la même chose. Et quand ils ne le sont pas, vous aurez de gros problèmes.

J'ai toujours dit que le rôle d'un bon manager est de bloquer la merde d'en haut et de me voler mon code quand c'est assez bon. Sans gestionnaire, je pourrais travailler sur une seule fonction pour le reste de ma vie, pour toujours l'améliorer.

Les propriétaires doivent regarder la situation dans son ensemble, les programmeurs doivent regarder les détails. Vous ne pouvez pas faire les deux sauf si vous êtes Dieu!

Comme cela est défini dans Scrum traditionnel, il n'y a pas de problème avec un développeur fonctionnant également en tant que Product Owner. Cependant, vous devez faire attention lorsque vous prévoyez de tenir compte de toute personne qui exécute son rôle à temps partiel, soit parce qu'elle travaille sur plusieurs projets ou parce qu'elle a plusieurs rôles dans la même équipe. Dans votre cas, vous ne pouvez pas vous considérer comme un développeur à temps plein, car vous devez prévoir du temps à chaque itération pour effectuer les tâches du propriétaire du produit.

Je pense que vous avez également une mauvaise compréhension de ce que fait le Product Owner. Il n'est pas de votre responsabilité de choisir les fonctionnalités qui entrent dans une itération. Au lieu de cela, c'est votre travail d'être la voix du client sur le projet, lorsqu'il s'agit d'introduire de nouvelles histoires, d'attribuer des priorités à ces nouvelles histoires et de vous assurer que la mise en œuvre de chaque histoire est acceptable grâce à la création et à l'exécution de tests d'acceptation. Le choix des histoires est basé sur la vitesse de l'équipe et le carnet de commandes prioritaire, et non pas sur le nombre d'histoires que le Product Owner veut mettre en œuvre.

Intéressant que je donne des conseils à un gars du nom de Charlie, (je m'appelle Charles) mais j'ai une certaine expérience dans le double rôle en tant que dev / PM, et d'après mon expérience, il est TRÈS facile de s'emballer trop dans un rôle ou l'autre.

Si vous êtes en mesure de garder le contrôle sur les deux rôles, faites-le, mais prévoyez votre temps et limitez le contexte entre ces deux rôles au minimum absolu, en particulier en une seule journée.

Idéalement, je vous recommande d'éviter de mélanger ces rôles, car ils sont, comme vous l'avez remarqué, un peu en conflit les uns avec les autres.

Presque toujours une mauvaise idée. Nous avions un chef de projet qui était propriétaire d'un produit et c'était assez conflictuel.

Je comprends les problèmes généraux d'équilibre entre les deux rôles, mais je ne comprends pas vos préoccupations spécifiques.

Le développement n'est un rôle à plein temps que si vous le faites. Si vous ne comptez que pour 50% lors de la planification du sprint (lors du comptage de toutes les heures / jours de développeur disponibles), vous devriez avoir beaucoup de temps pour vos tâches de PO.