Le problème avec les mots, c’est que chacun peut en avoir sa propre définition. Donc il est parfois difficile de se comprendre, à fortiori lorsqu’il s’agit d’un mot‑clé qui apparu sur les réseaux sociaux (notamment sous l’impulsion de Woody Zuill et Vasco Duarte).
Qu’est‑ce qu’une estimation dans le développement logiciel ? Il s’agit de prédire le coût ou le délai pour une fonctionnalité ou un groupe de fonctionnalités. Par exemple, cette fonctionnalité A va coûter tant et sera terminée à telle date. Donc il ne s’agit pas de toutes les acceptations du terme « estimation ». Si nous disons : « J’estime que cela est risqué », au sens de « je pense que cela est risqué », nous ne sommes pas dans le contexte précédemment décrit.
Photo : Nicolas Éliard
Une première définition régulièrement partagée est que, lorsque l’on fait du #noEstimates, nous faisons quand même des estimations. Mais comme nous savons qu’elles sont fausses, nous leur accordons peu d’importance. Cette définition est problématique. Si une compote sans sucre ajouté contient des sucres ajoutés, c’est une escroquerie. Si un cosmétique sans parabène contient des parabènes, c’est une escroquerie. Donc, si nous revendiquons que nous ne faisons pas d’estimation, alors que nous en faisons… Et pourquoi revendiquer le #noEstimates alors que nous faisons des estimations ? Autant assumer que nous faisons des estimations.
La deuxième approche est celle qui est, par exemple, mise en avant par Jean-Christophe Pages 🧢. Le constat étant que les estimations sont (très) fausses, nous allons arrêter d’en réaliser et nous appuyer sur la mesure du passé pour réaliser des projections du futur. Par exemple, depuis le début de l’année, nous avons réalisé une mise à jour chaque semaine, avec 4 à 6 fonctionnalités par semaine. Donc nous projetons livrer 5 fonctionnalités en moyenne par semaine. Cette approche est cohérente. Il n’y a plus d’estimation, avec le gain de temps et de rationalité associé.
La troisième approche, que je partage avec Rudy Onfroy notamment, est de ne plus chercher à prévoir le futur du tout. C’est‑à‑dire se poser la question : « Quels usages faisons‑nous de la prédiction du futur actuellement ? » et, pour chacun de ces usages, développer une alternative. Par exemple, nous utilisons la prédiction du futur pour communiquer auprès de nos utilisateurs ? L’alternative, dans ce cas, est de communiquer au moment de la livraison, et non avant.
Bien entendu, cette dernière approche donne le vertige tant elle est contre‑intuitive. Nous utilisons tellement la prédiction du futur (pour vendre, pour contractualiser, pour réaliser un budget, pour prioriser, pour synchroniser des équipes…) que travailler dans un pur fonctionnement adaptatif nous paraît être une utopie. Et pourtant, en se donnant le temps de la réflexion, c’est tout à fait accessible.