Dan Milstein, développeur et cofondateur du groupe de consulting Hut 8 Labs nous raconte dans un billet de blog comment lors de sa jeunesse il avait pensé pouvoir finir un projet en 3 semaines alors que ça lui a pris 3 mois au final. Plusieurs années plus tard, il se rendra compte qu’il faisait encore et encore des erreurs lors de l’estimation des délais, et ceci est le cas aussi pour tous les autres développeurs selon lui.Du point de vue de Milstein, il y a plusieurs raisons qui font qu’on se trompe toujours lors des estimations : la première est que « l'écriture d’un logiciel implique de comprendre quelque chose avec une telle précision que vous pouvez dire à un ordinateur exactement comment le faire ». Cependant, « si vous comprenez quelque chose, vous avez déjà une bibliothèque ou un morceau de logiciel existant qui fait cette chose […] Sinon, il existe une incertitude » et cette incertitude a une grande probabilité de finir dans un problème ; or le temps nécessaire pour le résoudre peut varier de quelques heures à plusieurs mois, voire même plusieurs années.
Dan Milstein explique ensuite que même si on fait en sorte de bien cerner le problème et de tout couvrir dans la phase de spécifications, il faut les écrire dans un tel détail que « vous serez au final en train d’écrire le logiciel » en lui-même.
Nos estimations en termes de temps d’accomplissement d’un projet sont donc toutes erronées selon son billet de blog, et ceci est causé par un phénomène très connu en psychologie, explique Milstein : la « surestime ». Toutefois, ceci n’est pas la seule raison ; « le vrai trouble vient de la fusion entre les deux sources d’erreurs d’estimation : le biais humain envers la surestime, et l’incertitude incluse dans n’importe quel projet logiciel », et cette incertitude est « si sévère » que même si on analyse bien le problème et qu’on y réfléchit lentement, nous ne pourrons toujours pas apporter d’estimations réalistes.
Selon les études psychologiques résumées dans le livre « Thinking, Fast and Slow » de Daniel Kahneman, combinées à ses propres observations dans le domaine professionnel, l’auteur du blog affirme que les humains ne sont pas doués pour les estimations à long et à moyen terme, mais peuvent devenir des experts dans l’estimation à très court terme. « L’équipe avec la plus haute vélocité dont j’ai fait partie faisait des sprints d’une durée d’une semaine, et divisait chaque tâche sur la base de 0, 2, 4, ou 8 heures (et il y avait toujours une certaine suspicion pour celles de 8 heures) », déclare Dan Milstein. « Nous estimions ces délais très rapidement et parfois un peu au hasard, nous n’utilisions même pas de formalisme du style Planning Poker », continue-t-il. Il ajoute que la courte longueur des sprints jouait un rôle important puisqu’elle permettait d’obtenir un retour très rapide sur la qualité des estimations.
Toutefois, cela ne marche que sur le court terme, rappelle l’auteur de l’article, car même si on divise nos tâches sur la base de 4 heures chacune, elles prendront toujours du retard si on en planifie plusieurs d’affilée sur plusieurs semaines à l’avance ; « en termes mathématiques, je soupçonne que le temps suive une distribution en loi de puissance. Et, les distributions en loi de puissance sont connues pour ne pas avoir une moyenne stable et une variance infinie ».
Les courts sprints sont donc un élément « absolument essentiel » selon Dan Milstein, car « ils placent une limite stricte sur le coût d'une mauvaise estimation », et ceci explique, selon lui, pourquoi les méthodes Agiles ont rencontré tellement de succès depuis leur apparition.
Source : Hut 8 Labs Blog
Et vous ?
Êtes-vous d’accord avec l’avis de Dan Milstein ? Que pensez-vous de l’estimation des délais dans les projets logiciels et des deadlines non respectées ? 
Envoyé par AoCannaille
