De la tartine qui tombe du côté de la confiture, au chiffrage par points des projets Agile

Les tartines tombent toujours du côté de la confiture, c’est bien connu, et même démontré scientifiquement (pour être précis, à 60% nous disent les chercheurs qui cherchent sur les sujets sérieux). Question de hauteur de table…

C’est la fameuse loi de Murphy : « Anything that can go wrong, will go wrong » et de ses corollaires :

1. Nothing is as easy as it looks

2. Everything takes longer than you think

3. If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong

4. If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way will promptly develop

5. Left to themselves, things tend to go from bad to worse

6. Whenever you set out to do something, something else must be done first

7. Every solution breeds new problems

8. It is impossible to make anything foolproof because fools are so ingenious

9. Nature always sides with the hidden flaw

10. Mother nature is a bitch

Si cette loi est devenue aussi populaire chez les ingénieurs, c’est que Murphy étant physicien, il s’agaçait que ses expériences ne se terminent pas en temps et en heure, ses appareils de mesure ne fonctionnant pas comme il le souhaitait. Ces lois humoristiques ont donc un petit air de déjà vu pour tout ingénieur, et encore plus les informaticiens que nous sommes. Estimer les délais dans la tech est particulièrement ardu. L’homme construit des ponts depuis 4 000 ans et ils ne sont pas toujours livrés en temps et en heure. L’informatique moderne a démarré dans les années 1970, il y a cinquante ans. Avec 80 fois moins d’expérience, on ne va pas faire des miracles. Mais on peut essayer 😊.

Quel est le problème ? Par définition, je ne sais pas ce que je ne sais pas. Hors comment chiffre-t-on un projet traditionnellement ? Depuis Le discours de la méthode de Descartes, on décompose les projets en éléments simples, jusqu’à arriver à l’élément unitaire simple que l’on chiffre et l’on remonte de la tâche simple au projet complexe. Pour laisser parler le maître : « Le second [principe est], de diviser chacune des difficultés que j’examinerais, en autant de parcelles qu’il se pourrait, et qu’il serait requis pour les mieux résoudre.

Le troisième, de conduire par ordre mes pensées, en commençant par les objets les plus simples et les plus aisés à connaître, pour monter peu à peu, comme par degrés, jusques à la connaissance des plus composés; et supposant même de l’ordre entre ceux qui ne se précèdent point naturellement les uns les autres. »

L’inconvénient du discours de la méthode est subtilement glissé dans le dernier principe :

« Et le dernier, de faire partout des dénombrements si entiers, et des revues si générales, que je fusse assuré de ne rien omettre. » Ne rien omettre ! Ne rien omettre, c’est être capable d’appréhender le tout dans sa globalité. Le monde étant infini, un tel être capable de ne rien omettre n’est pas très loin de la définition de Dieu par les philosophes… bon courage !

Si Descartes était avant tout un grand mystique, nous autres informaticiens avons des considérations plus prosaïques : estimer la durée de nos projets alors que nous sommes dans l’incapacité « de ne rien omettre », que notre cerveau à une CPU et une bande passante limitée et que nous sommes dans l’incapacité ne serait-ce que de comprendre dans sa globalité l’un des sous sous composants que nous utilisons quotidiennement comme une base de données, un serveur web, un réseau internet, etc…

Et donc une estimation de la durée de nos projets selon une décomposition en éléments simples est un exercice terriblement périlleux : je ne sais pas ce que je ne sais pas, et quelque part, ça va merder, la tartine va tomber du côté de la confiture, forcément, et je vais passer deux jours à comprendre que si mon code tourne sur ma machine et pas en production, c’est parce que la base de données de développement tourne avec la version de mysql 5.7 alors que celle de production est en version 5.8 et que le moteur de recherche regex ne renvoie pas exactement les mêmes résultats dans les deux cas. Je laisse au lecteur le soin d’ajuster les variantes possibles ad nauseam en fonction de ce qu’il aura codé la veille...

C’est ainsi les livraisons des équipes techs deviennent un rituel sacré où, en lieu et place de livrer le produit, on explique pourquoi on a pas pu livrer. Telle une tragédie grecque, le héros part au inlassablement au combat, il lutte, mais l’échec est certain. « Il faut imaginer Sisyphe heureux » nous dit Camus en référence au fondateur de Corinthe condamné pour l’éternité à pousser une pierre au sommet d’une montagne, d’où elle finit toujours par retomber. Pas très enthousiasmant…

Si cette approche de décomposition en élément simple à des vertus, comment échapper à la damnation associée ?

Grâce à un des grands théorème geek : « All problems in computer science can be solved by another level of indirection, » de Butler Lampson, le scientifique qui en 1972 a le premier envisagé l’ère du Personnal Computing (PC)

Le principe est le suivant : Au lieu de décomposer les tâches en heures, on va les chiffrer sur la base de tâches comparables en appelant ‘point’ le temps nécessaire à la tâche comparable la plus simple. (Niveau d’indirection).

Un exemple : combien de temps pour construire un pont ? Et bien je peux décomposer la construction d’un pont en une multitude de tâches et sous tâches et chiffrer chacune d’entre elles, de la conception du ciment, au cablage, etc… Le processus d’estimation devient lui-même très long. Chez Vizzit, en début des releases trimestrielles, il a pu arriver que les équipes tech disparaissent pendant une semaine en improductif pour évaluer chaque code et avoir un chiffrage de toute la release. Ceci crée une illusion de maîtrise qui vole en éclat au premier composant qui ne marche pas comme il devrait.

Or, une autre manière pour estimer combien de temps cela va me prendre de construire un pont, c’est tout simplement de regarder combien de temps cela m’a pris de construire un pont à peu près similaire. Et c’est tout.

Cette méthode par comparable intègre naturellement toute la liste des infinis détails que je ne connais pas et tous les problèmes qui ne manqueront pas de surgir. Premier avantage, ma date est plus fiable pour les clients internes ou externes. Deuxième avantage, l’ambiance est plus positive et plus saine dans une équipe où l’on termine à peu près en temps et en heure que dans une équipe où l’on passe son temps à expliquer pourquoi on a pas réussi.

Attention néanmoins. La notion de points correspond quoi qu’il arrive à du temps passé. L’erreur serait de juste parler de ‘points’ au lieu « d’heures ». En effet, le théorème geek complet sur l’indirection est : « All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection » Rajouter couche d’abstractions sur couches d’abstractions n’a d’intérêt que pour ceux qui aiment rajouter de la complexité intellectuelle pour se faire plaisir. Le risque de parler de points au lieu d’heures, est de réouvrir les discussions médiévales sur le sexe des anges : rien de tel qu’un concept qui n’a plus aucune référence concrète dans notre bas monde pour pouvoir ensuite en débattre une vie durant. Et quel plaisir infini que d’expliquer aux autres qu’ils ont tort et que j’ai raison sans pouvoir être réellement contredit !

Mais chez Vizzit, nous avons l’ambition d’être utile. Et donc la notion de « points » n’a de sens dans cette méthode qu’avec la notion de « tâches comparables ». L’expression «j’estime cette tâche à 3 points » n’est donc qu’une formulation raccourcie à utiliser pour : « je suis capable de faire 20 formulaires web en 10 jours, et ce projet a la complexité de 3 formulaires web, j’estime donc cette tâche à 3 points sur une capacité de 20 ».

Qu’est-ce qui a changé alors avec les points ? J’ai isolé la difficulté à un endroit où elle sera plus facile à traiter. L’idée sous-jacente est que comparer ma tâche à une autre tâche est facile. Il n’y a rien qui ressemble plus à un formulaire web qu’un formulaire web, un pont à un pont, etc… et la difficulté de l’estimation est repoussé dans le terme « je suis capable de faire 20 formulaires web en 10 jours ». Ca on a pas à s’en soucier quand on fait une estimation en point. C’est l’expérience qui nous le dira. Le geek n’a plus qu’à comparer la proximité de la tâche par rapport à des tâches existantes, avec un risque d’erreur faible dans la comparaison. C’est au gestionnaire de projet ou « ScrumMaster » de s’appuyer sur l’expérience des comparables pour savoir combien de temps cela va prendre.

Quel est l’avantage de la méthode ? Dans la tech, chaque tâche peut partir fortement en cacahuète. Le problème n’est pas que nous techos sous-estimions régulièrement de 10% chaque tâche. Le problème est qu’on estime correctement chaque tâche, mais qu’une tâche va prendre 10 fois plus de temps que prévu parce que l’outil sous-jacent ne fonctionne pas comme espéré. Ex : « Pas de chance, la gestion de formulaire ne traite que des dates au format américain, et nous sommes français donc il faut introduire la gestion de la langue utilisateur dans toute notre conception de site. » Bingo ! Rajouter un champs vient de passer de 10 minute à 1 semaine…

Sauf que si, isolée, la mesure de la tâche est par nature erronée, statistiquement, les merdes volent en escadrille. Et donc le chef de projet peut constater qu’effectivement, en 5 jours le développeur à fait 9 formulaires, mais qu’il a pris 5 jours pour faire le dixième. Et donc le gestionnaire de projet ajuste la capacité de l’affirmation « je suis capable de faire 20 formulaires web en 10 jours » à « statistiquement un développeur fait 10 formulaires web en 10 jours ». En terminologie Agile, la capacité est ajustée de 20 points à 10 points à la fin du sprint.

Le développeur a ainsi raison d’estimer, avec le niveau d’information dont il dispose à priori, que d’évaluer le temps de réalisation du nouveau formulaire au temps de réalisation d’un ancien formulaire. Et l’erreur est lissée statistiquement en ajustant la capacité sur l’équipe.

En conclusion :

La méthode d’estimation par comparables peut avantageusement se substituer ou compléter une méthode d’estimation par décomposition en éléments simples dans les projets comportant le risque élevé que quelques tâches soient très fortement sous estimées.

Attention à ne pas juste changer le vocabulaire et créer une couche d’opacité en remplaçant simplement la notion d’heures par une notion de points. L’enjeux est de construire une vraie base de comparables.

Il faut aussi être vigilant à ce que le développeur ait un feedback régulier. Notamment, vu que l’on prévoit du temps à consacrer aux tâches qui s’avèrent ardues à l’implémentation, le risque est accru que le développeur passe beaucoup de temps sur cette difficulté alors qu’un contournement technique existe ou qu’un ajustement métier est possible (ex : « la date de naissance, je l’ai demandé, mais je n’en ai pas vraiment besoin, si ça te prend plus de 10 mn, mets moi l’âge à la place »). Si l’estimation par comparable a des vertus, la fluidité de la communication entre le besoin métier et la technique reste central et aucune technique d’estimation ne remplacera totalement un dialogue constructif visant l’enchantement du client.