Est-il acceptable d'avoir plus d'un rôle dans un processus SCRUM [fermé]

Question

Pensez-vous qu’une personne pourrait avoir plusieurs rôles dans une société de développement de logiciels souhaitant utiliser SCRUM?

E.g. est-ce ok / possible si une personne est

• maître et membre de l'équipe SCRUM
• Propriétaire du produit et membre de l'équipe
• maître SCRUM et propriétaire du produit

Quelles combinaisons pensez-vous possibles? Travaillez-vous dans une telle équipe? Que faut-il considérer si une personne a plus d'un rôle?

Merci pour vos remarques.

Answer 1

Merci pour toutes vos réponses. Je ne peux pas en choisir une comme réponse acceptée, car toutes sont utiles. J'accepte donc cette réponse pour supprimer le rappel de ma page de profil.

Answer 2

Tous nos Scrum Master sont des membres de l'équipe et je pense que cela fonctionne bien. Le processus gère très bien les différences de productivité.

Je pense vraiment que le propriétaire du produit doit être externe, mais je pense simplement que les équipes doivent avoir une certaine distance par rapport au propriétaire du produit.

Answer 3

Le propriétaire du produit ne doit pas être un développeur ou un rôle de gestion de projet. le but est d'avoir quelqu'un qui peut accepter un résultat et qui est l'expert en la matière. Si vous en faites un membre de l'équipe, vous êtes obligé de faire définir le produit par les développeurs du produit; C'est une mauvaise chose. Et si vous en faites le maître SCRUM, d’abord, ils n’ont probablement pas l’arrière-plan de développement requis par un maître SCRUM pour comprendre les problèmes et l’estimation, et ensuite, ils contrôlent les processus et produits exacts que le maître SCRUM devrait servir en tant que balance on.

Le maître SCRUM peut certainement assumer certaines tâches de membre d’équipe, en particulier dans une petite équipe. Cependant, dans la plupart des cas, lorsque l’effectif de l’équipe dépasse 3 ou 4, le maître SCRUM n'aura pas beaucoup de temps pour le travail de développement régulier.

[Mise à jour: " SCUM " maîtriser une faute de frappe très gênante.]

Answer 4

Recherchez dans les archives du liste scrumdiscussion. Cette question a été longuement discutée dans le passé.

Answer 5

Notre maître et propriétaire du produit SCRUM sont la même personne, mais il est unique et sait s’il porte son bonnet SCRUM (ou le bandeau Karate Kid dans ce cas). Il n’est pas le propriétaire du produit et vice-versa.

Oh oui, et je recommande vivement un bandeau Karate Kid pour le maître SCRUM.

Answer 6

Dans une "situation Scrum idéale" vous ne partageriez pas les rôles.

Maître Scrum et membre de l'équipe
Il peut arriver qu’il y ait conflit d’intérêts entre ceux-ci qui doivent s’acquitter de leur tâche et qui doivent éliminer un obstacle signalé par un membre de l’équipe. Dans chacun de leurs rôles, ils se sont «engagés» à achever leur rôle avant la fin du sprint - lequel devrait primer? Cependant, en réalité, il s’agit probablement de la paire de rôles la plus courante

Propriétaire du produit et membre de l'équipe
Vous ne devriez jamais avoir la même personne qui accepte le travail comme étant complet et fini et qui le fait réellement. Cela ne devrait se produire que dans une entreprise unipersonnelle, auquel cas vous pouvez remettre en question l’idée d’utiliser Scrum en premier lieu

Scrum master et propriétaire du produit
Encore une fois, je vois un conflit d’intérêts potentiel entre le maître Scrum qui souhaite terminer le sprint conformément aux engagements pris et les propriétaires de produits qui doivent accepter, à savoir que le sprint a été accepté.

Answer 7

Scrum a délibérément scindé les responsabilités traditionnelles en matière de gestion de projet pour se prémunir contre les pièges traditionnels de la gestion de projet, notamment la pression et la microgestion. Par définition, le Scrum Master n’a pas d’autorité et le Product Owner a autorité, donc si nous combinons ces deux personnes en une seule personne, nous devons simplement être honnêtes et appeler cette personne un chef de projet ordinaire (peut-être avec quelques compétences Agile).

Les autres combinaisons (PO est un membre de l’équipe, SM est un membre de l’équipe) présentent également des inconvénients, mais sont moins dommageables.