Estimation

Article
06/10/2015

De Mitch Lacey. Propriétaire, Mitch Lacey & Associates, Inc, un société de conseils spécialisée dans les adoptions et améliorations Agile et Scrum.

Janvier 2012

Mitch Lacey présentent les difficultés concernant l'estimation des projets logiciels et fournit des trucs et astuces pour utiliser les techniques d'estimation de deux logiciels Agile lors de l'estimation des projets.

S'applique à

Gestion du cycle de vie des applications ; Team Foundation Server

Sommaire

Introduction
Pourquoi l'évaluation est dure
Techniques d'évaluation
Points de récit comme unité de mesure
Planification du poker
Évaluation du mur
Évaluation
Définition de priorités
Conclusion

L'estimation du travail qui est créatif et imprévisible est indéniablement difficile. Le choix d'une méthode peut être également délicat. Fred Brooks l'indique mieux : « Il est très difficile d'établir une protection contre les risques liés au travail performante et plausible, qui est dérivée par une méthode quantitative, prise en charge par peu de données et principalement certifiée par les intuitions des gestionnaires. »

Et pourtant nous sommes invités à donner des estimations de nos projets logiciels d'avance et tôt, et en dépit de tous nos efforts pour rappeler à la direction que ces estimations sont approximatives, trop souvent nos évaluations initiales se transforment en engagements.

Dans cet article, je vous montrerai pourquoi il est difficile d'estimer les projets d'avance, comment les techniques d'évaluation de logiciels Agile apportent une aide et comment estimer votre journal des travaux en souffrance (backlog) du produit à l'aide de la technique du planning poker et des points de récit.

Pourquoi l'évaluation est dure

Dans la plupart des projets, nous sommes invités à estimer d'avance. Pour comprendre pourquoi cela pose un tel problème, nous devons examiner le concept du « Cone of Uncertainty », présenté par Barry Boehm en 1981 et repris par Steve McConnell en 1997 dans son livre Software Project Survival Guide.

Cône d'incertitude

Le cône montre que nous avons le plus d'incertitudes au début d'un projet (une variation de 4x à 0,25x dans la plage). Cette variation signifie que la durée du projet que nous estimons à un an pourrait en fait être de 3 à 48 mois. Le début de n'importe quel projet est le moment où nous avons le moins de certitude sur le projet, même si c'est également lorsque nous sommes invités à fournir des évaluations qui sont très précises.

Dans Agile, nous essayons de passer de l'incertitude à la certitude dans un cycle aussi court que possible. Pour se faire, le système et la façon dont il doit être conçu doivent être correctement compris, le plus tôt possible. Pour ce faire, nous créons un chemin unique dans le système, un récit complet et cohérent. Nous utilisons ceci dès le départ pour nous débarrasser de toutes les hypothèses en termes de conception et d'exigences, afin d'atteindre un degré élevé de certitude plus rapidement et avec une plus grande confiance.

Techniques d'évaluation

Il existe un grand nombre de techniques d'évaluation valides, notamment le comptage, le jugement expert (personne et groupe), la décomposition, l'analogie, l'évaluation de proxy, le planning poker et l'évaluation du mur. Nous pouvons également utiliser des outils tels que Cocomo II. Toutes ces techniques nécessitent que nous choisissions une unité d'évaluation (heures, jours, semaines, mois, jours idéaux, taille d'un T-shirt, points) ou toutes les unités d'évaluation. Si nous ne comprenons pas l'unité, l'évaluation ne signifie rien. Au vu de tous ces faits, il n'est pas étonnant que l'évaluation est difficile.

Bien que les équipes agiles tendent vers une certaine version des unités et des techniques d'évaluation pour estimer le journal des travaux en souffrance (backlog) du produit (points de récit et planning poker), votre équipe doit se sentir libre d'utiliser la méthode la mieux adaptée à ses besoins. De mon expérience, l'expression d'estimations en termes de points de récit, par l'utilisation du planning poker ou de l'évaluation de mur, donne les meilleurs résultats possibles. Dans les paragraphes suivants, vous en saurez plus sur les points de récits en tant qu'unité de mesure et sur deux techniques d'estimation que je préfère : le planning poker et l'évaluation sur tableau.

Points de récit comme unité de mesure

Mike Cohn définit les points de récit comme étant des unités de mesure permettant d'exprimer la taille globale d'un récit utilisateur, d'une fonctionnalité ou d'un autre type de travail. » Les points de récit nous montrent l'importance d'un récit par rapport à d'autres, en termes de taille ou de complexité. Mike fait souvent référence aux tailles de chien pour aider les équipes à comprendre le concept de dimensionnement relatif. Un (petit) chien de taille 2 est un chihuahua. Un (gros) chien de taille 13 est un dogue allemand. Avec ces deux repères à l'esprit, il est assez facile de dimensionner les autres races de chien par rapport à un chihuahua ou à un dogue allemand. Un beagle, qui est environ deux fois plus gros qu'un chihuahua, peut correspondre à la taille 5. Un labrador, qui est plus gros qu'un beagle mais plus petit qu'un dogue allemand, peut correspondre à la taille 8.

Lorsque vous apprenez à utiliser des points de récit, votre équipe devra créer vos propres points de comparaison fixes. Pour ce faire, choisissez un récit dans votre journal des travaux en souffrance (backlog) du produit que vous considérez comme petit (en termes de taille ou de complexité) et un autre récit que vous considérez comme très grand. J'aime que mon petit récit soit basé sur deux points car si je devais devenir plus petit (supposons que je découvre un Chihuahua en jouet), je pourrais le faire. Si je limite mon plus petit récit connu à un récit d'un point et que je dois faire plus petit, je risque d'avoir des problèmes. Les autres récits peuvent ensuite être classées par rapport à ces derniers.

Lorsqu'il s'agit de choisir des nombres pour représenter ces tailles, je pense que la séquence de Fibonacci est la plus appropriée. Fibonacci est la somme des deux nombres précédents. 1 et 2, le suivant est 3. 3 et 2, le suivant est 5. 5 et 3, le suivant est 8, etc. Je préfère Fibonacci, par exemple la taille d'un T-shirt ou la croissance exponentielle (4/8/16/32/64/128/256, etc.) car nous les humains, nous sommes bons sur la base de dix. Lorsque nous sortons de cette plage, même si nous sommes dedans avec par exemple xs, s, m, l, xl, cela provoque une confusion. Les nombres de Fibonacci sont simples, facilement compréhensibles et fournissent suffisamment de précision pour atteindre les objectifs (fournir des estimations relatives). Vous pouvez choisir un ensemble de nombres différent, mais souvenez-vous que l'important est de rester cohérent.

Les points de récit sont des valeurs relatives, non fixes. Il n'y a pas de corrélation directe entre les heures et les points. Par exemple, nous ne pouvons pas affirmer avec certitude qu'un récit à deux points est égale à 12,2 heures car les récits dans la plage de deux points varient considérablement en termes d'heures réelles consacrées à leur exécution. De même, vous ne pouvez pas comparer les points de récit d'une équipe avec ceux d'une autre avec certitude. Les points de récit sont créés par l'équipe qui les a estimés et lui sont spécifiques. Ils incluent probablement un degré de complexité uniquement compris par l'équipe, et ne sont pas absolus.

Planification du poker

Après avoir choisi votre unité de mesure et établi votre échelle, il est temps de passer à l'estimation. La plupart des équipes Agile utilisent la technique du planning poker pour estimer la taille relative des récits. Elle est populaire chez les équipes Agile car il s'agit d'une mesure objective qui inclut plusieurs techniques d'évaluation subjectives, notamment le jugement analogique et le jugement d'expert. La clé du planning poker est la participation. Chaque membre de l'équipe doit participer - OUI, tout le monde. Les testeurs fonctionnels évalueront des tâches de développement et vice versa. Les chefs de projet fonctionnels peuvent également évaluer les tâches de développement. Cette procédure garantit que les nombres objectifs incluent l'évaluation subjective autant que possible.

Commencez par un jeu de cartes du planning poker. Les cartes de planning poker peuvent facilement être effectuées avec des fiches, fournies via l'utilisation de cartes de jeux, ou achetées (Visual Studio les fabrique même). À chaque carte correspond un nombre dans la plage sélectionnée des points de récit (1, 2, 5, 8, 13, etc.). Chaque participant donne un « coup de main » qui représente la gamme complète des points de récit disponibles.

Exemple de cartes de planning poker

Une fois les cartes distribuées, le jeu démarre.

Le Scrum Master présente l'élément supérieur du journal des travaux en souffrance (backlog) du produit à l'équipe.
L'équipe discute du récit.
Le propriétaire du produit explicite les questions, les hypothèses et les éléments inconnus, ainsi que les critères d'acceptation.
Chaque membre de l'équipe définit la taille du récit par rapport au récit de référence, une série de récits de référence ou tous les récits du journal des travaux en souffrance (backlog) du produit.
Au bout de trois, chacun montre la carte choisie simultanément.

Si chacun jouait la même carte, l'équipe pourrait stocker l'évaluation et passer au récit suivant.

En cas de variation large (par exemple, les nombres affichés s'étendent de un à huit), l'équipe prend le temps de discuter du récit. Pour concentrer la discussion, demandez au soumissionnaire moins-disant et au soumissionnaire le plus offrant d'expliquer leur raisonnement concernant leurs estimations. La conversation est importante ici et pas le nombre, car c'est là que l'apprentissage se produit et toutes les hypothèses sont mises à jour. Après une brève discussion de 30 secondes à une minute, l'équipe répète les étapes 4 et 5. Cela continue jusqu'à ce que l'équipe accepte une évaluation pour le récit.

Cela semble relativement simple, mais il est important de comprendre certains principes de base. D'abord, si l'équipe ne trouve pas un terrain d'entente commun, inutile de continuer. Par exemple, disons qu'il existe un membre de l'équipe qui lit un huit mais que tous les autres choisissent cinq. Si le facilitateur de réunion dit, « Assez proche. Nous choisissons le cinq pour cette fois ; poursuivons », que va faire la personne qui avait choisi le huit ? D'après mon expérience, cette personne acceptera ce que l'équipe décidera, mais mettra un terme à sa participation. La planification peut aller plus rapidement de cette façon, mais vous avez perdu un élément précieux. Non seulement cette personne perd la compréhension du travail mais l'équipe perd l'entrée et la perspective du membre. Il est aussi possible de ne pas être d'accord. Les discussions sur la raison pour laquelle une personne a sélectionné un nombre plus élevé que tous les autres permettent une compréhension précieuse. Si vous vous trouvez dans une impasse, faites en sorte que le facilitateur tente d'appliquer la technique « Fist to Five ». Il faut faire des merveilles pour accélérer les réunions sans éloigner les participants.

Comme la planification du poker exprime les estimations en points, cela convient parfaitement à l'évaluation du journal des travaux en souffrance (backlog) du produit. Le journal des sprints en souffrance doit toutefois être estimé en heures. Ceci étant dit, le planning poker peut être et a été utilisé correctement pour estimer des journaux des sprints en souffrance ; les numéros sur la carte, deviennent toutefois des heures et non des points. Ainsi, la règle simple –

Les évaluations du journal des travaux en souffrance (backlog) du produit sont en points.
Les estimations du journal des sprints en souffrance ont lieu en heures.

Vous pouvez utiliser le planning poker au début de n'importe quel projet et tout au long de son cycle de vie à mesure que les nouvelles informations se révèlent elles-mêmes, les priorités sont modifiées, et la clarté ressort.

Évaluation du mur

Le planning poker est un outil fantastique pour estimer les récits utilisateur, mais il faudrait beaucoup trop de temps pour estimer des centaines de récits, un par un, à l'aide de cet outil. Si vous avez un journal des travaux en souffrance (backlog) brut rempli avec des centaines de récits qui n'ont pas été évalués ou qui n'ont pas été classés par ordre de priorité, vous devrez recourir à une méthode d'évaluation plus rapide.

L'évaluation du mur est conçue pour permettre aux équipes d'éliminer les discussions à 2 contre 3 et à 5 contre 8, et de regrouper les choses de manière purement relative en optant pour un continuum, au moins pour commencer. Elle permet également aux parties prenantes de donner la priorité générale à un grand groupe de récits sans être bloquées par le fait qu'un récit est légèrement plus important qu'un autre.

Pour une l'évaluation du mur, vous devez d'abord imprimer les récits utilisateur sur des cartes. Regroupez ensuite votre équipe et les parties prenantes dans une pièce entourée de grands murs vides (d'environ 4 mètres de long et 2,5-3 mètres de haut). Retenez deux éléments à propos du mur :

La hauteur détermine la priorité. Les récits situés en haut ont une priorité plus élevée ; les récits situés en bas ont une priorité moins élevée. La priorité d'un récit peut être basée sur le retour sur investissement, la valeur commerciale ou quelque chose d'aussi simple que « c'est important, et je ne sais pas pourquoi ».
La largeur est réservée pour la taille. Les récits à gauche sont plus petits ; les récits à droite sont plus grands. (Vous pouvez faire le contraire et aller de droite à gauche si vous êtes, par exemple, au Japon, ce qui est plus logique). La chose importante consiste à prévoir une ligne passant horizontalement et une autre verticalement. Les membres de l'équipe et les participants doivent se demander où, par rapport aux autres récits, celui-ci doit figurer ?

L'équipe utilisera le mur pour dimensionner tous les récits. Les parties prenantes utiliseront le mur pour classer les récits par ordre de priorité. Comme pour la planification du poker, nous utilisons le dimensionnement relatif, mais au lieu d'utiliser deux récits de référence pour la comparaison, le mur devient la constante. Petit récit ? Déplacez vers la gauche. Grand récit ? Déplacez vers la droite. Récit important ? Placez vers le haut. Un récit dont nous pouvons nous passer pour le moment ? Placez vers le bas.

Les parties prenantes n'ont pas besoin d'être présentes pendant l'estimation des récits, mais l'équipe doit être présente dans la salle pendant le classement par priorité des récits. Le Scrum Master et le propriétaire du produit doivent assister aux activités d'évaluation et de priorité.

Maintenant si vous avez déjà un journal de travaux en souffrance estimé, vous pouvez simplement effectuer la section de définition des priorités de cet exercice. Si les propriétaires de produits et les parties prenantes vous ont déjà fourni un journal des travaux en souffrance (backlog) classés par ordre de priorité, vous pouvez simplement effectuer la section d'évaluation de cet exercice. (Le propriétaire du produit souhaitera probablement revoir l'ordre des priorités une fois les estimations effectuées. Après tout, le coût a un impact important sur la priorité). Examinons en détail le mode de fonctionnement, en commençant par le rôle de l'équipe.

Évaluation

Donnez à l'équipe le journal des travaux en souffrance (backlog) du produit brut, et commencez par l'évaluation. Informez l'équipe que l'extrême gauche du mur doit contenir les récits les plus petits possible et que l'extrême droite du mur doit contenir les récits les plus grands possible, quels que soient les nombres. En fonction de ces deux pôles, l'équipe place les récits quelque part sur le mur. L'avantage de cette méthode est qu'il n'y a aucune notion préconçue à propos d'un récit à deux ou trois points ; elle est vraiment basée sur la grandeur du mur, c'est pourquoi un mur très grand est pratique.

Si votre équipe rencontre des difficultés pour le faire, vous pouvez donner plus de structure au mur en fournissant des récits supplémentaires de référence allant de 1 à 8 points. Veillez à ne pas créer un plus grand récit de référence, car il risque d'être décomposé du fait qu'il figure en priorité. Une fois que l'équipe a identifié les cinq récits, placez-les sur le mur, dans un emplacement en corrélation avec leurs tailles (de nouveau, en allant de gauche à droite). Laissez de la place sur la partie droite du mur pour les récits supérieurs à huit points. Placez ces récits sur le mur et indiquez à l'équipe de placer les récits restants sur le mur par rapport à ces récits de référence, en conservant à l'esprit que les petits récits vont vers la gauche et que les récits plus importants vont vers la droite.

Avec les récits sur le mur, demandez à l'équipe d'identifier les interruptions logiques entre les tailles de récit. Enregistrez une ligne verticale entre des groupes de récits pour illustrer ces sauts. Bientôt vous aurez un mur semblable à celui indiqué ici. Le contenu du premier groupe pourrait correspondre à 2 ; le contenu du deuxième groupe à 3 ; le contenu du troisième groupe pourrait correspondre à 5 ; et le contenu du dernier groupe à 8. Les nombres sont moins importants que le fait que tous les récits sont maintenant considérés comme ayant un rapport les uns par rapport aux autres.

Exemple d'estimation de mur - Tri relatif

Maintenant que vous avez estimé vos récits, vous devez impliquer les parties prenantes pour affecter une priorité aux récits.

Définition de priorités

Bien que vos clients et parties prenantes souhaitent évaluer l'importance d'un récit pour les aider à déterminer sa priorité, ils sont beaucoup plus attentifs à rechercher les récits qui les concernent et à s'assurer de leur réalisation. Attendez-vous à ce que les parties prenantes n'acceptent pas l'ordre de priorité - le propriétaire du produit utilisera ces informations pour déterminer la priorité finale.

Décrivez le mur aux parties prenantes. Dites-leur que les cartes sur le mur reflètent toutes les fonctionnalités qu'ils souhaitent voir dans le produit fini. Expliquez que l'équipe a déjà évalué chaque récit et qu'elle peut déterminer l'évaluation de point pour un récit en fonction de la colonne dans laquelle il se trouve sur le mur. Rappelez-vous que tous les membres de l'équipe ne sont pas des participants actifs dans la définition de priorités. Ils doivent observer, prendre des notes sur le comportement, les interactions et les raisons pour lesquelles certains récits deviennent plus ou moins prioritaires. Ils peuvent également répondre à tous les questions des parties prenantes, le cas échéant. Si l'équipe ne peut pas redimensionner un ou plusieurs récits en toute confiance car des réponses doivent être apportées par une partie prenante particulière, l'équipe peut également poser des questions sur ces récits, puisque le temps le permet.

Demandez aux parties prenantes d'aider à déterminer la priorité relative de toutes ces récits en les déplaçant à l'intérieur des colonnes vers le haut ou vers le bas. Rappelez-les leur que plus un récit est en hauteur sur le mur, plus sa priorité est élevée pour l'entreprise. Définissez les règles suivantes :

Si vous placez un récit en haut, préparez-vous à justifier son positionnement.
Vous pouvez vous demander pourquoi un récit est plus importante qu'un autre. Sentez-vous libre de vous interroger mutuellement « Qui a abaissé (ou relevé) celui-ci ? » ou vous demander à haute voix, « Je pense que celui-ci doit être déplacé ». Qui souhaite ne pas être d'accord ? » Cela permet une conversation entre les parties intéressées, sans facilitation.
Si vous déplacez un récit plus bas sur le mur qu'une autre personne, marquez-le avec un point de couleur pour vous alerter.

Le plus grand avantage de classer par ordre de priorité en tant que groupe est que toutes les parties prenantes peuvent mieux comprendre les priorités des différents récits. Si une discussion dure trop longtemps sans véritable solution, le propriétaire du produit doit collecter la carte, identifier les deux parties prenantes qui ne peuvent pas s'entendre et faire une note pour les rencontrer en privé ultérieurement.

L'exercice peut prendre de 2 à 6 heures, en fonction du nombre de récits et de parties prenantes. Lorsque vous avez terminé, le mur doit ressembler à l'illustration ci-dessous.

Exemple d'estimation de mur - Tri par priorité

Votre mur est divisé approximativement en quatre quadrants. Les récits situés en haut à gauche sont courts et de priorité élevée. Ils seront placés en haut du journal des travaux en souffrance (backlog) du produit. Les récits situés en haut à droite sont de priorité élevée, mais sont également longs. Ces récits doivent être décomposés au plus tôt, afin de pouvoir être introduits dans les sprints suivants.

Estimation du mur - Quatre quadrants

Le quadrant gauche inférieur se compose de petits récits qui sont de priorité moindre. Elles tomberont probablement en bas du journal des travaux en souffrance (backlog). Le quadrant droit inférieur contient de grands récits qui sont également de priorité moindre. Ces récits sont vos narrations ou thèmes. Elles devront sans doute être décomposées en récits plus petits et plus gérables, mais pas tant que leur priorité n'aura pas augmenté.

Prenez le temps d'examiner le mur dans son ensemble avec le groupe. Si un récit se trouve dans le quadrant incorrect, déplacez-le. Si un récit de haute priorité doit être décomposé et que le temps le permet, alors faites-le lorsque tout le monde est réuni.

À la fin de l'évaluation sur tableau, vous aurez le début d'un plan de version. Si vous connaissez la rapidité historique de l'équipe, vous pouvez même fournir une plage approximative dont les récits dans le quadrant supérieur gauche seront terminés.

L'évaluation est une tâche difficile car l'incertitude est très pesante au début d'un projet. Les propriétaires du produit et les gestionnaires du projet Agile essaient d'optimiser rapidement l'apprentissage en échangeant avec les propriétaires de leurs produits et les parties prenantes, en produisant un logiciel fonctionnel, et en intégrant des commentaires sur ce logiciel pour arriver à un état libérable. Mais même les projets Agile doivent fournir une estimation de la date de disponibilité d'un ensemble de fonctionnalités pour la version finale.

Les deux techniques d'évaluation recommandées sont la technique du planning poker (adaptée aux petits groupes de récits) ou celle de l'évaluation du mur (adaptée pour la gestion des grands journaux des travaux en souffrance des produits bruts). L'un ou l'autre vous offre les données que vous devez utiliser pour constituer un plan, ce qui est l'objectif ultime de l'évaluation.