Techniques d’estimation agiles

Abstract

L’estimation de l’effort de travail dans les projets agiles est fondamentalement différente des méthodes traditionnelles d’estimation. L’approche traditionnelle consiste à estimer en utilisant une technique « ascendante » : détailler toutes les exigences et estimer chaque tâche pour répondre à ces exigences en heures/jours, puis utiliser ces données pour développer le calendrier du projet. Les projets agiles, en revanche, utilisent une approche « descendante », en utilisant des techniques d’estimation de niveau brut sur des ensembles de fonctionnalités, puis en employant des méthodes d’élaboration progressive et de planification par vagues successives pour descendre jusqu’au niveau des tâches sur une base juste-à-temps, en découvrant itérativement de plus en plus de détails à chaque niveau inférieur. Cet article développera deux techniques communes pour l’estimation agile (poker de planification et groupement d’affinité), ainsi que de toucher sur la façon dont les résultats de ces exercices fournissent des entrées dans la prévision du calendrier et du budget.

Top-down vs. Bottom-up

La méthode traditionnelle d’estimation des projets est de passer plusieurs semaines ou mois au début d’un projet à définir les exigences détaillées pour le produit en cours de construction. Une fois que toutes les exigences connues ont été obtenues et documentées, un diagramme de Gantt peut être produit, montrant toutes les tâches nécessaires pour répondre aux exigences, ainsi que l’estimation de chaque tâche. Les ressources peuvent alors être affectées aux tâches, et des actions telles que le chargement et le nivellement permettent de déterminer la date de livraison finale et le budget. Ce processus est connu comme une méthode ascendante, car tous les détails concernant le produit doivent être définis avant que le calendrier et le coût du projet puissent être estimés.

Dans l’industrie du logiciel, l’utilisation de la méthode ascendante présente de graves inconvénients en raison de la vitesse du changement d’aujourd’hui. La vitesse du changement signifie que la vitesse des nouveaux outils de développement et la vitesse d’accès aux nouvelles connaissances sont si grandes que tout retard dans la livraison laisse ouvert à des alternatives compétitives et au danger de livrer un produit obsolète (Sliger, 2010).

La méthode descendante aborde ce problème clé, en utilisant les informations actuellement disponibles pour fournir des estimations de niveau brut. La planification par roulement est ensuite utilisée pour intégrer de nouvelles informations au fur et à mesure qu’elles sont apprises, en affinant davantage les estimations et en élaborant de manière itérative avec plus de détails au fur et à mesure que le projet progresse. Cette méthode consistant à apprendre juste assez pour démarrer, avec un plan pour incorporer plus de connaissances au fur et à mesure que les résultats du travail évoluent, permet à l’équipe de projet de réagir rapidement à l’adversité et à l’évolution de la demande du marché.

Techniques d’estimation

Les techniques d’estimation de niveau brut sont utilisées par les équipes utilisant des approches agiles telles que Scrum et Extreme Programming, et cet article couvrira deux des techniques les plus populaires : Le poker de planification et le groupement d’affinité. Les unités d’estimation utilisées seront également examinées, car ces unités doivent être telles qu’elles ne peuvent être confondues avec le temps.

Planning Poker

La technique la plus populaire d’estimation de niveau brut est le Planning Poker, ou l’utilisation de la séquence de Fibonacci pour attribuer une valeur de point à une fonctionnalité ou un élément (Grenning, 2002). La séquence de Fibonacci est une série mathématique de nombres qui a été introduite au 13ème siècle et utilisée pour expliquer certains aspects formatifs de la nature, comme la ramification des arbres. La série est générée en additionnant les deux nombres précédents pour obtenir la valeur suivante dans la séquence : 0, 1, 1, 2, 3, 5, 8, 13, 21, et ainsi de suite. Pour les besoins de l’estimation agile, certains des chiffres ont été modifiés, ce qui donne la série suivante : 1, 2, 3, 5, 8, 13, 20, 40, 100.

Ces nombres sont représentés dans un jeu de cartes à jouer (voir pièce 1). Les membres de l’équipe jouent au « Poker de la planification » (pièce 2) pour fournir une estimation sous la forme d’une valeur en points pour chaque élément. Voici les étapes :

• Chaque membre de l’équipe reçoit un jeu de cartes.
• Le propriétaire de l’entreprise (qui n’a PAS le droit d’estimer) présente l’élément à estimer.
• L’élément est discuté.
• Chaque membre de l’équipe choisit en privé une carte représentant son estimation.
• Quand tout le monde est prêt, toutes les cartes sélectionnées sont révélées en même temps.
• Si tous les membres de l’équipe ont sélectionné la même carte, alors cette valeur de point est l’estimation.
• Si les cartes ne sont pas les mêmes, l’équipe discute de l’estimation en mettant l’accent sur les valeurs aberrantes :
  • Le membre qui a sélectionné la valeur la plus faible explique pourquoi il a sélectionné cette valeur.
  • Le membre qui a sélectionné la valeur la plus élevée explique pourquoi il a sélectionné cette valeur.
• Sélectionner à nouveau jusqu’à ce que les estimations convergent.
• Si des conversations longues ou « dans les herbes » en résultent, les membres de l’équipe peuvent utiliser une minuterie de deux minutes pour encadrer la discussion, en sélectionnant à nouveau chaque fois que la minuterie s’épuise, jusqu’à la conversion.
• Répétez pour chaque élément (Cohn, 2006, pp. 56-57).

Il y a plusieurs raisons pour lesquelles les nombres de Fibonacci sont utilisés, et utilisés dans ce format. La première est l’idée qu’une fois que les équipes ont éliminé le temps comme base de l’estimation, elles sont moins susceptibles d’exiger plus de détails et de gonfler les estimations. Ces nombres représentent plutôt la taille relative, et non le temps. Par conséquent, l’exercice d’estimation se déroule assez rapidement. Les équipes consacrent généralement environ deux minutes à chaque élément, ce qui permet d’estimer un arriéré de 30 éléments en une heure. Le fait que les équipes soient limitées à seulement 9 choix (c’est-à-dire des valeurs de points ou des cartes) contribue également à accélérer le processus.

La séquence fournit également le bon niveau de détail pour les fonctionnalités plus petites et mieux comprises, tout en évitant un faux sentiment de précision pour les estimations plus élevées. Par exemple, un élément avec une estimation élevée (20 ou plus) signifie que l’élément est grand et pas encore bien compris. Débattre pour savoir si l’élément est un 20, un 19 ou un 22 serait une perte de temps car il n’y a tout simplement pas assez de données disponibles. Une fois que l’élément se rapproche de l’itération dans laquelle il sera travaillé, il peut être décomposé en plus petits morceaux et estimé en nombres plus granulaires (1-13). Les éléments avec des estimations de points de 1 à 13 peuvent généralement être achevés en une seule itération (1 à 4 semaines).

Il est important de noter que les points n’ont pas la même signification à travers les équipes ; par exemple, le « cinq » d’une équipe n’est pas égal au « cinq » d’une autre équipe. Ainsi, la vélocité de l’équipe, qui est dérivée des points, ne devrait pas être utilisée pour comparer la productivité entre les équipes.

Groupement par affinité

Un moyen encore plus rapide d’estimer, et utilisé lorsque le nombre d’éléments à estimer est important, est le groupement par affinité. Les membres de l’équipe regroupent simplement les éléments de même taille, ce qui donne une configuration semblable à celle de la pièce 3. La méthode est simple et rapide :

• Le premier élément est lu aux membres de l’équipe et placé sur le mur.
• Le deuxième élément est lu et on demande à l’équipe s’il est plus petit ou plus grand que le premier élément ; le placement sur le mur correspond à la réponse de l’équipe (plus grand est à droite, plus petit est à gauche).
• Le troisième élément est lu et on demande à l’équipe s’il est plus petit ou plus grand que le premier et/ou le deuxième élément ; le placement sur le mur correspond à la réponse de l’équipe (plus grand est à droite, plus petit est à gauche).
• Le contrôle est ensuite remis à l’équipe pour qu’elle termine le regroupement par affinité pour le reste des éléments.

Les équipes peuvent choisir de continuer de la même manière, en plaçant un élément à la fois sur le mur après la discussion de groupe. Cependant, une façon plus rapide est de demander à chaque membre de l’équipe de choisir un élément et de le placer en fonction de sa meilleure compréhension. Tous les membres de l’équipe travaillent en parallèle jusqu’à ce que tous les éléments aient été évalués et placés sur le mur. Plusieurs centaines d’éléments peuvent être estimés en un temps relativement court. Une fois que tous les éléments sont sur le mur, l’équipe examine les regroupements. Les éléments qu’un membre de l’équipe pense être dans le mauvais groupe sont discutés et déplacés si nécessaire.

Une fois le regroupement par affinité terminé, les valeurs des unités d’estimation telles que les points peuvent être attribuées. Dans la pièce 3, le premier ensemble à l’extrême gauche serait étiqueté comme ayant une valeur de 1 point, le deuxième ensemble serait de 2 points, le troisième ensemble de 3 points, le quatrième ensemble de 5 points et le dernier ensemble de 8 points.

Le regroupement par affinité peut également être fait pour d’autres unités d’estimation, comme les tailles de T-shirt. La pièce 4 montre un exemple d’articles groupés par affinité étiquetés avec des tailles de T-shirt au lieu de points.

Unités d’estimation

L’utilisation des tailles de T-shirt (Extra Small , Small , Medium , Large , Extra Large ) est une autre façon de penser aux tailles relatives des caractéristiques. Il s’agit d’un écart encore plus grand par rapport au système numérique et, comme toutes les bonnes unités d’estimation de niveau brut, elles ne peuvent en aucun cas être associées à une durée spécifique.

D’autres jetons de mesure arbitraires comprennent les Gummi Bears, les NUTS (Nebulous Units of Time) et les pieds-livres. Les équipes peuvent créer leurs propres unités d’estimation, et comme vous pouvez le voir, elles s’amusent souvent à le faire.

Ce document ne couvre pas l’utilisation d’unités temporelles telles que les jours et/ou les heures de développement idéaux. Ceux-ci sont déjà communs et bien compris, donc leurs explications n’ont pas été incluses. Il convient toutefois de noter que l’estimation au niveau brut a le potentiel d’être plus réussie lorsqu’elle est découplée de la notion de temps. Comme les estimations de temps sont souvent transformées en engagements par la direction et les entreprises, les membres de l’équipe se sentent davantage poussés à être aussi précis que possible. Par conséquent, ils demandent de plus en plus de détails sur l’élément à estimer. Cela transforme l’estimation de niveau brut en une estimation de niveau détail qui prend plus de temps et va à l’encontre de l’intention et de l’objectif initial.

Prévision du calendrier et du budget

Une fois que les estimations de niveau brut et la vélocité de l’équipe sont déterminées, le calendrier et le budget peuvent être prévus. Les équipes déterminent leur vélocité en additionnant le nombre total de points pour tous les éléments qu’elles ont terminés dans une itération. Par exemple, une équipe peut avoir sélectionné cinq éléments avec une valeur totale de 23 points (voir le tableau 5). À la fin de leur itération de deux semaines, ils n’ont été en mesure de terminer que quatre des cinq éléments. Leur vélocité est de 15, soit la somme des valeurs de points des items 1 à 4. Les équipes n’obtiennent pas de « crédit partiel » pour avoir complété des parties d’un élément, donc même si elles avaient commencé l’élément 5, il ne compterait pas, car il n’a pas été complété.

Détermination du calendrier

La vélocité moyenne d’une équipe est utilisée pour prévoir un calendrier à long terme. La vélocité moyenne est calculée en additionnant les mesures de vélocité des trois dernières itérations de l’équipe, et en divisant ce total par trois. Ainsi, si une équipe a réalisé 15 points dans sa première itération, et 20 points dans chacune des deux itérations suivantes, la vitesse moyenne de l’équipe est de 18 (15+20+20 / 3). Si une équipe peut réaliser 18 points en une itération en moyenne, et qu’il y a 144 points de travail à réaliser dans le projet, il faudra à l’équipe huit itérations pour terminer le travail (144 / 18). Si chaque itération dure deux semaines, l’achèvement prévu est de 16 semaines. Cette méthode permet de répondre à la question : « Quand aurons-nous terminé tout ce travail ? »

Si l’équipe dispose d’un historique de données de vélocité, il est possible de déterminer la date d’achèvement la plus optimiste, la plus pessimiste et la plus probable. Le nombre moyen de vélocité de l’équipe est utilisé pour calculer le scénario le plus probable, tandis que les nombres de vélocité des itérations les moins performantes de l’équipe sont utilisés pour calculer la date d’achèvement prévue la plus pessimiste. L’utilisation de la vélocité des itérations où l’équipe a pu terminer plus que prévu permet d’obtenir la prévision la plus optimiste.

Nous pouvons également utiliser ces chiffres pour répondre à la question suivante : « Nous devons livrer quelque chose à cette date – parmi ces fonctionnalités, combien en aurons-nous terminé à cette date ? » Voir la pièce 6 pour un exemple de la prévision du montant le plus probable à réaliser, de la prévision pessimiste et de la prévision optimiste. Cet exemple concerne une équipe dont la vitesse moyenne est de 20, et dont la vitesse la plus défavorable est de 12 et la vitesse la plus favorable de 25. Compte tenu de ces éléments et de seulement six semaines (trois itérations), quelle est la quantité de travail qui peut être réalisée ? La prévision pessimiste est que seuls les éléments 1 à 8 seront réalisés en six semaines. La prévision optimiste est que les éléments 1 à 18 seront réalisés. Et la prévision la plus probable, basée sur la vélocité moyenne de l’équipe de 20, est que les éléments 1-13 seront réalisés en six semaines.

Si les équipes utilisaient des unités d’estimation non numériques telles que les tailles de T-shirt, les algorithmes de prévision seront plus complexes. Il est recommandé de convertir les tailles en un système numérique pour générer plus facilement des données similaires. Par exemple, une petite taille pourrait être convertie en un NUT de 3, une taille moyenne en un NUT de 5, et ainsi de suite. Elles peuvent également être converties en plages de temps (une Petite pourrait être de 1 à 3 jours, par exemple), mais cela est intrinsèquement risqué, en raison des problèmes déjà cités dans la section des unités d’estimation.

Détermination du budget

Dans cette section, nous cherchons à répondre à la question suivante : « Nous n’avons que cette somme d’argent – combien de temps cela va-t-il durer et combien aurons-nous fait avant d’être à court ? » Tout d’abord, une formule simple est utilisée pour déterminer le coût par point :

Σ (salaires chargés de l’équipe pour la période n) / points réalisés dans la période n

Prenez la somme des salaires de l’équipe (chargés) pour une période de temps, disons trois itérations de deux semaines, et divisez-la par le nombre de points réalisés par l’équipe dans le même laps de temps. Ainsi, une équipe dont le total des salaires chargés est de 240 000 $ sur six semaines, et qui a réalisé 60 points de travail au cours de ces trois itérations, aurait un coût par point de 4 000 $. Maintenant, utilisez la formule suivante pour déterminer le budget :

(Coût par point x valeur totale en points des éléments à compléter) + autres dépenses = budget prévisionnel

Bien souvent, toutes les fonctionnalités d’un produit ne sont pas définies au début d’un projet, ce qui est attendu pour les projets agiles. Donc, les estimations budgétaires sont basées sur ce que nous savons aujourd’hui, plus un algorithme de prévision qui est basé sur des données historiques ou des conseils d’experts. Par exemple, disons qu’il n’y a que 20 fonctionnalités répertoriées jusqu’à présent, mais que l’entreprise ne sera pas en mesure de fournir des demandes de fonctionnalités supplémentaires ou des améliorations avant de voir comment la première version est reçue par le client. Le budget du projet, qui est prévu pour trois versions, ne disposerait de données prévisionnelles que pour la première version et non pour l’ensemble du projet. L’équipe pourrait utiliser l’algorithme ci-dessus pour prévoir le budget de la première version, puis supposer un supplément de 20% pour la deuxième version et un supplément de 5% pour la dernière version, sur la base de l’expérience passée.

Comme la vélocité, les prévisions budgétaires et les prévisions de calendrier sont révisées à chaque itération. Cela fait partie du processus de planification rolling-wave auquel les projets agiles adhèrent.

Mots finaux

Notamment non couvert dans ce document est le manque de techniques d’estimation structurées utilisées dans les approches lean telles que Kanban. Plutôt que de passer (perdre) du temps à estimer des éléments, les temps de cycle et de délai moyens sont calculés sur la base des taux de passage réels de l’équipe. Kanban utilise le théorème mathématique de la loi de Little comme base de ses formules. En utilisant les calculs de délais dérivés des diagrammes de flux cumulatifs, les équipes prévoient les calendriers des projets sans passer de temps à préparer des estimations. Le lecteur est encouragé à faire des recherches indépendantes sur ce sujet, qui pourrait faire l’objet d’un article distinct à lui seul.

Les projets agiles visent à livrer un produit ou des incréments de produit tôt et souvent, afin d’intégrer les commentaires des clients et d’autres apprentissages dans la prochaine version. En consacrant plus de temps à l’expérimentation, l’exécution et l’apprentissage, et moins de temps à la spéculation, la durée du cycle de livraison est réduite. Les équipes agiles sont plus à même d’être compétitives sur le marché et de suivre le rythme des changements toujours plus rapides.