Cet article fait écho à ce que j’ai pu lire ça et là sur le sujet des estimations dernièrement. Les avis divergent et sont intéressants, il y a un vrai débat. Je trouve ça cool et je voulais apporter ma vision sur le sujet.
Il y a quelques années, j’étais fervent défenseur du #NoEstimate et probablement pour de bonnes raisons. La principale était la fâcheuse tendance que l’on peut rencontrer dans des métiers dits “produits” ou “commerciaux” à prendre ces estimations comme des deadlines. J’y reviendrais plus tard.
Que l’on mette les choses au clair tout de suite. Une estimation, par essence, est fausse. On oppose d’ailleurs le terme à quelque chose qui a été mesuré avec précision. Elle est basée au mieux sur un modèle, une représentation que l’on a pu faire d’un besoin fonctionnel ou technique. Ce besoin a été spécifié (a minima par oral) mais on ne le répètera jamais assez, la seule spécification suffisamment précise pour couvrir l’intégralité des possibilités, c’est le code. Toute autre spécification est sujete à l’interprétation de la personne qui va l’implémenter.
Sur cette base, et étant donnée la complexité des outils informatiques, il n’est pas possible de donner une prévision juste et précise du temps nécessaire à un développement. L’expertise permet d’affiner les estimations en anticipant les points sensibles, mais elles restent un exercice incertain.
“Les estimations sont par définition fausses, mais elles sont nécessaires.”
Quand Alfred m’a dit ça pour la première fois, ça a été comme une illumination. Son propos était basé sur le fait que le plus important dans une estimation ça n’est pas sa valeur absolue, mais relative.
Il existe plusieurs façons d’estimer la charge d’une tache. Cela peut être sous forme de temps évidemment, mais aussi de complexité ou d’effort de réalisation … et soyons honnête, quelle que soit la valeur estimée, le cerveau fait naturellement la pirouette de l’ancrer dans quelque chose qu’il est capable de quantifier concrètement : le temps (de façon plus ou moins approximative).
Finalement la forme de l’estimation importe peu, le plus important est surtout de pouvoir la comparer aux autres.
L’informatique comme tout domaine basé sur l’ingénierie est un métier de compromis, il faut savoir faire des choix. Et c’est la relativité de ces évaluations qui va être un élément crucial dans la prise d’une bonne décision (par exemple avec des outils comme la matrice valeur/effort).
Les estimations sont donc un outil d’aide à la décision très efficace pour définir des priorités.
Je parlais en introduction de la tendance à prendre ces estimations comme des deadlines, en utilisant volontairement le terme fâcheuse et en parlant de métiers dits “produits” ou “commerciaux”.
C’était mon raisonnement en tant que développeur. Car du point de vu opérationnel, si les estimations sont interprétées comme des deadlines, elles deviennent des obligations sources de stress. C’est vrai dans le cas où l’on a soit même estimé la tache, car elle devient un engagement. Mais ça l’est également quand l’estimation vient d’une autre personne de l’équipe, particulièrement si elle est plus plus expérimentée, car on risque alors de ne pas se sentir à la hauteur si l’on dépasse la charge initialement prévue.
Mais si l’on fait l’effort de changer de point de vue, il y a plusieurs métiers où cette estimation devient un outil précieux. C’est par exemple le cas dans le marketing lorsque l’on doit mettre en place un plan de communication. Si un projet fait intervenir différentes personnes, particulièrement quand elles sont externes (prestataires, partenaires …) il est également important d’avoir de la visibilité sur les moments où ces gens seront sollicités.
Ce sont les premiers exemples qui me viennent, mais en cherchant un peu on trouve facilement des cas où l’on ne peut simplement pas travailler sur un produit en se basant sur des “Ben ça sera prêt quand ça sera prêt”. Aussi complexe ou fausse que soit l’estimation, elle est nécessaire à plusieurs corps de métier.
Il y a pourtant des entreprises qui réussissent à fonctionner sans estimation. C’est le cas par exemple de Basecamp, célèbre sur pas mal de plan pour sa façon de travailler. Leur méthode de travail est simple : quelle que soit la tache ou le projet, tout est planifié dans des timebox de 6 semaines. A la fin de cette période, soit on livre, soit on jette.
Mais si on regarde de plus près, choisir ce qui rentrera dans ces espaces de 6 semaines passe forcément par une phase d’estimation de temps. Pas forcément avec précision, mais les taches et/ou projets ne sont pas choisis au hasard.
Ce qui est innovant et important à souligner, c’est la façon qu’à Basecamp de gérer la différence entre estimations et charge réelle. Ils sont capables de jeter 6 semaines de travail si l’estimation s’est avérée fausse, là où beaucoup d’entreprises peuvent mettre la main dans l’engrenage et parfois quadrupler le temps initialement estimé.
Ce dépassement d’estimation est un comportement aussi normal qu’irrationnel, il a même été théorisé par les sciences comportementales. C’est ce qui fait que les méthodes à la Basecamp demandent un recul et une maturité d’équipe assez peu communs.
Au final, le temps n’est pas un élément dont on peut se dédouaner dans nos métiers, et si en tant que développeur·euse on aimerait pouvoir avancer sans cette contrainte et le stress qu’elle apporte, c’est un besoin à mon sens très égocentrique par rapport à l’ensemble de la production logicielle. Ce que nous apprennent les différents exemples, c’est que le mieux que l’on puisse faire c’est de travailler sur la gestion de l’incertitude et notamment du plan d’action lorsque l’on s’écarte de l’objectif.
Medhi parle de chaos dans le monde du développement et il a raison. Il ne faut pas nier ce chaos, nous travaillons dans un domaine trop complexe pour être intégralement compris par un petit groupe de cerveaux humains. Il faut également chercher à gérer ce chaos et ses conséquences, plutôt que de l’utiliser comme une excuse pour se dédouaner des ses propres responsabilités.