Estimation agile et cône d'incertitude
Auteur : Agile101 - Tara Lee Whitaker
Source : Agile Estimation and the Cone of Uncertainty
Traducteur : Fabrice Aimetti
Date : 21/08/2009
Traduction :
Le Cône d’incertitude est un terme utilisé en Gestion de Projet pour décrire le degré d’incertitude existant aux différents stades d’un projet.
En bref, nous devenons de plus en plus certains de nos estimations lorsque nous en apprenons plus sur ce que nous devons estimer.
Dans les environnements de Gestion de Projet Agile, nous acceptons que les projets portent une part d’incertitude. Cette incertitude diminue à mesure que les décisions sont prises autour du périmètre et de la démarche – plus nous comprenons, plus nous sommes certains de nos estimations.
Pour atténuer le risque d’estimations incorrectes, nous réduisons la précision de nos estimations en fonction de ce que nous savons de ce que nous devons estimer. Cela nous aide à être plus exact.
(Voir Estimation logicielle : Le plus précis vous êtes, le moins exact vous serez)
Exigences Agiles par ordre d’Incertitude
1. Thème
2. Epic
3. User Story
4. Tâche
(Voir La différence entre les termes Agiles Thèmes, Epics et User Stories
Techniques d’Estimation Agile dans une recherche de Précision
1. Heures
2. Story Points
3. Taille de T-shirt
Estimer en Heures vs Fibonacci
Comme indiqué dans mon post Estimation logicielle : Le plus précis vous êtes, le moins exact vous serez, des études suggèrent que les estimations qui ont lieu au cours de la Phase de Définition du Produit représentent entre 300% de moins et 0,75% de plus que ce que cela prend réellement pour construire le logiciel soit un coefficient multiplicateur de 16. Le cône d’incertitude se rétrécit au fur et à mesure que vous éliminez les incertitudes.
Dans les environnements Agile, nous utilisons deux principales métriques d’estimation : Fibonacci et les Heures.
L’Estimation basée sur les Heures s’explique de soi-même, toutefois, il convient de mentionner que les Équipes Agiles estiment uniquement des Tâches en heures. Par Tâches, je veux dire "Parties de User Story"... quelque chose de très petit qui devrait prendre quelques heures, certainement pas plus d’une seule journée à réaliser.
Pourquoi ?
Généralement, les très grosses fonctionnalités sont plus complexes et devront/pourront probablement être décomposées en plus petits éléments : il reste donc un certain nombre de décisions en suspens qui pourraient affecter la quantité d’effort requise pour réaliser la tâche.
Plus la tâche est importante, moins il y a de chances que vous soyez en mesure d’estimer
le nombre exact de minutes/heures pour la réaliser (interruptions téléphoniques, pauses toilettes, réunions différées, ...).
En d’autres mots, estimez de PETITES tâches en heures.
L’Estimation basée sur Fibonacci est la deuxième métrique d’estimation Agile. Nous appelons cela Estimation en Story Points. Nous utilisons des Story Points pour estimer de grosses fonctionnalités : User Stories et Epics.
Cela fonctionne comme suit :
0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
En d’autres termes, un "5" équivaut à 5 fois plus d’effort qu’un "1" et un "8" à 8 fois plus d’effort qu’un "1".
Les Story Points permettent de mesurer des choses que nous ne pouvons pas mesurer en heures – par exemple la complexité – comptabilisez vous une tâche pour chacune des discussions dont vous aurez peut-être besoin, à chaque fois que vous prenez 10 minutes pour répondre à une question ? Il est cependant relativement facile (lorsque vous vous y mettez) de comparer la taille d’une tâche / ensemble de tâches avec une autre tâche / ensemble de tâches. Estimer en Story Points vous permet de prendre en considération toutes sortes de "choses" intangibles que vous pressentez sans pouvoir précisément les nommez.
(Voir Estimation logicielle : Le plus précis vous êtes, le moins exact vous serez)
L’Estimation basée sur les Tailles de T-Shirts
Le "T-shirt Sizing" est une méthode d’Estimation Agile : elle est utilisée pour estimer les exigences de haut niveau c’est-à-dire des Epics, mais peut être aussi utilisée pour une User Story "bizarre".
En bref, vous attribuez un nombre de story points à une taille de t-shirt par exemple, un XXL pourrait valoir "55 points" comme le montre le schéma ci-dessous. Les tailles de T-shirt sont très utiles pour les Product Owners et/ou des non techniciens étant donné qu’elles sont totalement abstraites et non menaçantes (sans que cela devienne paternaliste... si vous voyez ce que je veux dire !). Elles sont faciles à comprendre.
Lorsqu’on estime en taille de T-shirt, il est toujours important de définir l’échelle – convenez à l’avance de ce que vaut un "Small", "Large" et "XX Large".
Le T-shirt sizing aura normalement lieu lors des Ateliers Exigences – ce qui aide le Product Owner et le Product Manager à avoir une idée de l’échelle, et ce qui aidera donc grandement au processus de priorisation.
Comme toujours, c’est l’Équipe Scrum qui attribuent les tailles de T-shirt aux Epics. Le Product Owner et/ou le Product Manager ne sont pas autorisés à participer au processus d’estimation – ils peuvent en effet communiquer la vision du produit et des préconisations, mais les estimations appartiennent à l’équipe Scrum.
L’Estimation basée sur les Story Points
Une fois que les Epics ont été évaluées et priorisées pour la livraison, elles seront ventilées en User Stories par le Product Manager et le Product Owner.
Les User Stories seront ensuite présentées aux ateliers exigences ultérieurs et estimées en Story Points lors du Planning Poker.
(Voir Réunions de planification de Sprints en Scrum : Qui, Quoi, Quand, Où, Pourquoi)
Pour en savoir plus.
