Discussion :

[Amine Horseman]

Pourquoi nous trompons-nous toujours dans l’estimation des délais ?
Les sprints de courtes durées sont la solution, affirme un 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 ?

[earhater]

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

[Invité]

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.

[MintWater]

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

[theMonz31]

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é

[MikeRowSoft]

Il devrait demander à Microsoft de lui expliquer le fonctionnement des DLL. Simplement pour commencer, puis en profondeur.

[Sodium]

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

[Nicam]

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

[spyserver]

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

[Saverok]

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

[TiranusKBX]

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

[abriotde]

Petite précision sur 2 cas d'évolution des spécification de départ.
1)
Pour l'utilisateur, c'est simple, "il faut ajouter ceci pour que cela".
Pour le programmeur ok, "pas de problème, c'est rapide".
Sauf que l'utilisateur avait oublié que lui voulait qu'évidemment on puisse "revenir en arrière, paramétrer, y accéder d'un clic... bref que ce soit simple et pratique.".
2)
Le programmeur réfléchi a la manière d'implémenter la demande de manière simple informatiquement parlant avec les librairies dont il dispose alors que l'utilisateur réfléchis en terme d'humain. Et parfois les spécifications sont très complexe a programmé alors que la demande de l'utilisateur peut se contenter de bien plus simple. Exp : générer un document Excel est complexe alors qu'un CSV (lisible par Excel) en simple. Mais si l'utilisateur et veut mettre en gras certains passage. il faut passer par un format type l'Excel. Pour l'utilisateur c'est un simple ajout (L'export complexe est fait)...

[Laurent 1973]

Le principale problème est que l'on veux pouvoir estimer le coût d'un projet informatique comme le coût de la révision de la voiture de société.
Or, faire une vidange à une voiture, on sait faire depuis très longtemps.
Même s'il peux y avoir quelque impondérable (genre une pièce grippée ou une fuite imprévue) globalement le garagiste ne se loupe pas trop sur le temps qu'il lui faut.

Mais effectuer un développement informatique spécifique, on travail alors dans l'inconnu.
Il faudrait plus se comparer aux premiers pionniers de l'espace: on ne sait pas quand on va réussir, ni quelle nouveaux problèmes on va rencontrer.
Pourtant, que ce soit les agences russe ou américain, ils ont persévérer malgré leurs différent échec (avec parfois des vies en jeu) et leur concurrences rudes.

En informatique, on essaye de conquérir la lune à chaque nouveau projet, mais on vend cela comme un révision chez le garagiste.
En ayant un état d'esprit de "prestataire" avec le demandeur et pas de "partenaire", pas étonnant que l'on ne respecte pas des délais qui sont de toute façon non prédictifs.

[el_slapper]

Je viens de faire un chiffrage. Complètement au hasard, puis j'ai multiplié par un entier pris au hasard. Comme de toutes façons, je ne sais pas sur quoi je vais tomber, ça n'a aucune valeur. Mais mon chef y tiens beaucoup.

[AoCannaille]

en école d'ingé on m'a apprit à chiffrer un projet dans sa globalité en partant des besoins clients :
Tu fais une estimation rapide de la tâche de specif de dev et du dev (notre domaine donc) et tu multiplie par Pi. "Pi c'est bien, Pi c'est réèl, le resultat est souvent dans ces eaux là".

Pour l'instant je ne me suis jamais trompé de plus de 10% dans mes estim' complètes. Par contre, moi je fais l'estimation. Si le commercial trouve ça trop cher et qu'on n'en fait pas assez on finit vite par avoir moins d'argent pour faire plus...

[Saverok]

en école d'ingé on m'a apprit à chiffrer un projet dans sa globalité en partant des besoins clients :
Tu fais une estimation rapide de la tâche de specif de dev et du dev (notre domaine donc) et tu multiplie par Pi. "Pi c'est bien, Pi c'est réèl, le resultat est souvent dans ces eaux là".

Pour l'instant je ne me suis jamais trompé de plus de 10% dans mes estim' complètes. Par contre, moi je fais l'estimation. Si le commercial trouve ça trop cher et qu'on n'en fait pas assez on finit vite par avoir moins d'argent pour faire plus...

Ce que tu décris, c’est la marge de 20% (en utilisant Pi, ça fait moins).
C’est la « part d’incertitude » évoquée par Dan Milstein.
Le hic, comme tu l’évoques, c’est que les commerciaux sont parfaitement au fait de cette norme et la font sauter presque tjrs.
Ensuite, ce que tu dis Dan Milstein, c’est que parfois, les incertitudes de l’informatique dépassent cette marge de sécurité (dans ton cas, 10%) et cela augmente proportionnellement avec la taille du projet.

[landry161]

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 .

Ouais

[CodeurPlusPlus]

Un jour il faudra enfin chiffrer le temps qu'on passe à chiffrer.

Moi, je suis programmeur. Je programme.

[Matthieu Vergne]

Pour ma part, les deadlines ne font plus partie de mon vocabulaire. J'ai une todolist de choses à faire, s'il y a besoin d'un suivi on met en place des meetings, mais si on me pose la question quand est-ce que ce sera fini, la réponse est "Quand ce sera fini.". Ma todolist est ordonnée, de manière à ce que quand une tâche est identifiée comme prioritaire (et ça peux venir d'un changement d'avis durant un meeting), elle passe au dessus des autres. Si je vois que pour faire cette tâche, il vaut mieux d'abord en faire une autre dans la liste, cette dernière passe au dessus de la première automatiquement. Les tâches inutiles finissent naturellement au fond du panier, et si on n'a pas le temps elle ne seront tout simplement pas implémentées (ou elles resteront dans la liste pour le jour où j'aurais du temps en rab).

Le principe de deadline, c'est de l'égo pur et dur. On peut avoir une prévision précise, ça n'en reste pas moins qu'une prévision, et non une prédiction. N'ayant pas de Master diseur de bonne aventure, je me garderai donc de dire ce que le futur est censé être et je me contenterai de parler de "ce qui est prévu, aux imprévus près".

[Laurent 1973]

... J'ai une todolist de choses à faire, s'il y a besoin d'un suivi on met en place des meetings, mais si on me pose la question quand est-ce que ce sera fini, la réponse est "Quand ce sera fini.". Ma todolist est ordonnée, de manière à ce que quand une tâche est identifiée comme prioritaire (et ça peux venir d'un changement d'avis durant un meeting), elle passe au dessus des autres. Si je vois que pour faire cette tâche, il vaut mieux d'abord en faire une autre dans la liste, cette dernière passe au dessus de la première automatiquement. Les tâches inutiles finissent naturellement au fond du panier, et si on n'a pas le temps elle ne seront tout simplement pas implémentées (ou elles resteront dans la liste pour le jour où j'aurais du temps en rab) ...

Matthieu, tu as tout compris aux principes de l'Agilité:

• Avoir un "backlog" de fonctionnalités classées du plus prioritaire au moins prioritaire.
• Des réunions régulière pour avoir un feed-back du demandeur pour revérifier que la liste est toujours d'actualité
• Ajouter de nouveaux besoins éventuels (+re-tri de la liste).
• De là, on réalise les éléments de la liste, un par un, le maximum par rapport au délai demandé (ou finance, ce qui est souvent la même chose)
• Une fois livré, le produit est ce qui correspond au mieux aux besoins
• Si on a les moyens, on peux continuer une nouvelle version en continuant la liste restante.

C'est je pense la meilleur solution pour respecter les délais: la date est fixe mais c'est le contenu qui change alors en fonction des besoins et des contraintes rencontrées.
Tout le débats alors reviens alors sur ce que l'on souhaite livrer.
N'oublions pas qu'en informatique, un logiciel n'est jamais fini: on peux toujours en faire plus.

Je te rejoins également sur ce point, Matthieu, il ne faut pas parler de deadline ("ligne de mort", genre on est tous foutus si on la franchi !) mais plutôt de date de livraison souhaitée (voir même de dates de livraison souhaitées).