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

Pratique N°1 : Client sur site

Et bien nous sommes vernis, le client a demandé XP dans le "contrat" et connaissait déjà en partie les pratiques XP.
Le fait d'avoir le client sur site lui semblait une évidence autant que le choix de l' eXtreme Programming.
La société (client) est née à la suite d'une scission d'une plus grosse société, et donc la connaissance métier s'est partagée entre les deux nouvelles entités. Le choix d'une méthode agile, itérative a donc émergé. Il était difficile voire impossible pour la direction de l'époque de condenser dans un "cahier des charges" ce qu'elle attendait d'un développement aussi gros.

Difficulté à noter toutefois, le projet a commencé en fin 2005 avec une direction (Mr X), la direction a changé (Mr A). Mr A débarque et voit un projet qui dure depuis déjà 2 ans et ne voit pas où il s'arrêtera. La demande d'avoir un périmètre clair et identifié nous a été faite, le périmètre nous a été fournis sous la forme de procédure QUALIGRAM. Nous devons estimer la "charge" de ce périmètre. Nous avons utilisé COCOMOII (cocomo 2).
La fin du projet est prévue pour mi-2011. Donc nous sommes face à un projet agile complet (pas un ensemble de petits projets) de +- 6 ans?.

Revenons au client sur site :

les +

+ réponses rapides dans les 2 sens, nous vers le client et le client vers nous
+ transparence relative sur notre boulot
+ empreinte de l'ambiance qui reigne chez le client, sur un projet longue durée cela est assez important
+ impression de faire partie de la société cliente (impression partagée)
+ le client se familiarise avec notre façon de travailler
+ la proximité amène des questionnements plus profonds chez le client sur sa manière de travailler (le développement informatique participatif ou agile a souvent cet effet)

les -

- les crises internes de l'équipe de DEV sont directement perceptibles par le client
- l'équipe ne se sent pas toujours chez elle (à contrario du + faire partie du client), il existe toutefois bien une frontière, l'équipe ne peut pas toujours se "lâcher"
- l'équipe est parfois victime des petites vendetta côté client par la "priorisation" de tâches importantes

Conclusion : malgrès quelques points négatifs, qui sont là pour nous rappeler que l'agilité est une aventure humaine avant tout, le client sur site est plus que bénéfique pour un projet informatique. Il amène énormément de réflexions chez le client, une connaissance fine du métier client de la part de l'équipe, il nous arrive de participer à des réunions importantes et apporter un point de vue différent. Cela se traduit par une application très proche des désirs utilisateur/client.

Géographiquement, nos bureaux de développement sont dans les bâtiments du client.

Dans ce contexte de méconnaissance métier, sans être négatif, ou je dirais plutôt en période d'apprentissage de la part du client, nous avons créé des rôles qui ne sont pas tout à fait XP.

Il y a un chef de projet, désir du client et en même temps pratique automatique de la part de Thales.
Il y a 2 analystes dont le rôle et d'être le responsable client (product owner) et en même temps analyste fonctionnel, donc le principe est de dire quoi et plus ou moins comment le client veut ses fonctionnalités. Et le fait d'avoir le client à porter de main nous évite la dérive d'avoir des analystes dictateurs, mais bien messagers/décodeurs des exigences du client final.
Il y a également un architecte, qui est notre référence technique qui a comme rôle de penser à la structure de l'application, d'être en avance sur les technos qui vont être utilisées dans l'application et de ce fait, il nous a permis d'avoir dans la même équipe des profils senior et junior qui cohabitent dans un cadre XP. Nous étudierons ce sujet lorsque nous aborderons le binômage.

Voici une cartographie globale des interactions entre notre équipe et le client :


Quelles sont elles ?

Le comité de pilotage

Il réuni notre chef de projet, la direction générale du client, notre commercial. Il sert à passer en revue les différents indicateurs du projet (Bugs, Fonctionnalités,...), mais il sert surtout à donner les grandes priorités du client. Il se déroule toutes les 6 semaines, et donc il y a à chaque fois une livraison en production entre chaque comité de pilotage.

Les réunions fonctionnelles

Ces réunions rassemble les analystes, les décideurs fonctionnels et parfois les utilisateurs du système. Elles sont programmées toutes les deux semaines, donc à chaque itération. Cette réunion permet de définir les priorités de chaque service et donc les directeurs assistent également au comité de pilotage, et donc il sont conscient des priorités issues du comité de pilotage, ils doivent donc intercaler leur demande sans bousculer l'agenda du projet comité de pilotage. A la fin de la réunion nous obtenons le backlog des prochaines itérations.

Le planning game

Cette réunion nous permet d'estimer le backlog des réunions fonctionnelles. Cette réunion rassemble le chef de projet, les analystes, les développeurs client et fournisseur et un (des) représentant(s) du client afin d'apporter quelques précisions au besoin sur les spécifications des analystes. Le représentant du client est à 90 % assuré par les analystes. Et donc utilité de la réunion fonctionnelle préalable.

Stand-up

Réunion matinale qui permet à tout le monde de dire ce qu'il a clôturé la veille, ce qu'il va faire aujourd'hui et ce qui l'a bloqué ou le bloque encore.
Cette réunion rassemble toute l'équipe de DEV et parfois le client et donc comme souvent les analystes font office de représentant du client.

Binômage

Petit mot sur le binômage, dans ce contexte, il est un outil de communication entre les équipes (fournisseur/client). L'équipe du client doit également maintenir l'ancien système informatique. Les développeurs client ne sont donc pas disponible à plein temps. Le binômage leur permet donc de reprendre vite du service et se tenir à jour sur le code après une période d'inactivité sur le projet. Dernièrement un système alternatif a été mis en place, ils sont deux et donc une semaine sur deux il y en a un à temps plein dans le développement de l'application.