Comment un Scrum Master & # 8220; gère-t-il & # 8221; un propriétaire de produit hors de contrôle? [fermé]

Question

Je connais bien Scrum et bien que je comprenne le concept d’équipe derrière les Sprints, j’imagine qu’il doit toujours y avoir un gardien pour l’équipe qui minimise les interférences des propriétaires de produits qui ne sont pas au courant du développement logiciel. Quels sont vos succès et quelles histoires d'horreur avez-vous vécues?

Mise à jour:

Je recherche un équilibre entre le codage pour la mise en œuvre des processus métier et la création de l'architecture appropriée pour un client. Si le propriétaire du produit appartient à l'unité commerciale, vous devez indiquer combien de temps il faut consacrer au modèle de données, etc.

Définition:

Par "hors de contrôle" propriétaire de produit, je veux dire en général une personne de l’unité commerciale qui fixe de manière agressive des délais tout en n’ayant aucune réelle capacité technique à créer cette estimation. Généralement, cette personne dira: "J'ai besoin de ces écrans avant la prochaine réunion avec le Comité de fonctionnement la semaine prochaine. Vous devez donc hiérarchiser ces produits en priorité. Nous aborderons la base de données après avoir discuté avec les opérations. "

Excellent répond tout le monde. Merci pour la bonne contribution.

Answer 1

"Il doit exister des indications sur le temps qu'il faut consacrer au modèle de données, etc."

D'accord. C'est ce que la priorisation est tout au sujet. Vous définissez le travail, vous priorisez. Vous travaillez en fonction des priorités.

Qu'est-ce qui peut devenir incontrôlable?

1. Redéfinir le travail avant que quelque chose soit fait?

2. Redéfinir les priorités avant que le travail ne soit effectué?

La solution est la même. Divisez le travail en petits morceaux pour que quelque chose soit fait avant qu'il y ait une opportunité de faire un changement.

Si vous avez des sprints courts (2 semaines), il est impossible de perdre le contrôle. Si vous optez pour des sprints de 4 semaines un peu plus pratiques, vous aurez alors une petite chance d’avoir des ennuis.

Answer 2

Les responsabilités sont très clairement définies dans Scrum - le responsable produit définit les éléments de l’arrière-plan et les hiérarchise, les développeurs s’engagent sur les possibilités qu’ils peuvent accomplir dans un sprint.

Ainsi, un responsable de produit n'a tout simplement aucune autorité pour définir des estimations. Bien sûr, il peut toujours dire qu'il a besoin de quelque chose à un moment précis - cela se produit simplement. Mais ce sont toujours les développeurs qui diront si cela peut être fait . Et s’ils ne le peuvent pas, ils doivent réfléchir ensemble à la manière de modifier le champ d’application ou de faire ce qui est en leur pouvoir pour répondre au mieux aux besoins de l’OP.

Maintenant, comment le SM doit-il agir exactement dans une situation où cela ne fonctionne pas correctement dépend beaucoup de la situation spécifique. Je préférerais le voir faciliter une bonne relation et une bonne culture de communication entre le PO et l'équipe plutôt que de l'avoir protéger de l'équipe du PO, cependant.

Answer 3

Le propriétaire du produit est censé être celui qui vous protège des exigences ambiguës ou variables du client.

Le propriétaire du produit ne doit pas fournir d'estimation.

Answer 4

Je ne pense pas que ce soit une question de "perte de contrôle".

  

"J'ai besoin de ces écrans avant le prochain   réunion avec le comité d'exploitation   la semaine prochaine, donc prioriser ces travaux   produits d'abord. Nous allons aborder le   base de données après avoir parlé aux opérations. "

Il n’ya rien de mal en soi à cette déclaration en tant que telle . Si votre application est correctement extraite, votre base de données est quand même séparée. Le principal problème de l’interface utilisateur est d’abord plus psychologique: les non-développeurs présumeront que la plus grande partie du travail est accomplie s’ils voient des écrans et deviennent dingues lorsque les choses "ralentissent". Cependant, voici ce que je pense que votre vrai problème pourrait être:

La personne que vous avez désignée comme responsable de produit ne possède pas le produit et n'assume donc pas suffisamment de responsabilités.

Le produit est l'élément entier , pas seulement les "exigences fonctionnelles". (emprunter la terminologie). Votre SM doit s'asseoir et affirmer avec insistance que le PO ne doit pas chercher à comprendre l'ampleur du travail qui doit être accompli en coulisse. Une fois que vous êtes un bon de commande qui commence à examiner l'ensemble de la portée, il peut devenir votre représentant auprès de la communauté des parties prenantes au sens large.

En fin de compte, votre SM est le responsable du processus de mise en application. Ils devraient agir comme ça.

Answer 5

J'ai utilisé Agile dans deux magasins différents. Cela fonctionne bien à chaque fois. Je ne vois pas en quoi tout ce qui est hors de contrôle peut ruiner le système. Avant le sprint, vous planifiez toutes les tâches que vous ferez et vous estimez combien de temps elles prendront (toujours arrondies). Ensuite, vous pourrez déterminer approximativement combien de travail peut être effectué pendant votre sprint.

La plupart des magasins utilisent des sprints de 4 semaines et 6,5 heures de temps réalisable par jour. Lorsqu'un sprint est défini, vous n'introduisez pas de nouvelles tâches et seul le travail non planifié qui s'insinue dans un sprint consiste à corriger les bogues dans les fonctionnalités que vous ajoutez, bien sûr, qui sont supposés être inclus dans votre heure approximative.

Si vous souhaitez une réponse plus spécifique, vous devez définir ce que vous entendez par un "hors de contrôle". propriétaire du produit.

Answer 6

J'ai deux choses à dire.

Vous avez probablement un type de responsable R & D (ce n’est pas nécessairement Scrum Master) et n’est pas un produit propriétaire.

Ce gars peut et devrait (je pense) " protéger " développeurs. Nous étions dans une situation où nous avions un tel gars, et cela a très bien fonctionné. Il nous a notamment aidés à intégrer des tâches non fonctionnelles à l’arriéré.

Maintenant, nous n'avons pas ce gars. Notre manager est Scrum Master. Et il fait un très bon travail pour nous protéger également. Bien que ... le problème ici est que le maître de scrum générique n’a pas de pouvoir officiel, il ne peut donc pas dire "vous n’allez pas les appuyer autant", mais il peut bien sûr et doit parler s’il voit que ce groupe a besoin d’aide.

L’équipe elle-même et le propriétaire du produit évoluent également avec le temps, de sorte qu’ils commencent à se soucier davantage de l’autre. Le propriétaire du produit comprend que l’équipe ne s’engage tout simplement pas davantage ou dit "nous avons besoin de temps pour les éléments non fonctionnels maintenant".

Mais, encore une fois, c’est bien sûr s’il ya un gestionnaire de R & D distinct dont la responsabilité principale est de s’occuper des développeurs ... alors il sera plus équilibré, je pense.

Nous avons également un service de support qui emprunte des développeurs pour des tâches de support. Il est parfois difficile de se mettre d’accord sur ce qui va ou ne va pas être fait pour tel ou tel client (car le support le veut tout). Pour ce cas, le responsable R & D - une très bonne idée aussi.

Idéalement, j'aime bien l'idée d'être complètement maigre afin que les développeurs n'aient pas besoin de gestionnaire ni de bouclier ... mais je ne sais pas si et comment cela fonctionne ...:)

Answer 7

Je suis d'accord avec S. Lott. Les sprints courts sont meilleurs. De courtes histoires d'utilisateurs peuvent aider. Nous essayons de limiter nos user stories à 2 - 4 jours maximum.

1. Assurez-vous que tous vos utilisateurs les histoires sont bien définies et que le propriétaire en accord avec eux.

2. Une fois qu'un sprint a commencé, insistez     que de nouvelles tâches ne peuvent pas être ajoutées à     le sprint actuel, mais ils peuvent être     haute priorité dans le prochain sprint.     Les sprints plus courts en font beaucoup     plus facile.

3. En outre, afin de supprimer le     imposition de délais artificiels,     vous ne devriez vraiment pas livrer d'articles     à partir du sprint actuel jusqu'au     début du prochain sprint quand     possible.

La discipline est la partie la plus difficile du développement agile. Une fois que vous avez une équipe disciplinée et un scrum master, les utilisateurs s’y habituent et les choses bougent beaucoup. Je ne sais pas si vous utilisez un logiciel de gestion de projet, mais jetez un coup d'œil à Rally. Ils ont apporté des améliorations majeures au cours de la dernière année environ.

Answer 8

La portée de l'itération (Sprint dans Scrum) ne doit pas être modifiée pendant l'itération. C'est pourquoi une seule itération est prévue à la fois. Comme l'a souligné S. Lott, plus l'itération est courte, plus le responsable de produit sera en mesure de planifier de nouvelles tâches.

Le rôle du maître Scrum est d’isoler l’équipe de cette pression et doit dire au responsable du produit que les nouvelles demandes doivent attendre la prochaine itération.

Le rôle de responsable de produit consiste désormais à maximiser la valeur du travail produit par l'équipe. Par conséquent, s'il existe un nouvel élément prioritaire qui ne peut pas attendre la fin de l'itération en cours, il est toujours possible de le remplacer. avec une estimation similaire et non démarrés . Cela devrait être l'exception, pas la règle.

Answer 9

Respectez les règles d’engagement clairement définies pour permettre à votre partenaire de passer plus de temps à diriger votre équipe.

Answer 10

Une équipe agile est composée de développeur, d’analyste commercial, de testeur, de DBA, de maître Scrum et de propriétaire du produit. Tous travaillent en tant qu’équipe unique basée sur des fonctionnalités .

La méthodologie Agile est là pour aider les entreprises à accélérer le développement de produits plus rapidement. Le propriétaire du produit peut définir la priorité et en changer la priorité. En fait, c’est une équipe Scrum, qui l’estime notamment (PME, développeur, concepteur, testeur, etc.). Chaque membre de l’équipe apporte une perspective différente sur le produit et le travail requis pour livrer une histoire d’utilisateur et un sprint comprenant de gros et petite histoire d'utilisateur. Si l'équipe Scrum estime que cela ne peut pas être fait dans le sprint, il faut diviser la petite partie de la user story et obtenir une estimation en fonction de la trace de pile utilisée pour la développer.

i.e. Si Product Owner (PO) souhaite que la user story spécifique soit terminée en premier, mais si cette story inclut plusieurs modifications (par exemple, frontend et backend, base de données comprise) et qu'elle ne peut pas être complétée en un sprint, l'équipe Scrum peut suivre les règles suivantes:

Éléments clés :

• Diviser dans l'histoire de sous-utilisateur en fonction de la piste de pile
• Estimez chaque histoire d'utilisateur liée à cette
• Scrum master doit informer le propriétaire du produit de la chronologie  pour terminer cette histoire d'utilisateur en fonction de la vitesse actuelle de l'équipe
• Le propriétaire du produit doit être suffisamment mature pour comprendre la chronologie  ne peut pas être complété dans le sprint.

• Si Still a le problème en priorité, il / elle peut consulter le  Scrum Master / Coach.

  En bref, Agile sert davantage à aider les entreprises, mais vous devez vous assurer que ça ne surchargera pas Scrum Team. Comme il s’agit d’un processus régulier pour développement itératif.