Esti­ma­tion is evil

Peut être est-ce du à mon inca­pa­cité flagrante à sortir de bonne esti­ma­tions, mais je suis convaincu que l’exer­cice est des plus nocifs. Je conçois le déve­lop­pe­ment comme une acti­vité créa­tive, avec des problèmes qui sont large­ment incon­nus et des besoins qui sont à peine effleu­rés.

Esti­ma­tion is evil, chez prag­prog.

Soit on fait semblant, soit on accepte que les esti­ma­tions soient en perma­nence fausses, soit on tient les esti­ma­tions. La dernière option implique forcé­ment une astuce bien connue : c’est la qualité qui trinque. C’est l’op­tion des SSII, mais elle me parait diffi­ci­le­ment tenable en interne à une société.

Le problème c’est que le busi­ness a besoin d’avoir des dates et de les commu­niquer. Passer du « produire ce qu’on vend » au « vendre ce qu’on produit » est loin d’être simple. L’équi­libre du néces­saire compro­mis est parfois diffi­cile à trou­ver.

Rejoindre la conversation

2 commentaires

  1. Ce n’est pas le principe de l’estimation qui est faux, c’est que ce qu’on estime qui est faux. Tu es à peu près capable d’estimer combien de temps il faut pour écrire une ligne de code qui fait une boîte avec un fond rouge, car c’est 1. mesurable, 2. répétable à l’envie en grand nombre afin d’obtenir une probabilité 3. et être assujetti d’une marge d’erreurs.

    Là où l’estimation des projets Web marche sur la tête, c’est que c’est vendu comme une quantité mesurable et contractuelle (nombre d’heures, etc) alors que ce n’est justement pas mesurable à cause de la complexité des interactions. Cela ressemble à la thermodynamique si tu préfères. Si tu étudies au niveau atomique, tu peux étudier des propriétés précises, au niveau macroscopique ce n’est pas possible d’utiliser les mêmes outils.

    Cela ne te donne pas une solution bien sûr mais on est d’accord que toute l’industrie ment aux clients et se ment elle-même. Que fait-on ? Plutôt que d’évaluer le coût comme une valeur mesurable, on devrait estimer le risque associé au coût TOUT en minimisant la taille des enveloppes de chaque estimation. Prendre un risque sur une journée, n’est pas la même chose que sur 6 mois. D’où les méthodes « agiles » pour limiter les scénarios d’amplification des pertubations que tu as dans les systèmes complexes.

  2. Il n’y a pas que dans les projets web que l’estimation est délicate, voir imposible.

    Si on dit qu’un développement dure 4 jours, y’a des chances pour qu’il ne soit jamais réalisé en 2, alors que sans estimation, la même série de tâches pourrait très bien être livré plus rapidement.

    Cela fait quelques temps que je n’estime plus. Ou alors au hasard. Je préfère me focaliser sur apporter le maximum de valeur dans le moins de temps possible (de l’ordre de 2 heures à une journée grand max). Ensuite on peut estimer la faisabilité d’une série de fonctionnalité en regardant l’existant. C’est la vélocité en scrum, mais on peut aussi utilisé le « cumulative workflow diagram » utilisé dans le lean software development.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.