Pratique N°2 : le planning game

Aïe Aïe Aïe, quelle pratique !

Arrivée tard chez nous, cette pratique n'a pas été comprise, ensuite mal utilisée. Le gros problème de notre projet c'est d'avoir commencé XP en mettant en œuvre les pratiques au compte-goutte.
Le planning game, enfin ce qu'on appelait un planning game au début, se résumait en une réunion entre le directeur informatique (MOA), le chef de projet (MOE) et l'architecte.
Bien évidemment les estimations étaient foireuses, du fait que les estimations étaient faites par un senior et réalisées parfois par des juniors, et toujours en binôme.

La notion de point est déjà une notion tellement incompréhensible la première fois qu'on se demande si ce n'est pas un cannular. L'effet ridicule passé, le noeud du problème émerge : un point = quoi? une heure pour un binome, une journée pour un binome. La réponse du coach n'est pas plus claire : c'est l'effort nécessaire à réaliser une tâche.
Effort (déf. Larousse) : Action énergétique du corps ou de l'esprit vers un objectif, un but.
Le souci a été de déterminer l'étalon, la tâche de référence.
Donc arbitrairement nous avons décidé de partir de 1/2 jusqu'à 8 en multipliant par 2. 1/2 - 1 - 2 - 4 - 8. Ceci nous a permis d'éliminer rapidement le 8 car chaque tâche estimée à 8 points débordait sans exception. Autre souci dans notre pondération, avec l'équipe notre vitesse était de 12 pt/itération. Donc impossible d'avoir un suivi fin et quotidien sur 12 points - 3 binômes et 10 jours de DEV. Sachant qu'il y avait au moins une tâche à 4 points dans chaque itération. Dessiner un burndownchart se serait révélé inutile.
Revenons au planning game, nous réunissons toute l'équipe, la notion de point assimilée (ou presque), les analystes expliquent une tâche ensuite, à main levée, estimation, débat, consensus : voilà on a estimé.
Que faire maintenant de ces points ? L'humain est accroché au temps, donc je m'attends à ce que l'équipe clôture 12/10 de point tous les jours. Oui mais ça c'est beau en théorie, mais en pratique c'est autre chose.
Avec des points qui sont purement imaginaires et du temps qui ne l'est pas, quand puis-je me rendre compte que je suis en retard ?

Bon changeons le format du planning game, je reviens des XP days Paris 2008, génial, ils ont édité des jeux de cartes 'spécial planning game'. Nous avions remarqué que l'équipe s'inspirait du premier qui estimait et donc les estimations s'harmonisaient pour autant que la personne n'ai pas envie de justifier pourquoi elle estimerait son temps double des autres. "Moi j'estime comme les autres comme ça on ne me pose pas de question". Donc Poker planning game, génial l'effet débat est lancé, la première carte en l'air et personne n'est d'accord et l'éternel question : "c'est quoi un point ?". Passons, le débat technico-fonctionnel est bcp plus intéressant, si poker PG n'a pas franchement permis de solutionner le problème des estimations, il éveille enfin des discussions intéressantes et donc les estimations sont un poil plus justes. Cela se traduit par moins de débordement.
Mais voilà, un truc qu'on pense bien rôdé ne marche toujours pas, les estimations ne sont pas correctes, encore des dépassements, on retire des tâches, on fini à l'arrache,...
Que se passe-t-il ? Lors du PG suivant, je pose la question et là la réponse vient des plus "forts" de l'équipe, on estime sur base de l'équipe et pas sur base de ce que je ferais moi. Donc on se retrouve avec beaucoup de tâches surestimées, et donc les tâches qu'on fini à l'arrache sont les tâches qu'on ajoute en cours d'itération qui déstabilisent tout (Ne pas inclure de tâche non planifiée).

Que fait-on ? Bon Deux choses, on a remarqué en parallèle que quand l'équipe bosse sur un "projet", elle est plus efficace. Alors modelons les itérations comme des projets, un but commun et non pas 10 tâches qui n'ont parfois aucun lien entre elles.
De plus il est important de recadrer le contexte dans lequel s'inscrit la tâche. N'oublions pas que nous créons une appli pour des utilisateurs qui ont un savoir-faire dans leur métier, et il est important de comprendre le métier pour le traduire dans le code, et en même temps ne pas se perdre en chemin, cela fait déjà 2 ans que le projet a démarré. Et donc petit effort pour les analystes ..payant.
Le fait de négocier avec le client non pas de micro-tâches que personnes ne remarque mais bien de blocs/modules fonctionnels augmente la valeur du produit et l'adhésion de l'équipe.

Néanmoins, le "POINT" est toujours incompris.
Début 2009, je reviens de ma formation "scrum master", génial, en passant cela ouvre les yeux sur beaucoup de choses. Cela reseemble furieusement à une uusine à fric, mais quand on sort de là, on a plus qu'un titre, on acquiert un savoir qu'il faut pratiquer. Scrum master certifié signifie qu'une personne a suivi une formation certifié scrum master et rien d'autre.
Lors de cette formation j'ai appris une nouvelle méthode d'estimation, toujours à exploiter par l'équipe pendant le planning game : le mur.

Alors simple : vous collez sur un mur des post-it représentant votre échelle de pondération en colonne, vous exposez le contenu de votre itération également sur post-it. Chaque membre de votre équipe prend 1 à plusieurs de ces post-it et le colle dans la colonne de son choix. Lorsque toute l'équipe a collé tous les post-it, il suffit de lancer le débat et repasser chaque post-it en s'assurant que personne ne s'oppose farouchement à la pondération choisie.
Donc nous avons un planning game plus court et chaque tâche est choisie et pondérée par une personne, mais validée par l'équipe.

En mettant en pratique cela nous avons modifié notre échelle et afin de couper court au débat sur les points, nous avons définit que 1 point = 1 heure/binôme. Nous avons fait cela pendant 2 planning game et ensuite nous n'avons plus pronnoncé le mot "Heure", mais "Point". A l'heure actuelle nous comptons +- 120 pts/itération. Ce qui nous permet de suivre un graphique d'avancement(burndownchart) tous les jours.

Autre chose, c'est à ce moment là que nous avons défini notre mot : "Terminé".
Il est important que l'équipe se définisse un contrat sur chaque tâche, quand est-ce-que je peux dire que ma tâche est terminée ?

• Quand mes tests passent
• J'ai fait mon refactoring ?
• ...

Les effets : pondérations beaucoup plus justes, boost de l'équipe et adhésion des membres de l'équipe au système de planning game.

Résumons :

• focaliser son équipe sur un objectif commun et éviter un panier(backlog) rempli de petites tâches disparates


• Adopter une technique d'estimation adaptée à votre équipe : main levée, concertation, poker, mur,... Il en existe une multitude et le choix doit être concerté et testé


• Choisir également une échelle de point assez grande afin de pouvoir suivre l'évolution quotidienne de l'équipe