Que pensez-vous de «Planning Poker»? [fermé]

Planification de poker

Résumé, au cas où vous ne voudriez pas lire l'article wiki:

1. Obtenez une liste des tâches que vous souhaitez effectuer pour la prochaine itération
2. Pour chaque tâche:
   2.1 Discutez avec le groupe de ce que cela implique
   2.2 Tout le monde écrit / sélectionne une estimation de l'effort requis pour la tâche
   2.3 Chacun révèle son estimation
   2.4 Les valeurs aberrantes les plus élevées et les plus basses expliquent leur raisonnement
   2.5 Répéter jusqu'à ce qu'un consensus soit atteint

Habituellement, quelque chose de similaire aux nombres de la séquence de Fibonacci comme 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 sont les valeurs autorisées, donc vous n'obtenez pas d'arguments longs sur des valeurs proches comme 23 vs 27.

De plus, les chiffres représentent une valeur d'effort sans unité, dont la valeur est déterminée par une tâche de base que tout le monde convient égale à environ un 1, et tout le reste est relatif à cela.

En fin de compte, l'objectif est d'avoir une bonne idée de la «vitesse» d'une équipe donnée, qui est le nombre de ces points qui peuvent être complétés dans une itération donnée. Avec cela, il est possible de faire des estimations raisonnablement précises du temps que prendra une fonctionnalité donnée.

Nous l'avons fait lors des réunions de planification des itérations dans une entreprise dans laquelle je travaillais, et je pensais que c'était l'une des rares bonnes choses à propos de cette entreprise en particulier. Alors, ce que je me demande, est-ce que quelqu'un a utilisé cela? Pensez-vous que c'est un outil utile pour l'estimation? Fonctionne-t-il dans toutes les situations ou se prête-t-il à certaines équipes, projets, etc.?

Nous l'utilisons dans notre entreprise pour le projet auquel je participe. Quelques notes sur la planification du poker sont exprimées dans mon récent article de blog , et voici une plus grande liste des raisons pour lesquelles c'est cool:

1. Cela met tout le monde d' accord . Les gens ne sont pas obligés d'accepter un résultat; au lieu de cela, ils sont obligés de faire leur propre estimation! Le temps de défendre leurs propres estimations est également alloué, si nécessaire.

2. Cela garde tout le monde occupé . Vous ne pouvez pas vous relâcher pendant la réunion, tout en essayant de montrer que vous êtes si impliqué. De plus, la nécessité de bouger les mains constitue un bon exercice physique pour vous empêcher de dormir.

   Cependant, un inconvénient est que, parfois, vous devez faire autre chose (par exemple, prendre quelques notes et noter les détails de l'accord que vous venez de conclure).

3. Il maintient les réunions plus rapidement . Il n'y a pas besoin d'une implication constante d'un responsable de réunion pour garder le rythme. Le jeu avec des règles claires est bien meilleur pour ça. Oui, vous devez faire quelques mouvements supplémentaires pour mettre des cartes, les révéler, etc., mais ceux-ci paient leur chemin.

4. Beaucoup de gens aiment jouer aux cartes , surtout au poker :-) Cela augmente la motivation.

Une entreprise qui vend des jeux de cartes de ce type a accompagné son site d'un article sur Planning Poker , qui vaut également la peine d'être lu.

Nous l'utilisons largement. Je trouve qu'il présente plusieurs avantages par rapport aux méthodes traditionnelles:

1. L'équipe s'approprie davantage les estimations
2. Souvent, les archétypes de programmeurs favorisent les introvertis - cette méthode les encourage à contribuer là où ils pourraient autrement s'en remettre à des personnalités plus extraverties.
3. Lorsqu'une caractéristique a une large distribution d'estimations, c'est un bon indicateur de risque
4. Juste en faisant l'estimation, vous en apprendrez plus sur les tâches
5. Rien de mieux que de mettre efficacement les gens dans une pièce pour communiquer efficacement

Je suis d'accord avec les points de Pavel. Il y a aussi une autre chose qui est précieuse. Il nivelle les règles du jeu pour la discussion. Souvent, les gens calmes sont noyés par des personnes plus verbales dans une discussion de groupe. Planifier le poker donne à chacun la possibilité de prendre sa décision avant le début de la discussion active. Et si c'est la personne calme qui donne l'avis "aberrant", ils ont toute la scène sur laquelle présenter leur cas. Par conséquent, la technique permet aux contributeurs les plus silencieux et assure la pleine participation de l'équipe.

Après avoir utilisé la planification du poker pendant quelques sprints, la direction a finalement réalisé ce que tous les développeurs nous savaient depuis des mois, nous ne finirons pas à temps.

La planification du poker, ou plus précisément, l'estimation basée sur un récit, est beaucoup plus précise que les pratiques d'estimation traditionnelles car elle combine un moyen facile d'estimer la complexité combinée de l'ensemble des fonctionnalités avec des mesures réelles de la capacité réelle des équipes.

Il y a déjà beaucoup de bonnes réponses ici - je voulais juste souligner une autre fonctionnalité.

Lorsque vous utilisez le poker de planification, vous obtenez une mesure instantanée de l'ampleur des désaccords sur la taille du travail. Si je pense que c'est un 2 et que vous pensez que c'est un 3, nous pouvons simplement l'appeler un 3 et passer à autre chose. Mais si je pense que c'est un 1 et que vous pensez que c'est un 5, nous ferions mieux de discuter.

Cela fait que tout le monde parle et réfléchit à ce qui se fait. Même si je ne vais pas y travailler, je dois faire attention à l'estimation. Cela m'aide lorsque dans 2 mois, je dois travailler sur quelque chose qui touche ce domaine.

Il est également facile à saisir. Montrez aux gens une structure de répartition du travail et leurs yeux brillent et ils commencent à baver dans leur sommeil. Montrez-leur une liste de tâches pour les 2-4 prochaines semaines et ils pourront le comprendre.

Une autre bonne chose: les discussions sur la question de savoir si la tâche X est un «3» ou un «8» aident l'équipe à déterminer exactement quelle est la portée - donc plus tard, il n'y a pas de divergence quant à la tâche X impliquée.

J'aime les points de Pavel et j'aimerais ajouter que cela aide vraiment les développeurs juniors ou les noobs à apprendre beaucoup plus rapidement. Ils ne peuvent pas simplement s'asseoir et laisser les développeurs seniors gouverner. Leur vote compte tout autant et s'ils se concentrent vraiment sur la précision de leurs estimations, ils apprendront beaucoup des développeurs seniors.

Je n'aime pas ça dans mon équipe actuelle, principalement parce que nous avons des gens qui fondamentalement n'y adhèrent pas. Nous passons une partie importante de toute session de toilettage à débattre de la pertinence du pointage, et notre propriétaire de produit ne décompose jamais les épopées, donc nous nous retrouvons généralement avec des estimations ou des histoires incroyablement décevantes où les points indiquent que la chose doit simplement être décomposée .

Rien de tel que d'avoir un 40 et deux 20 en un seul sprint!