Pourquoi nous trompons-nous toujours dans l'estimation des délais ?
Les sprints de courtes durées sont la solution, affirme un sénior

Le , par Amine Horseman, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de earhater earhater - Membre confirmé https://www.developpez.com
le 08/06/2015 à 6:28
Heureusement qu'en entreprise il y a des gens plus compétents que nous qui nous donnent les deadlines ! D'ailleurs ce sont ceux là mêmes qui nous demandent à chaque fois de faire les choses pour la veille
Avatar de valkirys valkirys - Membre expérimenté https://www.developpez.com
le 08/06/2015 à 8:05
Sur le long terme ie supérieur à deux jours(!), le résultat final n'a plus grand chose à voir avec la demande initiale, même si je suis certain de l'avoir bien comprise cette demande initiale.
Avatar de MintWater MintWater - Membre actif https://www.developpez.com
le 08/06/2015 à 8:40
Si nous nous trompons dans les estimations, c'est avant tout parce que nous sommes dans un environnement non linéaire et avec des objectifs extrêmement changeants.
Se baser sur le passé pour prédire le futur pourrait être une bonne idée, mais nous ne faisons jamais deux fois la même chose (sinon copier/coller, donc 0), nous ne sommes pas sur une chaîne de montage (même si beaucoup de managers aimeraient que ça y ressemble). L'ennui dans ce genre de situation, c'est le décalage entre le "client" avec son budget serré qui va pousser les estimations vers le bas et le réalisateur qui va pousser vers le haut par protection et par sécurité.
Comme le dit l'article, en réduisant au maximum les tranches d'estimation à quelques heures, on limite la marge d'erreur, mais ce n'est pas pour autant la panacée.

Un petit billet très pertinent sur le sujet: http://www.thomsett.com.au/library/i...timation-games
Avatar de theMonz31 theMonz31 - Expert confirmé https://www.developpez.com
le 08/06/2015 à 8:46
J'apprécie beaucoup la remarque sur le fait que, si on détail trop, finalement, on code le logiciel...

Ca me rappelle mon expérience dans l'aéronautique, fin des années 90, où je devais coder un logiciel embarqué. Les spécifications détaillées étaient tellement détaillées
qu'écrire le code revenait, finalement, à traduire chaque phrase de la spec en assembleur ou en C. Bref, absolument pas passionnant...

D'ailleurs, les métriques sur le projet étaient de 4 à 5 lignes de code par jour par développeur... Bon, après, vu que le code pilote l'avion, il vaut mieux passer beaucoup
de temps sur les tests, rédactions des tests, etc... que sur du code "sioux" et risqué
Avatar de - https://www.developpez.com
le 08/06/2015 à 9:24
Il devrait demander à Microsoft de lui expliquer le fonctionnement des DLL. Simplement pour commencer, puis en profondeur.
Avatar de Sodium Sodium - Membre extrêmement actif https://www.developpez.com
le 08/06/2015 à 9:29
Respecter précisément des délais sans multiplier les heures supplémentaires (gratuites) en fin de projet me paraît être de la science-fiction.

D'abord parce qu'il est impossible de prévoir tous les petits problèmes qui vont survenir au fur et à mesure, on peut perdre des heures à cause d'une variable mal orthographiée ou une virgule oubliée, sans compter que n'importe quel projet fait au moins à un moment ou un autre à des technologies mal maîtrisées.

Ensuite parce qu'un client qui veut un truc pour la veille passera toujours avant celui dont la deadline est dans deux mois, même si cette deadline est déjà serrée par rapport aux ressources prévues.

Enfin parce que le client n'est jamais capable d'expliquer exactement ses besoins et ne comprend pas le temps qu'implique des adaptations qui lui semblent mineures. J'ai eu un cas récent ou de multiples produits B devaient dépendre d'une catégorie A. Je demande donc au client si cette règle sera immuable, ce qui simplifie à la fois la programmation et la gestion pour le client puisqu'il peut entrer une majorité communes de caractéristiques communes à tous les produits directement dans la catégorie afin de ne pas dupliquer uniquement ce contenu sur chaque produit. Il me répond oui oui. Trois jours plus tard : "Ah au fait ce produit-là il n'appartient pas à une catégorie, il faut le mettre juste seul".
Avatar de Nicam Nicam - Membre confirmé https://www.developpez.com
le 08/06/2015 à 11:43
- Besoin peu/pas/mal exprimé.
- Nouvelle fonctionnalité qui débarque en cours de projet.
- Le commercial a vendu quelque chose qui n'existe pas.
- Développement spécifique à chaque client, car le client est roi et qu'on veut absolument le garder
...
Avatar de spyserver spyserver - Membre averti https://www.developpez.com
le 08/06/2015 à 12:37
Que voulez-vous il faut bien justifier certains postes ...

C'est comme les grands projets dans l'industrie ou les grands ouvrages, il est prouvé que plus le projet est complexe plus le délai/budget initial est revu à la hausse (exmple concret : l'EPR d'Areva qui creve le plafond) dans l'informatique on peut quasiment faire la même projection ...
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 08/06/2015 à 13:24
Citation Envoyé par Amine Horseman Voir le message
Êtes-vous d’accord avec l’avis de Dan Milstein ?
Dan Milstein recommande de découper un projet en une multitude de petites tâches... Ca ne serai pas un peu la base de l'info ça, non ?????
Ensuite, faire des sprints plus petit... OK, mais ça implique déjà une analyse particulièrement poussée du projet car le découpage est à la base de la conception...

Le hic vient surtout des macros chiffrages où là, avouons le, c'est vraiment grosse maille où pour chaque fonctionnalités, on se contente de poser une qualification : simple, normal, complexe ou très complexe...
Normal qu'on se plante.

Lors de la phase de réalisation, une fois que la conception est plus avancée, on a des corrections de chiffrages nettement plus fiables mais là, il est trop tard car le contrat s'est signé sur la base des macro chiffrages...

L'avantage énorme de l'Agile ne vient pas des sprints, aussi petits peuvent ils être, mais du périmètre du projet qui est vague au lancement du projet.
Autrement dit, on débute avec un macro périmètre qui se précise au fur et à mesure des sprints : on fait ce que l'on peut dans un temps et un budget donné.
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 08/06/2015 à 14:09
Ha oui les estimation de temps !
Il est certain que c'est des plus compliqué de faire ces estimations
Du coup faire de la surestimation ça te couvre, et ma méthode donne j'estime le temps normal de réalisation sans problème puis sur le total j'ajoute 40% de temps total
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web