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

0PARTAGES

6  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de 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
8  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 08/06/2015 à 14:50
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.
6  0 
Avatar de CodeurPlusPlus
En attente de confirmation mail https://www.developpez.com
Le 08/06/2015 à 22:03
Un jour il faudra enfin chiffrer le temps qu'on passe à chiffrer.

Moi, je suis programmeur. Je programme.
4  0 
Avatar de
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.
3  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 10/06/2015 à 14:42
@Reward: je me permet de te répondre sur la facturation.

Déjà, si tu bosses en Agile, en toute transparence, ton client est au courant.
Vaux mieux, vu que tu vas fortement l'impliqué tout au long de ton développement.

Et donc, du départ, ton contrat est agile (par exemple, celui ci: http://www.contrat-agile.org/)
Dans ce contrat, tu ne t'engages pas sur un contenu figé comme sur un contrat au forfais mais plutôt sur un processus de travail et une relation donnant/donnant entre les 2 protagonistes.
La facturation se fera donc, chaque sprint par exemple, sur la quantité de travail fournis (en gros, un nombre de jours/homme).

Tu vas me dire qui y a plein de déviance:
- Pourquoi le fournisseur ne va pas gonfler la facture?
- Pourquoi le client ne fera pas preuve de mauvaise foi sur ses spécifications ?
....

Ça marche parce que le contrat prévois, comme tout projet agile, que celui-ci peux se terminer à tout moment (moyennant un préavis défini à l'avance) par l'un des deux partie.
Donc, le client et le fournisseur deviennent de vrai partenaire où aucun des deux ne veux pas "pigeonner" l'autre sous peine que l'autre se retire:
- Le fournisseur est réglo en facturation pour pouvoir continuer le projet.
- Le client s'implique dans le projet au risque que le fournisseur le laisse tomber.
Les acheteurs & vendeurs se trouvent enfin lier par ce partenariat: le premier à un besoin informatique "métier" que le deuxième peux réaliser.

Les techniques des deux cotés peuvent enfin travailler sereinement et en confiance pour le bien du produit sans être le nez dans le contrat.
3  0 
Avatar de 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
2  0 
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.
2  0 
Avatar de 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 ...
2  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 08/06/2015 à 16:36
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.
2  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 08/06/2015 à 17:52
Citation Envoyé par AoCannaille Voir le message
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.
2  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web