Introduction
Avant d'engager un peintre pour décorer votre maison ou un mécanicien pour réparer votre voiture, vous avez une estimation de leur part, n’est-ce pas ? Vous avez besoin de savoir combien cela pourrait vous coûter et combien de temps cela pourrait prendre. C’est juste du bon sens.
Mais que l’expérience nous dit-elle cependant ? Quel écart y a t-il entre ces estimations initiales et la facture finale ? Il est fort probable que le peintre trouvera du plâtre altéré qui aura besoin d’être enlevé et que le mur aura besoin d’un nouvel enduit de façade et d’être replâtré. Le mécanicien est assuré de trouver du travail en plus, nécessaire à votre voiture pour être à nouveau en état de marche. Dans une caricature de 1951 pour le magazine New Yorker, Syd Hoff a dessiné un mécanicien disant à son client :
“Bien sûr, ce n’est qu’une estimation : le coût réel sera plus élevé”.
Si le peintre ou le mécanicien nous le disent suffisamment à temps, on peut choisir de prendre ou non ce travail supplémentaire… et maintenant, trop souvent, on a l’impression de devoir réparer ces choses en plus. Qui voudrait vivre dans une maison avec un mur potentiellement humide ou conduire une voiture avec des freins potentiellement défectueux ?
Comment surmonter cela ? Une réaction commune est d’insister sur une estimation complète, finale et fixe, ou “quotation” comme cela est souvent appelé ; donc ils travaillent plus dur et plus longuement pour obtenir des estimations plus précises. Maintenant, peu importe la façon dont ils travaillent, ils ne peuvent toujours pas vraiment prévoir l’imprévisible.
Dans la vie des projets, c’est la même chose
Traditionnellement, les managers de projets tendent à se focaliser sur la création d’estimations détaillées pouvant supporter le contrôle de l’équipe financière. Bien sûr, cela est basé sur les “connus connus” avec quelques contingences pour les “connus inconnus”... et comme Donald Rumsfeld l’a célèbrement dit “il y a également des inconnus inconnus - il y a des choses que nous ne savons pas que nous ne savons pas”. Comme les spécialistes cités au-dessus, on ne peut jamais vraiment prévoir l’imprévisible.
Cependant, plus on investit dans l’élaboration d’estimations détaillées, plus on cause de problèmes. Les estimations détaillées peuvent être vues comme des devis fermes, une cible qui nous distrait de la production de valeur, et qui nous focalise sur la production de quelque chose - quoi que ce soit même - à la date et au coût prévus.
On se tue à faire des revues post-implémentation, à se dire de juste faire plus d’efforts ; Einstein, cependant, a défini la folie comme “faire la même chose encore et encore en s’attendant à avoir de différents résultats” ; alors il doit y avoir une meilleure solution.
Ce n’est bien sûr pas vrai pour les projets agiles, n’est ce pas? Est-ce que l’on ne commence pas par un périmètre de haut-niveau que l’on retravaille au fur et à mesure ? Et bien, oui et non (ou comme ils diraient en Nouvelle Zélande, “yeah...nah”). Tant que l’on ne se paralyse pas à créer des estimations détaillées, il reste vital d’avoir une idée de la taille du travail à envisager, et voici pourquoi…
Pourquoi on a besoin d’estimations
Oubliez les estimations faites pour construire de jolis diagrammes de Gantt qui nous forcent à nous focaliser sur les tâches, et non sur les résultats. Il y a trois résultats qui ont besoin de nous pour avoir une idée de la taille d’un élément.
- Lorsque l’on considère la justification pour un projet donné, on a besoin de comprendre les possibles coûts en avance, de manière à ce que l’on puisse décider si cela en vaut l’investissement.
- Lorsque l’on lance de nouveaux produits ou des améliorations de produits sur le marché, on a besoin d’avoir une vague idée de quand des fonctionnalités importantes seront prêtes à être livrées, pour que l’on puisse planifier les activités associées.
- Lorsque l’on priorise le travail, le product owner a besoin de comprendre les coûts, et l’équipe a besoin de comprendre la valeur de chaque story (ou élément de backlog).
Il est également intéressant de noter que l’estimation peut être une activité vraiment saine, tant que l’intégralité de l’équipe collabore ensemble à ce sujet. Elle aide à favoriser l’engagement de toute l’équipe et s’assure que tout le monde a une compréhension commune du périmètre et de la valeur à produire.
Cependant le label “d'estimations” peut être gênant.
Utiliser des tailles plutôt que des estimations
Pour éviter d'établir une attente au fait que l’on parle de coût et de temps, lorsque l’on estime la complexité d’une story, certains d’entre-nous aiment se référer à "dimensionnement" plutôt qu’à l’estimation. Dans les années 90, lorsque j’ai utilisé Scrum et XP pour la première fois - avant même qu’ils ne soient appelés des pratiques agiles - on dimensionnait les stories en utilisant les tailles de t-shirts (S, M, L et XL).
Maintenant, cependant, on utilise les story points – une façon de dimensionner les stories relativement les unes par rapport aux autres – alors on définit laquelle sera la plus simple, on la dimensionne à 1 story point, puis on lui compare une autre story, si cette dernière est plus complexe, alors peut être qu’elle sera à 3 story points.
Pour rendre les choses plus intéressantes, on n'utilise pas une séquence simple comme 1, 2, 3, 4, 5, etc. A la place, on utilise une forme modifiée de la suite de Fibonacci comme 1, 2, 3, 5, 8, 13, etc. (comme vu dans "Da Vinci Code"). Cela rend le saut entre les nombres plus grand, le plus haut on va, ce qui nous conduit à choisir celui qui est plus petit ou plus grand.
Bien que ce ne soit pas une science exacte, c’est bien plus que suffisant pour les trois résultats cités ci-dessus, et comme John Maynard Keynes disait : “mieux vaut être vaguement juste, que précisément faux”. Cela signifie, toutefois, que l’on a besoin de traduire les story points en temps et en coût approximatifs.
Une autre pratique centrale aux projets agiles est d’établir la “définition de terminé”, pour avoir une compréhension exhaustive de tout ce qui est nécessaire pour qu’une story soit terminée et livrable, en incluant les éléments comme la documentation utilisateur, la traduction, la publicité, etc. etc.
En considérant que l’on ait une bonne définition de terminé, on peut prendre quelques exemples de stories et calculer l’effort nécessaire. A partir de cela, on peut obtenir des estimations de coût approximatives pour une décision d’investissement, un timing approximatif de planning de release, et une compréhension suffisante pour aider dans la priorisation de stories.
Certains, cependant, trouvent toujours que l’estimation en story points est une distraction, et une réponse à celà a été le débat autour du #NoEstimates.
Alors qu’en est-il du débat #NoEstimates
Si vous avez suivi une des influences majeures sur Twitter, vous avez peut-être remarqué certaines personnes s’impliquer dans des discussions avec le hashtag #NoEstimates. Alors que cela ressemble à un appel à l’arrêt complet de l’estimation, c’est plutôt un appel à l’arrêt du dimensionnement de stories et à la place, de juste commencer à développer.
Cette discussion est apparue, et a pris de l’ampleur car l’expérience de ceux travaillant sur de grands projets était qu'ils dimensionnaient par story points ou qu’ils comptaient juste le nombre de stories, le suivi de la cadence restant sensiblement le même.
Alors que cela semble s’appliquer aux équipes de production les plus expérimentées décomposant leurs stories constamment de plus en plus petit en juste-à-temps — ce qui permet d’avoir un plus grand débit d’incréments potentiellement livrable - le rapport semble similaire même dans les projets qui continuent à travailler avec un éventail de stories de la très petite à la modérément large à chaque itération.
Alors que cela rend la priorisation de story plus simple et permet à l’équipe de production de s’en défaire plus rapidement ; nos pauvres product owners et sponsors ont toujours besoin de savoir approximativement combien cela va coûter et combien de temps cela va prendre. La bonne nouvelle est que l’on peut toujours le savoir en se basant sur le compte de stories, une fois que l’on a suffisamment de métriques pour rendre cela faisable.
Pour toute nouvelle équipe débutant sur votre voyage agile, cependant, je recommanderais tout de même fortement de dimensionner en story points jusqu’à ce que vous atteigniez l’expérience et le niveau de maturité suffisants.
Conclusions
Alors pour résumer, et pour paraphraser la célèbre citation du Général Dwight D. Eisenhower : “En me préparant pour les [projets], j’ai toujours trouvé que les [estimations] étaient inutiles, mais [estimer] est indispensable” ; on a toujours besoin de le faire, peu importe comment on l’appelle et ce que l’on compte lorsqu’on le fait.
Je suis redevable à Esther Derby (les estimations deviennent des cibles), Mike Cohn (les estimations pour le planning de release et la priorisation), Ahmed Sidky (estimation avec toute l’équipe), Martin Fowler (story points), Ian Mitchell (définition de terminé), Vasco Duarte (comptage de stories vs story points), Stephen Forte (métriques vs estimations), Neil Killick (les équipes expérimentées définissent de plus petites stories), parmi tant d’autres, pour avoir partagé leurs réflexions à ce sujet - et j’ai lié leurs articles respectifs aux contextes ci-dessus.
About the Author
David Morris est un praticien indépendant en Business Agility, coach et formateur. Il travaille au sein de sa société Sophorum, propose des analyses business, de la conduite d’équipe, du coaching, et des services de formation à des clients dans toute la Nouvelle Zélande. Avec près de 30 années d’expérience en production de projets, il a travaillé et mené des équipes et lancé son propre business au travers de projets stratégiques, business et techniques suivant des méthodologies structurées, itératives et agiles.
David est CBAP certifié, ICAgile Certified Practitioner, Certifier ScrumMaster et un IT Certified Professional. Il conduit des groupes de travail, des ateliers de développement professionnel et des formations intensives et aide dans l’organisation d’événements pour Agile Auckland et IIBA NZ. Il a parlé à des conférences et événements en Europe et en Australasie, contribué à plusieurs livres (incluant "Extension Agile du BA Body of Knowledge") et est un actif bloggueur, tweeteur et éditeur Wikipedia.