« Il est difficile de prévoir… surtout l’avenir ! » disait Bernard SHAW.
L’estimation est une évaluation quantitative des coûts, des ressources, ou de la durée du projet. Par nature, elle est imparfaite, car le seul moment où l'on connaîtra le budget réel du projet... c'est à la fin du projet ! L’exercice d'estimation peut parfois s’avérer périlleux, conduire à un sous-dimensionnement du projet, et par voie de conséquence, à son échec. S’il existe de nombreuses méthodes d’estimation, nous vous proposons aujourd’hui de zoomer sur l’une d’entre elles, le "planning poker".
Mais avant de sortir les cartes, il convient de parler des lagomorphes à longues oreilles, autrement dit… les lapins.
De la croissance de la population des lapins et de son impact sur les projets
En 1202, un mathématicien italien du nom de Leonardo Fibonacci, pose le problème récréatif suivant dans l’un de ses ouvrages, le Liber Abaci :
« Un homme met un couple de lapins dans un lieu isolé de tous les côtés par un mur. Combien de couples obtient-on en un an si chaque couple engendre tous les mois un nouveau couple à compter du troisième mois de son existence ? »
Quelle conclusion en tirer ?
Je suppose que vous avez fait des calculs savants, et que vous avez abouti à la conclusion suivante :
- au (début du) premier mois, il y a juste une paire de lapereaux ;
- les lapereaux ne procréent qu'à partir du (début du) troisième mois ;
- chaque (début de) mois, toute paire susceptible de procréer engendre effectivement une nouvelle paire de lapereaux ;
- et ça continue ainsi jusqu’à la mort des lapins.
Quel lien entre votre projet et les lapins ?
A ce moment de votre lecture, vous vous demandez sans doute quel est le lien entre une bande de lapins et l’estimation de votre projet.
Et bien sachez que cette passion (temporaire) de Fibonacci pour nos amis léporidés l’amena à formaliser sa fameuse suite (de Fibonacci !) : une suite d'entiers dans laquelle chaque terme est la somme des deux termes qui le précèdent. Elle commence généralement par les termes 0 et 1 (parfois 1 et 1) et ses premiers termes sont : 0, 1, 1, 2, 3, 5, 8, 13, 21, etc.
Et cette suite s’avère fort utile pour étalonner la complexité d’éléments à produire dans le cadre d’un projet: c'est à dire que dans un même projet, des livrables ou tâches à réaliser d'une complexité de 3 peuvent en côtoyer d'autres d'une complexité de 21 (soit 7 fois plus complexes!) ou de 1 (3 fois moins complexe).
Le planning poker comme outil clé pour votre projet
Le « planning poker » est un outil clé du processus d’estimation de la méthode agile SCRUM. Le principe ? Les équipes n’estiment pas en termes de charge de travail ou d’euros, mais, à la place, utilisent une mesure plus abstraite pour quantifier l'effort.
Estimer le coût et le durée de votre projet
Alors concrètement, comment estimer le coût ou la durée de votre projet avec le planning poker ?
1 - Commencez par identifier l’ensemble des “stories” du projet (une story est une fonctionnalité à livrer dans le projet).
2 - Une fois ce travail réalisé, réunissez l’équipe projet pour lui faire produire une estimation des stories. La chose importante est que l'équipe partage une compréhension commune de l'échelle, et qu’elle soit à l’aise avec ses différents niveaux, et surtout le rapport relatif entre ces niveaux.
3 - Les participants s'installent donc autour d'une table, placés de façon à ce que tout le monde puisse se voir. Un jeu de cartes est remis à chaque participant. Sur chacune des cartes, il y a une valeur possible pour l’estimation d’une story. En règle générale, c’est notre fameuse suite de Fibonacci qui est utilisée pour fixer la valeur des cartes (pourquoi Fibonacci ? Car plus la story est grosse, moins l'évaluation est précise).
4 - L’équipe définit un étalon : il s’agit d’une story connue de tous, pour laquelle l’équipe définit en commun une valeur arbitraire. Afin de laisser de l’espace d’estimation pour les autres stories, on choisit en règle générale pour étalon une story de taille moyenne, à laquelle on attribuera une valeur de 2, 3 ou 5.
5 - Présentez ensuite une nouvelle story à livrer. Les membres de l’équipe peuvent poser des questions de bien comprendre cette story, et débattent rapidement. Chaque participant choisit la carte qui correspond le mieux selon lui à l’estimation de la story, par rapport à sa complexité. Tous les participants dévoilent en même temps leurs cartes, et le groupe discute des différences éventuelles entre les estimations.
Cet échange doit permettre aux participants de réestimer la story : le groupe procède donc à de nouvelles estimations/discussions, jusqu’à trouver la convergence des estimations pour la story. Ecrivez alors le nom de la story sur un Post-it et positionnez ce dernier dans un tableau dans lequel chaque rangée correspond à une valeur d’estimation différente.
6 - Une fois l’ensemble des stories estimées, additionnez les points pour obtenir un total de points pour le projet (dans le cas ci-dessus : 2 story à 0,5 point + 2 stories à 1 point + … soit un total de = 60 points
7 - L’équipe doit maintenant estimer combien de points elle peut livrer dans le cadre d’un sprint (un sprint est un cycle de travail de 2 semaines qui doit donner lieu à une livraison partielle du projet), en prenant des options pessimistes et optimistes (la vélocité réelle de l’équipe ne pourra être mesurée qu’une fois qu’elle aura réalisé un premier sprint). Supposons par exemple que l’équipe se dise en capacité de livrer entre 15 et 20 points par sprint de deux semaines.
8 - Le nombre estimé de sprints pour terminer le projet = Nombre total de points / vélocité de l’équipe pendant un sprint, soit dans notre exemple :
- Total points = 60
- 60/15 = 4 Sprints
- 60/20 = 3 Sprints
- La moyenne des 2 estimations nous permet d’envisager une durée de 3,5 sprints (plus ou moins 0,5), soit 7 semaines au total.
- En supposant que le coût de l’équipe SCRUM soit de 25k€ par sprint (500€ par jour par personne x 5 personnes x 10 jours), le coût estimé du projet sera de : 25k€ x 3,5 = 87,5k€ (plus ou moins 12,5 k€).
CQFD !
Aujourd'hui, cette méthode d'estimation est particulièrement utilisée dans les projets de développement applicatifs gérés avec la méthode Scrum, mais elle tend à se déployer sur d'autres types de projet.
[poll id="4"]
