Carnet de notes

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.

Publié

dans

,

par

Éric

Étiquettes :

Commentaires

2 réponses à “Esti­ma­tion is evil”

  1. Avatar de karl
    karl

    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.

    Répondre
  2. Avatar de Yannick
    Yannick

    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.

    Répondre

Laisser un commentaire

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