Agile Tour : Planification agile par la pratique
Un article de ODcWiki.
 Auteur : jamory.
|
Voici un retour d’expérience réalisée lors d’un atelier durant l’agile tour Paris 2009 : “Planification agile par la pratique : Kanban, Burndown, Burnup (1h30)”.
Le but était de manipuler les outils d’un projet agile par la réalisation d’un projet fictif itératif et incrémental avec la mise en place d’un radiateur d’informations, (post’it ou kanban (petite fiche cartonnée), BurnDown et BurnUp charts) en appliquant certains des quelques principes agiles (Prioriser / Planifier / Estimer les délais / Collaborer / Visualiser / Auto organiser).
Le projet se présentait sous la forme d’un ensemble de tâches. Ces tâches étaient exprimées sous la forme de contrats de réussite de tirages de dés. Une valeur client était indiquée sur chaque tâche. Le travail de découpage et de valorisation du client, quant à lui, était déjà établi.
Les chiffres importants :
- Un jour de l’itération = le tirage d’un dé.
- Une itération = 15 jours ouvrés (3 semaines).
- Une vélocité encore inconnue à ce stade.
- 6000 points de valeur client, répartis sur des fiches valant 130 à 500 points.
Sommaire |
Première étape - Chiffrage / Priorisation:
Nous devons évaluer chaque tâche en ‘points’ pour remplir l’objectif indiqué sur celle-ci. Ces points représentent un premier niveau d’abstraction destiné à évaluer la complexité de chaque kanban. On évalue ces tâches à accomplir en les rassemblant par niveau de difficulté similaire (ici c’est les probabilités qui nous guident). On remarque que certains kanbans sont proches en terme de probabilités.
L’équipe décide –dû au fait que certains n’étaient pas novices dans une telle pratique- de chiffrer les tâches par niveau de complexité en suivant la suite de Fibonacci.
Nous totalisons le nombre de points tâches à réaliser ainsi que la valeur client de l’ensemble des fiches (ici 75 points tâche pour 6000 points de valeur client) afin les de répartir sur les 9 itérations prévues par l’organisateur. On note que les kanbans sont remarquables en terme de coût de réalisation / valeur client. La majorité d’entre eux sont de complexité faible, valorisée 1, 2 ou 3 points tâche.
Il se profile que des tâches sont plus prioritaires que d’autres. Ces tâches s’associent naturellement et définissent le contenu des premières itérations.
Deuxième étape - Planification / estimation des délais :
Nous venions de planifier à ce stade nos 9 itérations, soit une vélocité estimée d’environ 8 points tâche et par itération ce qui correspondrait à ce niveau de planification environ 2 lancers de dés par point tâche.
Troisième étape - Déroulement de l’itération / estimation :
La question des dés n’avait pas été évoquée jusque là…
Nous découvrons ceux-ci : deux dés à 6 faces et un dé à 10 faces. Le dernier dé est tiré au sort : nous devons réaliser les itérations avec un quatrième à... 20 faces ! Surprise donc : un dé n’est pas toujours à 6 faces…
Itération 1 : Nous allons effectuer 15 tirages de dés et tenter de réaliser l’ensemble des tâches prévues.
Fin de l’itération 1 : la vélocité est bonne puisque nous avons terminé les tâches de l’itération 1 et entamé celles de l’itération 2 : en 15 tirages la vélocité est de 11 points tâche réalisés.
Itération 2 : la vélocité baisse, une tâche prend beaucoup de tirages de dés pour être entérinée (et ne l’est pas en fin d’itération). Nous ajustons la vélocité à 6 points pour l’itération 3 pour tenir compte de l’écart entre le prévu et le réalisé et prévoir la vélocité.
Par manque de temps nous ne pouvons pas poursuivre le déroulement du « projet », mais nous dessinons les diagrammes qui donneront de la visibilité à notre projet :
BurnDown chart : En abscisses les itérations prévues, en ordonnées les points tâches restant à réaliser. La tendance idéale est de suivre la droite tirée entre le nombre d’itérations et le reste à faire à 0.
BurnUp chart : En abscisses les itérations, en ordonnées les points cumulés de la valeur client acquise. En pointillés, un exemple type que prend en général la suite de ce genre de graphique.
Conclusion :
La métaphore du jeté de dé semble assez réaliste et probante pour simuler un projet car dans un projet, divers imprévus peuvent survenir : humains, techniques, liés à des erreurs d’estimations :
- L’ajustement de la vélocité qui tient compte de l’expérience des itérations passées est un fait réaliste (pour l’avoir vécu).
- Un des impondérable que l’on peut rencontrer dans un projet est matérialisé par le tirage au sort du dernier dé (à 20 faces) : ceci a compliqué la réalisation d’une tâche en itération 2.
- Les erreurs de chiffrage ou d’estimation interviennent lorsqu’on croit maîtriser un sujet et qu’en réalité les certitudes s’avèrent incorrectes : le postulat implicite que les dés étaient des dés à 6 faces illustre parfaitement ceci.
Le contexte présenté est un contexte idéal : un client chiffre rarement la valeur qu’une tâche peut avoir pour lui : le product owner a réalisé un véritable travail en amont pour l’évaluer avec le client, cela suppose une très bonne communication avec ce dernier lors du recensement de ses besoins, ceci exige de sa part un investissement sans faute.
L’objectif était aussi de nous montrer une évolution typique de BurnUp chart. Il indique bien avant la fin du projet que la valeur client est acquise aux 2/3. D’après les conférenciers, des projets peuvent se terminer à ce moment, la valeur acquise étant suffisante pour le client. Le gain de productivité pouvant intervenir, pour une part, comme rétribution au mérite pour les développeurs (une source de motivation non négligeable), l’autre partie comme gain pour le client.
