Planning Poker and wordy developers [fermé]


10

Mon équipe est composée de 4 développeurs; tous chevronnés et qualifiés. L'un d'eux est un gars verbeux et bien intentionné qui insiste pour définir la solution technique à nos histoires avant de déposer nos estimations avec Planning Poker. Il refuse d'estimer s'il n'a pas une idée approximative de la solution technique convenue (ce qui semble raisonnable, non?).

Le problème est que nos séances d'estimation prennent une éternité pour se terminer !! D'après votre expérience, comment gérez-vous ce genre de personnalité lorsque vous jouez au poker de planification?

Réponses:


13

Il semble aimer que les choses soient définies de manière formelle, donc un chronomètre serait une bonne idée, car la planification du poker est définie comme ayant défini des délais pour que les gens puissent parler.

Il a également une mauvaise idée de l'estimation, tout le monde estime par rapport à l'histoire et non à la mise en œuvre , c'est pourquoi vous obtenez une telle variance. Par exemple, certaines personnes peuvent ignorer un cadre ou une solution standard et commencer à écrire des choses à partir de zéro.


1
Une minuterie est une excellente idée. Il rappelle aux orateurs d'être succincts et les oblige à distiller ce qu'ils essaient de dire au point très basique.
Shane Wealti du

Cela aide également si le travail préliminaire sur les histoires est mis en avant tôt, alors les préliminaires de conception technique peuvent être effectués "hors ligne" à partir de la réunion elle-même. Le poker n'est pas l'endroit idéal pour hacher des solutions, vous perdez le temps d'un département entier. Une autre idée consisterait à ajouter «concevoir ce genre de choses» comme une histoire qui déclenche une première boîte de temps de «mettre en œuvre ce genre de choses». Prochaine ronde, obtenez de réelles estimations pour la mise en œuvre.
Patrick Hughes

2
Non seulement une minuterie est une bonne idée, je pense qu'elle est recommandée (peut-être que quelqu'un avec Agile Planning and Estimation peut le confirmer). Ma compréhension est que, comme la plupart des activités, la planification des sessions de poker doit être temporelle pour éviter des situations comme ce à quoi la question fait référence.
Thomas Owens

1
For example some people may be ignorant of a framework or off the shelf solution and start writing things from scratch- D'où la discussion. Ensuite, tout le monde le sait et les estimations sont meilleures.
Izkata

3

Votre membre de l'équipe a une personnalité d'analyste. Les analystes ont besoin de beaucoup d'informations pour prendre une décision. L'idée de la minuterie est la meilleure, mais sachez qu'il va éviter l'enfer de tout ce qu'il donne. Travaillez avec lui pour lui expliquer qu'il ne s'agit que d'une estimation précoce basée sur le problème PAS sur la solution. S'il veut poser des questions, demandez-lui de s'en tenir au problème et non à la solution. Vous devrez peut-être le couper ou l'ennuyer pendant un certain temps lorsqu'il continuera à dériver vers des solutions.

Assurez-vous de tenir les autres membres de l'équipe à ces mêmes règles afin qu'il ne se sente pas isolé. Les analystes sont une personnalité courante dans la programmation, vous pouvez donc très bien en rencontrer d'autres comme lui.


2
+1, je suis une personnalité analyste et je lutte avec ce problème. Je remarque que je suis beaucoup plus approfondie et complète et que j'ai moins de bugs que mes pairs, mais je suis facilement stressé et inefficace dans des situations avec des informations moins que parfaites. Je m'efforce chaque jour d'essayer de gérer l'inconnu de manière moins stressante.
maple_shaft

2

Il semble que votre collègue ne comprenne pas la différence entre l'estimation et l'engagement ou qu'il ne lui ait pas été communiqué pendant la formation. Et, puisque vous avez essayé d'attacher le problème à sa personnalité, il est possible que toute votre équipe ne le comprenne pas encore. (Mais ne vous inquiétez pas! La plupart de notre industrie ne le comprend pas. Agile est difficile!)

Lorsque nous disons que la taille d'une histoire est de X points, nous entendons en fait une distribution de probabilité. Si nos estimations sont correctes, l'histoire devrait prendre plus de 50% du temps (et les 50% restants, cela prendra moins de temps). Si votre collègue estime que, lorsque X unités de temps se seront écoulées, il lui sera demandé de faire une démonstration de l'histoire ou bien, cela changera son approche de l'estimation.

La planification du poker introduit une autre erreur: au lieu d'essayer d'épingler X, nous l'associons à une échelle discrète, l'échelle de Fibonacci (1, 2, 3, 5, 8, etc.) étant la plus populaire. C'est dire que la taille n'est pas autant que ce qu'elle est. Quand nous disons que la taille de l'histoire est de 3 points, nous disons vraiment "c'est X plus-moins une certaine variance et X est plus proche de 3 que de 2 ou 5."

Votre équipe pourrait tirer profit de la compréhension de l'imprécision de cet exercice et de la différence entre l'estimation et l'engagement. Si vous voulez / devez étudier ces concepts en profondeur, ce livre a cela.


Lors de la planification, si vous pensez qu'une histoire prend 3 jours et une heure, vous devez utiliser les 5 jours, pas l'arrondir . C'est au développeur de garder sa discipline et de faire une estimation par rapport à la tâche, et non de faire en sorte que le plan de la tâche corresponde à l'estimation.
StuperUser

10
"On dirait que votre collègue ne comprend pas la différence entre estimation et engagement" Je peux parfaitement comprendre cela car de nombreux managers prendront TOUJOURS vos estimations initiales et les transformeront en engagements . Certains d'entre nous comme moi sont si nerveux à l'idée de donner une estimation approximative parce que les managers nous ont retenus et s'attendaient à ce que nous travaillions de longs week-ends sans sommeil pour le faire avant la date limite du sprint.
maple_shaft

1
@maple_shaft: vous avez absolument raison, l'estimation / l'engagement est l'une des plus grandes idées fausses de notre industrie et cette idée fausse est l'un de ses plus grands obstacles. Votre "nervosité", "longs week-ends", "pas de sommeil" etc. sont parmi ses conséquences. Vous ne pouvez résoudre ce problème que si vous incluez tout le monde, toute votre équipe, votre manager, etc. C'est pourquoi la transition agile est si difficile. Ramasser un jeu de cartes sans comprendre ces concepts est facile.
azheglov

1
@azheglov, la transition Agile est parfois difficile car la direction pense qu'elle veut Agile alors qu'en réalité ce sont des mégalomanes de micro-gestion avec un terrible complexe d'infériorité et un fort désir de ne JAMAIS ajuster les horaires de sprint lorsque les exigences changent ou que de nouvelles informations sont découvertes. En d'autres termes, ils ne veulent pas vraiment d'Agile parce que le vrai Agile est fondamentalement contradictoire avec tout ce qu'ils savent.
maple_shaft

@maple_shaft, vous avez également raison! Je n'entrerai pas dans toutes les raisons pour lesquelles l'agilité est difficile dans mon commentaire ;-)
azheglov

1

Je peux voir d'où vient votre membre de l'équipe, mais il n'a clairement pas complètement compris le concept d'Agile et Planning Poker. Vous devez commencer par vous assurer que tout le monde comprend les concepts et le raisonnement qui les sous-tendent, puis ils doivent faire les choses par eux-mêmes.


1

Pour les équipes avec lesquelles je travaille, au début de chaque session de planification, je mets une minuterie de sable de 3 minutes sur la table. Je fais savoir à toute l'équipe que si à un moment donné ils sentent que la conversation devient une plongée profonde, ou non pertinente, ou de toute autre manière va au-delà de ce qu'ils estiment nécessaire pour estimer l'histoire en points d'histoire, alors n'importe qui dans l'équipe peut retourner la minuterie. Une fois le sable épuisé, l'équipe estime immédiatement.

Cette méthode permet à chaque membre de l'équipe de limiter la conversation, lorsqu'ils estiment que la conversation n'est plus utile pour estimer l'histoire en cours de discussion. En même temps, cela n'interrompt pas immédiatement la conversation, mais donne à tout le monde une indication visuelle que leur conversation doit se terminer dans les prochaines minutes, car nous allons ensuite voter.

Un autre outil que j'utilise pour aider à garder les sessions de planification concentrées est de s'assurer que tout le monde dans l'équipe a examiné les histoires en haut de l'arriéré au moins quelques jours avant la planification. L'idée est que si vous avez une liste de questions immédiatement après avoir lu les histoires, vous pouvez informer le propriétaire du produit des questions potentielles plusieurs jours avant, afin qu'il puisse clarifier l'histoire ou la critique d'acceptation pour, espérons-le, limiter la discussion ultérieure. Cela permet également aux gens de commencer à réfléchir à la conception potentielle de l'histoire, avant d'être en planification (et d'essayer de concevoir pendant la planification).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.