Je vous livre la technique secrète utilisée par les meilleurs pour estimer le délai de livraison qui plaira toujours aux managers en donnant toujours un résultat fiable (mais inutile)
 |
| Les cathédrales étaient bâties sur plusieurs générations, quel chef de chantier moderne aurait accepté de lancer un tel chantier ? |
Imaginez que vous êtes au bord d'un lac dont vous ignoriez la largeur, qu'on vous lance dos à la largeur et qu'épisodiquement on vous demande : quelle est la largeur selon vous ?
Le physicien répond : 2 fois ce que j'ai déjà ramé.
Pourquoi 2 ?
Le physicien se décrit en tout point au milieu du lac. Il n'y a en réalité aucune information utile apportée tant que le rameur n'a pas atteint la fin du lac. Cette série de chiffre est du bruit car elle n'apporte aucune information validée pendant toute la durée où l'information serait utile.
Ça n'apporte rien. Au contraire.
Si vous êtes un chef de projet, vous allez adorer. Faîtes sur une vitesse linéaire la moyenne des estimations et le temps de livraison est le même \o/
Ce que l'on peut résumer en
E = lambda n: sum(map(lambda x: 2.0 *x, range(1,n)))/(n-1) == n
et factoriser en
E = lambda n:True
Ça pue la triche, et c'est de la triche. Le but dans cet algorithme n'est pas de donner une mesure utile, mais l'heuristique minimale pour plier les estimations à une attente.
Cette heuristique permet de donner la réponse quelle est mon délai de livraison estimé qui fait plaisir à un chef de projet quand je sais que je ne sais pas pour qu'à posteriori les 2 chiffres coïncident. Et, donne au chef de projet l'impression de maîtriser car une colonne de chiffre et construite pour converger vers une expectation, mais cette convergence n'est disponible que quand le projet est fini, donc quand la métrique n'est plus utile
L'estimation d'un temps de livraison est du bullshit.
Au fait, c'est un peu la magie derrière certains algorithmes d'allocations de région de mémoires : à chaque dépassement on double ...
