Estimation is evil

Peut être est-ce du à mon incapacité flagrante à sortir de bonne estimations, mais je suis convaincu que l’exercice est des plus nocifs. Je conçois le développement comme une activité créative, avec des problèmes qui sont largement inconnus et des besoins qui sont à peine effleurés.

Estimation is evil, chez pragprog.

Soit on fait semblant, soit on accepte que les estimations soient en permanence fausses, soit on tient les estimations. La dernière option implique forcément une astuce bien connue : c’est la qualité qui trinque. C’est l’option des SSII, mais elle me parait difficilement tenable en interne à une société.

Le problème c’est que le business a besoin d’avoir des dates et de les communiquer. Passer du « produire ce qu’on vend » au « vendre ce qu’on produit » est loin d’être simple. L’équilibre du nécessaire compromis est parfois difficile à trouver.

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 OVH SAS, joignable par téléphone au +33 (0)9 72 10 10 07 et dont le siège social est au 2 rue Kellermann, 59100 Roubaix, France.