Planning Poker – 2ème épisodes
2008
Lors de mon dernier billet sur le planning poker, je vous avez indiqué que je détaillerais la méthode (carte et attribution des points) pour bien mettre en œuvre cette technique. Me voila de nouveau pour clore ma présentation sur le planning poker.
Le Planning poker combine des opinions d’experts, des analogies et des échanges dans une ambiance agréable et ludique, qui permettent d’obtenir des estimations rapides avec des résultats fiables.
Les participants au planning poker inclus tous les développeurs de l’équipe. Rappelez-vous que le terme développeurs en méthode agile se réfère à tous les programmeurs, testeurs, ingénieur système, ingénieurs base de données, les architectes, concepteurs de l’interaction avec l’utilisateur, et ainsi de suite.
Sur un projet agile, qui ne dépasse pas généralement plus dix personnes. Si c’est le cas, il est généralement préférable de se séparer en deux équipes. Chaque équipe pourra alors faire une estimation de manière indépendante. Le directeur de produit participe à la planification, mais il ne fait d’estimation.
Au début de la planification, chaque participant reçoit un jeu de cartes. Chaque jeu de cartes distribué doit permettre de réaliser une estimation fiable. Chaque participant peut, par exemple, recevoir un jeu de cartes qui va de 0, 1, 2, 3, 5, 8, 13, 20, 40 à 100. Les cartes doivent être prêtes avant la réunion de planification et les nombres doivent être assez grands pour être vu de l’autre côté de la table.
Pour chaque cas d’utilisation ou fonction à estimer, un animateur lit le descriptif. Le modérateur est généralement le directeur de produit ou un architecte. Toutefois, le modérateur peut être n’importe qui, car il n’existe pas de privilège associé avec le rôle. Le directeur de produit répond à toutes les questions des participants. Néanmoins, tout le monde doit savoir qu’à un certain moment les discussions complémentaires ne conduisent pas à améliorer la précision. L’objectif avec le planning poker est de ne pas procéder à une estimation qui supportera toutes les futures fonctionnalités. Au contraire, l’objectif est de qualifier la première vue pour arriver sur la fin à une estimation fiable, d’où une première estimation peut être considérée à « bon marché ».
Après que toutes les questions ont trouvé des réponses (enfin, on essaye), chaque participant choisit une carte représentant son estimation. Les cartes sont montrées une fois que chaque participant a fait son choix. À ce moment-là, toutes les cartes sont retournées en même temps de manière à ce que tous les participants puissent voir chaque estimation individuelle.
Il est très probable à ce stade que les estimations diffèrent sensiblement. Il s’agit en fait d’une bonne nouvelle. Si les estimations diffèrent, les participants avec des valeurs hautes et des valeurs basses doivent expliquer la raison de leurs estimations. Il est important que cela ne fonctionne pas comme un reproche à l’intention des participants. Mais un échange sur des visions différentes.
A titre d’exemple, un participant avec une estimation haute peut dire: Eh bien, pour tester ce cas d’utilisation, nous devons créer une base de données avec des objets fictifs. Cela pourrait nous prendre un jour. Je pense aussi que l’algorithme de compression n’est pas bon, ce qui impliquerait d’en développer un nouveau plus efficace
. Le participant qui a fait une faible estimation peut répondre : Je pensais que nous allions stocker les informations dans un fichier XML – ce qui serait plus facile qu’une base de données.
Le groupe peut discuter de nouveau sur le cas d’utilisation et de leurs estimations respectives quelques minutes de plus. Le modérateur peut prendre des notes qu’il pense utiles pour le développement et le test de ce cas d’utilisation. Après la discussion, chaque participant fait une nouvelle estimation en sélectionnant une carte. Les cartes sont une fois de plus gardées secrètes jusqu’à ce que tout le monde ait réalisé son estimation au cours de laquelle elles seront affichées en même temps.
Dans de nombreux cas, les estimations convergent déjà au second tour. Mais si cela n’est pas le cas, il faut continuer à répéter le processus. L’objectif pour les participants est de converger vers une seule estimation qui peut être utilisée pour le cas d’utilisation. Cela prend rarement plus de trois tours de scrutin, mais le processus doit continuer jusqu’à ce que les estimations convergent. Il n’est pas nécessaire que tout le monde dans la pièce retourne une carte avec exactement la même estimation. Si je suis un modérateur et sur le deuxième tour quatre participants proposent, 5, 5, 5 et 3, je vais demander au participant qui a fait la plus faible estimation, si il est OK si on décide d’une estimation à 5. Encore une fois, l’estimation ne nécessite pas une précision absolue, mais raisonnable.
Le droit à la discussion
Certaines discussions sur la conception préliminaire du cas d’utilisation sont nécessaires et appropriées, lors de l’estimation. Toutefois, dépenser trop de temps sur des discussions à propos de la conception est souvent un gaspillage d’efforts et de temps. Voici un moyen efficace d’encourager certains débats, mais assurez-vous qu’il ne va pas trop durer.
Acheter un sablier, et placez-le au milieu de la table de poker où la planification est en cours. Toute personne assistant à la réunion doit pouvoir voir le compte à rebours à tout moment. Lorsque le sablier est épuisé (environ deux minutes), la prochaine série de cartes est jouée. Si un accord n’est pas atteint, la discussion peut se poursuivre. Mais quelqu’un doit tourner immédiatement le sablier pour limiter la discussion à deux minutes. Le sablier n’a rarement besoin d’être utilisé plus de deux fois. Avec cette méthode, les équipes apprennent à estimer plus rapidement.
Les petites sessions
Il est possible de jouer au poker avec un sous-ensemble de l’équipe, plutôt que de tout le monde. Ce n’est pas idéal, mais cela est parfois une option raisonnable, surtout si l’équipe est nombreuse, s’il y a beaucoup de cas à estimer, comme cela peut se produire au début d’un nouveau projet.
La meilleure façon d’y parvenir est de scinder la plus grande équipe en deux ou trois petites équipes, dont chacun doit disposer d’au moins trois participants. Il est important que chacune des équipes de participant estime successivement.
Pour ce faire, commencer avec toutes les équipes ensemble dans une session de planification conjointe d’une durée d’une heure environ. Demandez-leur une estimation pour 10 à 20 cas d’utilisation. Ensuite, assurez-vous que chaque équipe a une copie des cas d’utilisation et leurs estimations et qu’ils les utilisent comme base pour estimer les cas d’utilisations qu’ils leur sont donnés à estimer.
Quand jouer au planning poker
Les équipes devront jouer au planning poker à deux moments différents. Tout d’abord, il sera généralement nécessaire de faire des estimations sur un grand nombre de cas d’utilisation avant que le projet ne commence officiellement ou au cours de sa première itération. Estimer une première série de cas d’utilisation avec l’équipe sous la forme de deux ou trois réunions allant d’une à trois heures chacune. Naturellement, cela dépendra du nombre de cas d’utilisation à estimer et de la taille de l’équipe, et si le directeur de produit a les capacités de préciser les exigences de manière succincte.
Deuxièmement, les équipes devront faire de nouveaux efforts à chaque nouvelle estimation de cas d’utilisation qui sont identifiés au cours d’une itération. Une façon d’y parvenir est de planifier une estimation sous la forme de réunion très courte vers la fin de chaque itération. Normalement, cela est tout à fait suffisant pour estimer les travaux qui sont à réaliser au cours de l’itération, et permet d’obtenir les priorités à appliquer à l’itération en cours.
Sinon, Kent Beck propose une enveloppe accrochée sur le mur avec tous les nouveaux cas d’utilisation positionnés dans l’enveloppe. L’équipe va récupérer un ou deux cas d’utilisation dans l’enveloppe et les estimer. Les équipes doivent établir une règle pour eux-mêmes, généralement que tous les cas d’utilisation doivent être estimés d’ici la fin de la journée ou à la fin de l’itération. J’aime bien l’idée d’accrocher une enveloppe sur le mur qui contient les cas d’utilisation non estimés. Toutefois, je préfère lorsque quelqu’un qui a un peu de temps consacre quelques minutes à faire une estimation, il trouve au moins une autre personne et ils font une estimation conjointe.
Pourquoi le planning poker fonctionne
Maintenant que je viens de décrire la mise en oeuvre du planning poker, je vous propose de passer un petit moment sur les raisons pour lesquelles il fonctionne si bien.
Tout d’abord, le planning poker rassemble de multiples expertises pour réaliser les estimations. Parce que ces experts forment une équipe pluridisciplinaire sur un projet de développement applicatif, ils sont le plus à même pour estimer une tâche que d’autres personnes. Après avoir réalisé un examen approfondi de la littérature sur les estimations des charges en développement, Jørgensen (2004) a conclu que les personnes les plus compétentes pour résoudre la tâche doivent l’évaluer
.
Deuxièmement, un dialogue animé s’ensuit au cours de la planification, et les planificateurs sont appelés par leurs pairs pour justifier leurs estimations. Cela a été proposé pour améliorer la précision de l’estimation, en particulier sur les cas d’utilisation avec de grandes quantités d’incertitude (Hagafors et Brehmer 1983). Être invité à justifier les estimations a démontré que cela se traduit par une meilleure estimation pour compenser les informations manquantes (Brenner et coll. 1996). C’est d’autant plus important sur un projet agile parce que les cas d’utilisations sont souvent intentionnellement vagues.
Troisièmement, des études ont montré que la moyenne des estimations individuelles conduit à de meilleurs résultats (HOEST et Wohlin 1998) de même que des discussions de groupe de planificateurs (Jørgensen et Moløkken 2002). Le groupe de discussion est la base du planning de poker, et ces discussions aboutissent à une sorte de moyenne des estimations individuelles.
Finalement, le planning poker fonctionne parce que c’est amusant !

janvier 18th, 2009 at 0:16
Bonsoir, je termine un livre (de plus) sur Agile. En ce qui concerne le planning poker, plutôt que de réinventer la roue, perdre du temps à formuler, ou traduire, je souhaite utiliser votre post envouscitant et référençant votre blog bien sur.
Pouvez-vous me donner votre OK ?
Merci