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.
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.
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.