par James Grenning

1. – traduit par Fabrice Aimetti le 1er
octobre 2009 –
Planning Poker
ou
Comment éviter la paralysie
lors de la planification de version
par James Grenning
Le client raconte une story à l'équipe. Deux personnes discutent des impacts de la story sur le
système. À contrecœur, une estimation est jetée sur la table. Ils s'absentent. Dans la salle, tout le
monde est à la dérive et aucune personne ne se sent particulièrement engagée. Le débat oscille entre
une solution potentielle et une autre, en évitant soigneusement d'annoncer un chiffre. Lorsque la
discussion se termine enfin, vous découvrez que l'estimation n'a pas vraiment évoluée. Vous venez
de perdre 20 minutes de temps précieux. Vous avez 25 autres histoires à estimer et vous ne
souhaitez pas faire carrière dans la planification de release.
L'extreme programming met en oeuvre deux niveaux de planification : la planification de l'itération
et la planification de la version. La planification de l'itération est à court terme et très détaillée. La
planification de l'itération est un bon moyen d'entrer dans les détails d'implémentation d'une story.
La planification de la release est d'un niveau plus macro avec une vision à plus long terme du projet.
Au cours de planification de la release, l'équipe a une vision moins précise et plus long terme du
projet. Le backlog de stories est très grand. L'objectif du planning de release est d'obtenir une
estimation approximative de l'effort pour créer le produit, et de fractionner le produit en versions
successives et à forte valeur ajoutée. La précision des estimations individuelles n'est pas le but. Il
s'agit ici de déterminer le périmètre du projet.
Les estimations de stories ne signifient pas plus que leur nom. Ce sont des estimations. Certaines
estimations sont sur-estimées. Certaines sont sous-estimées. De temps en temps, les estimations se
révèlent être justes. L'équipe estiment des stories, y compris celles qui ne seront peut être jamais
implémentées. Il est donc normal d'être moins précis. Pourquoi investir dans la précision avant que
cela ne soit nécessaire? Un ensemble d'estimations relativement précises vaut toujours mieux que
deux estimations très précises (qui ne sont probablement pas si précises que ça de toute façon).
L'équipe doit essayer de développer son intuition. Ne soyez pas puriste au sujet des estimations,
privilégiez la vitesse d'estimation pour que l'équipe termine la séance et retourne sur la réalisation
du produit.
Il y avait deux problèmes identifiés dans le paragraphe d'introduction : les estimations prenaient
trop de temps et toute l'équipe n'était pas impliquée. Il n'y a rien de tel qu'un petit jeu de planning
poker pour résoudre ces deux problèmes. La mécanique du planning poker est simple. Le client
raconte une story. S'ensuit une discussion permettant de clarifier la story si nécessaire. Chaque
programmeur note son estimation sur une carte, ceci sans en discuter avec son voisin. Une fois que
tous les développeurs ont noté leur estimation, retournez toutes les cartes. Si tout le monde est
d'accord, c'est parfait, aucune discussion n'est nécessaire, enregistrez l'estimation et passez à la story
suivante.
En cas de désaccord dans les estimations, l'équipe peut alors discuter des différentes estimations et
Planning Poker
Copyright © April 2002 All Rights Reserved
1 James W. Grenning
james@grenning.net

2. – traduit par Fabrice Aimetti le 1er
octobre 2009 –
essayer d'arriver à un consensus. Si vous n'y arrivez pas, ne vous inquiétez pas. C'est seulement une
story parmi d'autres. Reportez la story, découpez-la ou prenez l'estimation la plus basse.
Essayons de jouer avec une story qui ne prête pas à consensus. Le client traite la story. Les
développeurs réfléchissent à leur estimation. Tous ensemble, ils retournent leurs cartes. Cela
ressemble à ceci :
Les développeurs qui ont des estimations aux extrêmes démarrent la discussion (ici 1 et 5). Cela
peut donner quelque chose comme ça :
> "Pourquoi penses-tu que cette story est si difficile ?"
> "Pourquoi penses-tu que cette story est si facile ? Penses-tu que tu devras modifier le
protocole de communication ? La dernière fois que nous l'avons fait, cela nous a coûté
seulement quatre jours !"
> "C'est fondamentalement la même chose que la dernière fois lorsque nous avons changé le
protocole et tout ce que nous avons eu à faire c'est d'ajouter une autre classe de message"
> "OK, mais ici, ce n'est pas exactement ce cas"
> blah ... blah ... blah
> "Partons sur 3 alors"
> "D'accord, on a fini"
Vous souvenez-vous de l'autre problème mentionné dans le paragraphe d'introduction ? Tout ceux
qui étaient présents ne participaient pas. Maintenant, tous les participants sont des joueurs. A
présent, plus personne ne peut se cacher en jouant aux cartes. De plus, chacun prend de l'expérience
en pratiquant les estimations. Toute l'équipe joue le jeu, pas seulement les plus virulents ou les plus
anciens. Tout le monde participe.
Jouez à ce jeu, vous verrez que cela ressemble vraiment à une main au poker. Quand la story est
lue, l'estimation est pondérée, les côtes calculées, les autres joueurs observés, et une carte est
choisie par le joueur et jouée face cachée. Ensuite, tous les joueurs retournent leurs cartes
Planning Poker
Copyright © April 2002 All Rights Reserved
2 James W. Grenning
james@grenning.net

3. – traduit par Fabrice Aimetti le 1er
octobre 2009 –
simultanément.
L'une des points d'attention à porter avec le planning poker est de ne surtout pas éviter les
discussions importantes. Les estimations pourraient devenir inutiles sans ces discussions. Lorsque
j'ai utilisé cette technique, j'ai remarqué que l'équipe est rapide pour estimer les stories qui lui
semblent familières : des stories qui sont naturellement construites sur la base d'autres stories déjà
connues. Les choses ont tendance à ralentir lorsque le client traite des stories concernant des
nouvelles parties de l'application. Les discussions doivent être déclenchées dès que c'est nécessaire.
Lorsque le client traite une story qui n'est pas comprise, prenez le temps de bien la comprendre.
Cette idée de parvenir à un consensus sans débat semble bizarre, mais cela fonctionne. On peut
l'utiliser dans des domaines autres que la planification. Ceux qui sont les moins susceptibles de
participer auront leur mot à dire dans le planning. Les gens silencieux peuvent avoir de très bonnes
idées. L'équipe peut enfin concentrer son énergie sur les différences d'avis et ne pas gaspiller un
temps précieux sur des choses sur lesquelles ils sont déjà d'accord. J'ai constaté que cela avait un
impact positif sur la vélocité d'estimation de l'équipe. Au lieu de passer 10, 20 ou 30 minutes sur
chaque story, la plupart des stories sont estimées en une minute ou deux.
Remerciements
Je remercie Symantec Corp. d'avoir expérimenté cette technique. Je remercie Lowell Lindstrom
pour m'avoir inspiré et Brian Bouton pour avoir identifié des pièges potentiels.
A propos du jeu de cartes
Un paquet de cartes est joint à cet article. Imprimez-le sur du papier cartonné 3×5. Un paquet pour
chaque joueur. Vous verrez certains trous dans les chiffres. Le jeu est conçu pour obtenir des
nombres sans unité ou des jours de développement "idéaux". Plus les estimations prennent de
temps, plus la précision diminue. Il existe des cartes pour 1, 2, 3, 5, 7, 10 jours et l'infini. Ce paquet
de cartes peut vous aider à garder l'estimation de votre story sous 2 semaines. D'expérience, les
stories estimées à plus de 2 semaines dépassent le budget initial. Si une story est estimée à plus de 2
semaines, jouez la carte infini et demandez au client de découper la story. Si vous vous sentez
vraiment obligé de jouer un 4, 6, 8 ou 9, allez de l'avant et jouez deux cartes à la fois. Je parie que la
précision obtenue ne sera pas d'une grande aide.
Planning Poker
Copyright © April 2002 All Rights Reserved
3 James W. Grenning
james@grenning.net