Estimation Agile et Cône d’incertitude

((/dotclear/public/logos/agile101_logo.png|Logo Agile101|L|Logo Agile101, aoû 2009))J’ai traduit un article intéressant de Agile101 : ++[Agile Estimation and the Cone of Uncertainty|http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/|en]++%%% %%% > 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|http://agile101.net/2009/07/17/software-estimation-the-more-precise-you-are-the-less-accurate-you-will-be/|en]++)%%% > %%% > __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|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/20/La-difference-entre-les-termes-Agiles-Themes-Epics-et-User-Stories|fr]++)%%% > %%% > __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|http://agile101.net/2009/07/17/software-estimation-the-more-precise-you-are-the-less-accurate-you-will-be/|en]++, 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|http://agile101.net/2009/07/17/software-estimation-the-more-precise-you-are-the-less-accurate-you-will-be/|en]++)%%% > %%% > 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|http://agile101.net/2009/07/24/scrum-sprint-planning-meetings-who-what-when-where-why/|en]++)%%% > %%% > ++[Pour en savoir plus|http://agile101.net/category/project-management/agile-estimation/|en]++.%%% ((/dotclear/public/./.cone-of-uncertainty_t.jpg|Cône d’incertitude|L|Cône d’incertitude, aoû 2009))Pour voir le schéma dans sa taille normale, rendez-vous sur le ++[billet de l’auteur Tara Lee Whitaker|http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/|en]++.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *