[NCrafts2016] No Estimates : Estimer sans estimer

Une des confs que j’ai préféré à NCrafts 2016 a été celle sur No Estimates par Vasco Duarte. L’estimation : sans doute le sujet le moins sexy du monde, mais où tout le monde se casse les dents quasi-systématiquement depuis l’écriture de la première ligne de code du premier logiciel créé.

De la difficulté à estimer

La problématique est simple : combien de temps va me prendre cette tâche ? Dans certains cas, la réponse est extrêmement simple. Si c’est une action que j’ai déjà effectuée moult fois, que j’ai rodé mon processus, le temps qu’il me faudra est sensiblement le même que la dernière fois, voire un peu moins, puisque je m’améliore en permanence. Sauf que dans l’ingénierie logicielle, c’est foutrement rare. La question de l’incertitude a d’ailleurs été cartographiée par Dave Snowden pour Cynevin :

Liz Koegh en parle très bien dans cet article, mais voici un résumé :

Simple : l’environnement est connu, maîtrisé. J’ai déjà effectué cette tâche plusieurs fois, pas de soucis. Ça me prend X temps. D’ailleurs, si je documente, n’importe qui pourra le faire.

Complicated : je n’ai jamais effectué cette tâche, mais quelqu’un dans mon environnement direct, si. Je me renseigne un peu, je regarde les bonnes pratiques préconisées, je prends un peu de marge et on y va. Je donne une fourchette [X – 1.5X]. Je sais que je peux y arriver, car c’est mon métier.

Complex : cette tâche est possible car quelqu’un l’a déjà faite. Sauf que je ne connais pas cette personne, je n’ai pas accès à elle directement. D’ailleurs, je ne sais pas si l’environnement dans lequel cette personne a exécuté la tâche est compatible avec le mien. Je n’ai donc pas de garantie de pouvoir mener ma tâche jusqu’au bout. Je vais donc privilégier une approche de type PoC. J’alloue un temps de X, et je regarde où ça me mène. J’analyse, je réoriente au besoin et je répète jusqu’à obtenir un gage de faisabilité.

Chaotic : il y a le feu à la maison. Gros bug de prod. Je stoppe l’hémorragie, je colmate les brèches, et j’analyse plus tard ce qui c’est passé. On essaye d’éviter cette catégorie autant que possible, les enfants.

Disorder : je ne sais pas où je me trouve. Ce serait bien de corriger ça.

Notez également que les choses simples peuvent devenir chaotiques si on perd le contrôle. Et que les choses complexes peuvent venir compliquées ou chaotiques, selon l’évolution des événements.

En ingénierie logicielle, on se trouve l’immense majorité du temps dans les zones compliquées et complexes. Sauf qu’on a souvent l’impression d’être dans la zone simple. C’est faux. Ajoutons à ça qu’on aime se rajouter des inconnues . “Oh, et si j’utilisais ce nouveau framework en beta ? J’ai lu sur le blog de Grokador que c’était vachement bien. Puis mon appli marchera beaucoup mieux avec un bus et un EventStore plutôt que d’écrire directement en base.” (Toute ressemblance avec une situation réelle ne serait que purement fortuite) Liz Koegh le dit très bien, d’ailleurs :

I have a theory that most devs get really bored by doing the same predictable but complicated thing over and over again. We tend to turn it into open-source or automate it, reducing it to the far smaller but more complex problem of how to do the automation or use the open-source. Devs are drawn to complexity like moths to a bonfire. And we make it when we don’t have it…

Tout ceci fait qu’on a toujours autant de mal à estimer. Débutant, confirmé, expert, vieux routard, on se plante tous. Souvent. Et même les très très bons galèrent aussi. Regardez Microsoft et .NET Core. Le scope bouge en permanence, les dates aussi. Difficile pour eux comme pour nous développeurs. Et pourtant, ce n’est pas comme si personne ne s’était intéressé au sujet. Certains en sont même devenus riches.

Mais… je vais guérir, docteur ?

Ecoutez, c’est une excellente question, Thérèse. Et vous remercie de l’avoir posée. Ce bon Vasco Duarte part de deux constats implacables :

• on passe un temps fou à chiffrer
• on y est nuls

Il a aussi analysé un nombre très conséquent de projets, de taillées et durées variables et a confronté les estimations avec la durée réelle des tâches. Première constatation : on est nuls. Ce a quoi on a envie de lui répondre : “Oui, bah hein bon… Ca va, Vasco. Bon…” Faut pas nous chercher, quand même. On a de la répartie dans le milieu.

Et pourtant, avec l’agilité, on avait l’impression d’avoir fait des progrès. On sait que le cerveau humain est fondamentalement mauvais pour estimer du temps. Mettez 10 humains dans une pièce sans montre ou horloge pendant une heure et demandez-leur depuis combien de temps ils y sont, vous aurez 10 réponses différentes. Et de toute façon, une tâche ne prend pas le même temps selon à qui elle incombe. Bref, on sait que chiffrer en jours/homme n’a pas de sens. Et pourtant, on le fait encore.

En revanche, on sait que le cerveau est bon pour comparer les choses. Il sait très bien dire que A est plus petit ou plus grand que B,  d’où le chiffrage en points de complexité du Planning Poker. Le problème est ici de comparer des choux et des carottes. Est-ce que développer cet écran de visualisation de mes commandes est plus complexe que développer mon service qui envoie mes commandes vers le CRM ? Et puis ce que veut le management, c’est une projection en temps pour savoir quand est-ce qu’on atterrit. Donc on fait des règles de 3 pour convertir complexité en temps. Bref avec les points de complexité, on est moins nuls, mais on est nuls quand même.

Autre constat intéressant : on sait très bien que le cerveau humain est mono-tâche et qu’il peine à basculer d’un contexte à un autre. Le développeur – tout comme n’importe quel être humain – sait qu’il lui sera plus compliqué en deux semaines d’abattre 20 tâches d’une demi-journée qu’une tâche de 2 semaines. L’idée n’est pas d’aller à l’encontre du découpage de gros blocs complexes en petits blocs faciles et rapides à emmener en production (coucou Kanban !). Au contraire. L’idée est de tenir compte de la difficulté à basculer fréquemment d’un contexte à un autre. D’expérience, on arrive d’ailleurs assez naturellement à la conclusion que l’on est le plus productif en travaillant sur des tâches découpées assez finement mais toutes situées dans un même contexte.

Sur un de mes derniers projets, on constatait également les choses suivantes :

• • on passait un temps fou en séances de chiffrage (facilement 3h par semaine, soit plus que le temps passé en planif + démo + rétro)
  • on tenait compte du nombre de User Stories pour définir le scope du sprint
  • les User Stories techniques – donc écrites par les devs eux-mêmes – étaient très (trop) souvent découpées horizontalement : par couche technique.
  • les Users Stories fonctionnelles écrites par les proxy-product owners étaient très souvent de mauvaise qualité : interdépendantes, orientées “technique” ou IHM plutôt que du point de vue de l’utilisateur

Et on arrive donc à la problématique centrale du chiffrage : le truc à chiffrer. Dans un projet agile, on a souvent un Backlog. Mais force est de constater qu’il est rarement de bonne qualité. Multiples points d’entrée, entraînant une priorisation difficile et par effet de bord des projets menés en parallèles et donc des changements de contexte fréquents, ou encore un mauvais découpage fonctionnel, pas de critères d’acceptance, des choix techniques induits… Mais alors que nous propose No Estimates ?

No Estimates

No Estimates n’est pas un mouvement nihiliste consistant à jeter au feu l’idée de se projeter dans le futur parce que c’est compliqué. No Estimates est un mouvement né des constatations susmentionnées et de deux lois :

Hofstadter’s  Law:  It  always  takes  longer  than  you  expect,  even  when  you  take  into  account   Hofstadter’s  Law.   —  Douglas  Hofstadter

Work  expands  so  as  to  fill  the  time  available  for  its  completion —  Parkinson’s  Law

Le Chaos Report nous enseigne que le taux de succès des projets informatiques évolue relativement peu dans le temps. Même si l’agilité aide en ce sens. Et la définition d’une bonne estimation, définie en 1986 (1986 !), reste toujours aujourd’hui d’actualité :

A good estimation approach should provide estimates that are within 25% of the actual results 75% of the time (Conte, Dunsmore, and Shen, 1986)

Imaginez, vous estimez un projet à 100. S’il coûte en réalité entre 75 et 125 et que vous avez raison 75% du temps, vous faites de bonnes estimations. Et après, on se plaint de Météo France…

Rajoutez le fait que dans bien des cas, les estimations deviennent des engagements, et vous commencez à saisir l’ampleur du problème.

Duarte cite 4 situations qui rendent les estimations nuisibles (en plus d’être probablement erronées, donc) :

• Les politiques internes : quand le management s’engage sur des dates et/ou un scope. Dans ce cas, le HIPPO (Highest Paid Person’s Opinion) l’emporte sur toute estimation effectuée par l’équipe.
• Quand il y a négociation sur les estimations par des personnes externes à l’équipe de développement, à des fins commerciales par exemple.
• Lorsque les estimations sont effectuées par des personnes qui ne participent pas au projet. Et qu’on blâmera l’équipe pour n’avoir pas tenu les engagements d’autrui.
• Lorsque le scope change, sans que les estimations puissent évoluer avec. Forcément, ça a l’air stupide. Et pourtant, ça arrive. Souvent.

Notez que ces situations peuvent parfaitement se cumuler.

Mais donc… comment on fait ?

Oh, merci encore Thérèse de poser la question. Ça me fait une excellente transition. Une bonne chose à faire est pour commencer de poser la question différemment. “Quand est-ce que le projet va se terminer ?” est une mauvaise question, car elle dépend de trop de facteurs : le scope, l’équipe, sa productivité et tous les aléas qu’on peut rencontrer. En revanche, il y a des questions qui ont du sens : “Si on avance au même rythme qu’à l’heure actuelle, combien de temps cela nous prendra-t-il pour abattre le travail restant ?” Ou son corollaire : “Si on avance au même rythme, où en serons-nous à la date X ?”

Plusieurs différences majeures avec la première question :

• on ne fige plus le scope et la date de livraison simultanément
• on se base sur le passé et des métriques quantifiables
• on corrèle la réponse à la question avec la stabilité de l’environnement (“si on avance au même rythme”)

Et pour répondre à ces deux questions, on ne joue plus au devin. On s’appuie sur des données empiriques : le passé de l’équipe. L’avantage qu’on a avec les projets modernes, est qu’on a à notre disposition tout un tas de données sur lesquelles s’appuyer. Si on utilise correctement nos outils de gestion de projet, on peut assez facilement savoir plein de choses sur une User Story : quand elle rentre dans le système, quand elle en sort, combien de temps elle a réellement pris à être développée, qui a travaillé dessus, les anomalies liées…

Et c’est là que Vasco Duarte a commencé à remonter des données intéressantes. Comme mentionné plus haut, il a analysé un nombre assez colossal de projets et a pu en dégager des conclusions pour le moins intéressantes. Il a noté que le nombre de User Stories était plus fortement corrélé à l’avancement du projet que l’estimation de ces User Stories. Un exemple est assez frappant. Sur un projet durant au total 50 sprints :

• au bout de 3 sprints, le delta entre réalité vs estimation est de 20%, alors qu’il aurait été de seulement 4% si l’équipe s’était appuyée uniquement sur le nombre d’US
• au bout de 5 sprints, le delta réalité vs estimation tombe à 13%, alors qu’il est toujours de 4% quand on compare avec le nombre d’US.

Plus on avance dans le projet, plus cet écart se réduit, mais d’après Duarte, dans l’immense majorité des cas, le nombre d’US donne une projection plus proche de la réalité que l’estimation. Vu le temps et l’énergie que l’on peut consacrer au chiffrage, ça peut mettre un coup au moral. J’ai fait l’exercice de mon côté avec les quelques données que j’avais sous la main, et sans aller très loin, j’ai effectivement l’impression que mes prévisions auraient été plus fiables en me basant uniquement sur le nombre de User Stories.

Et c’est ça, No Estimates. La projection basée uniquement sur le nombre de User Stories.

Évidemment, rien n’est garanti. Duarte nous dit qu’un certain nombre de paramètres rendent la méthode plus fiable. D’une part, il est primordial de respecter le “I”, le “V” et le “S” de INVEST. Et par magie, on renverse la responsabilité de la fiabilité de la projection sur le Product Owner, le proxy PO ou toute personne maintenant le Backlog. Ce point peut être extrêmement difficile à mettre en œuvre, mais il a le mérite de mettre l’accent sur la qualité du Backlog, qui devrait être la colonne vertébrale du projet quoi qu’il arrive. Un mauvais Backlog entraîne mécaniquement un mauvais projet et un mauvais logiciel. Ce point de vue est également parfaitement compatible avec Kanban, qui prône des User Stories les plus petites et les plus homogènes possibles.

Dernier point encouragé par Vasco Duarte : expérimentez ! L’Agilité en a fait un point central. On entend souvent “fail fast fail often” (heureusement qu’on est pas chirurgiens). L’échec n’est pas un objectif, mais on favorise l’expérimentation. Pareil ici. On sait qu’on n’estime pas bien les projets, autant tenter autre chose.

CI-DESSOUS LE REPLAY DE CETTE SESSION :