Tout d’abord, le joueur de Lego dispose dès le départ de l’ensemble des briques qui lui seront nécessaires pour réaliser sa construction.
Le développeur n’a lui aucune idée précise du nombre et de la nature des briques qui lui seront nécessaires pour la réalisation de son programme et cela jusqu’à son achèvement complet.
Et dans le pire des cas, les briques dont il va avoir besoin n’existent même pas.
Le joueur de Lego dispose de plus d’une notice figée qui lui explique précisément étape par étape ce qu’il doit faire pour construire correctement son modèle.
Il peut donc ainsi estimer de manière fiable la somme de travail qu’il doit accomplir et le temps qu’il doit passer pour parvenir au résultat escompté.
Le développeur n’a pas cette chance, puisqu’il ne dispose dans le meilleur des cas que du mode d’emploi plus ou moins précis et à jour de chacune des briques qu’il sera amené à utiliser et d’un « cahier des charges » qui lui explique plus ou moins grossièrement ce que doit faire son programme.
Enfin, dans une boite de Lego, les briques n’évoluent pas au cours du temps et le modèle qu’elles permettent de construire reste identique à jamais.
Dans le monde du logiciel, les briques évoluent en permanence, tout comme le modèle qui doit être construit, le tout évidemment indépendamment de la volonté du développeur.
Bref, en dépit du fait que la programmation orientée objet permet en théorie au développeur de jouer au Lego avec le code, lorsqu’on lui demande d’estimer le temps qu’il va mettre à concevoir un programme, c’est exactement comme demander à un joueur de Lego de construire un modèle polymorphe à l’aide de briques changeant de forme indépendamment de sa volonté et grâce à une notice incomplète susceptible d’évoluer au cours du temps qu’il ne peut consulter qu’à travers un télescope atteint de myopie.
Alors, si vous êtes développeur, un peu joueur, et qu’un jour, une personne vous demande le temps qu’il vous faut pour écrire un « programme », je vous encourage à tenter l'expérience suivante :
- Achetez au moins deux boites de Lego suffisamment grosse pour avoir beaucoup de briques.
- Mélangez les briques de toutes les boites.
- Mettez de côté 50 % des briques.
- Découpez chaque étape de chaque notice.
- Mettez de côté 50 % de ces étapes.
- Assemblez les étapes restantes dans un ordre aléatoire afin de composer une nouvelle notice.
- Expliquez à la personne que vous allez toutes les cinq minutes remplacer 30 % de ses briques par d’autres briques prises parmi celles que vous avez mises de côté précédemment.
- Expliquez à la personne que vous allez toutes les deux minutes remplacer une ou plusieurs étapes de la notice par une ou plusieurs étapes prises parmi celles que vous avez mises de côté précédemment.
- Scotchez la notice sur un mur au minimum à trois mètres de la personne.
- Enfin, demandez à la personne de vous dire en combien de temps elle s'estime capable de construire le modèle de l’une des boites.
- Si vous êtes sarcastique, ajoutez qu'il ne s'agit que de quelques briques en plastique à assembler et que si jamais elle se trompe dans son estimation, cela aura de graves conséquences.
Je pense que vous jubilerez en entendant sa réponse, et avec un peu de chance, elle aura compris qu'il vous est impossible de répondre à cette question d'une manière fiable.
8 réactions
1 De lanfisis - 07/05/2013, 16:40
Evidemment, je suis entièrement d'accord avec toi. Le modèle généralisé qui consiste à baser le chiffrage d'un projet informatique sur le modèle de la construction (BTP ou Lego) n'a aucun sens. Mais comme expliquer qu'en 2013, alors que l'on sait pertinemment que c'est une perte de temps et d'argent que de procéder de cette manière et que les méthodes agiles sont une (la ?) solution pour travailler de manière intelligente et prospère, autant de société ayant pignon sur rue n'ont toujours pas changé leur modèle de travail ? De grosse SSII pourrait faire exploser leur rentabilité en ayant plus de bon sens, mais non en fait. Généralement les solution apportant un gain de rentabilité / de productivité sont apprécié des entreprises. Mais pourquoi dans le domaine précis de la gestion de projet informatique y'a-t-il autant d'immobilisme ?
2 De Julien - 07/05/2013, 17:22
L'agilité n'offre qu'une vision à très court terme qui est bénéfique pour tous les parties sauf pour ceux qui veulent figer dans le marbre une année de développement pour être un peu plus certains de là ou va nous mener la barque ...
Pas facile pour un patron d'entendre : "Je ne sais pas trop le temps que ça va me prendre, je sais juste qu'en 2 semaines j'aurais fait à peu près ça (du moins on espère) et après cela dépendra de ce que l'on a fait pendant ces 2 semaines, des urgences et de l'ordonnancement des projets."
Après c'est sûr qu'au fil du temps, je me suis rendu compte que les chiffrages sur 3 mois c'est simplement pour faire plaisir parce que si tu ne double pas tes estimations tu es sûr d'aller droit dans le mur.
Le pire dans tout ça c'est quand on aborde la construction du projet Lego comme on négocie chez un marchand de tapis ... "Non mais là t'en a pour 2 minutes à faire ça pas une demi journée ..."
Ah ah ah ...
3 De Renaud - 08/05/2013, 10:11
@Julien : Sauf erreur de ma part, la méthode scrum ne se limite pas au prochain sprint, mais englobe également une notion de release et de projet qui permet d'estimer une durée globale.
4 De Funkyproject - 08/05/2013, 21:16
@julien l agilité fixe un périmètre fonctionnel à court terme pas la vision. la vision est bien à long terme.
En agile, on fixe d abord le délai et les ressources suivant un macro chiffrage.
La variable d ajustement est le périmètre fonctionnel
En méthode dite traditionnelle, le périmètre est figé (cahier des charges - qui est au delà de la vision ) les variables d ajustements sont les ressources, le délai et/ou la qualité
5 De Guile - 10/05/2013, 14:42
Attention, petite remarque en passant : ta comparaison entre un développeur (inventeur, créateur) et un joueur de lego (un débutant apparemment, qui ne fait que jouer à sa boîte) n'est pas adéquate.
Il faudrait comparer un développeur par un créateur de modèle légo : ils ont tous les deux une multitude de briques, et ont chacun un objectif à atteindre.
J'avais justement vu un reportage sur ces gars qui "invente" de nouveaux modèle Lego à partir de quasiment rien.
Les deux doivent connaître leur matière première (la grande majorité des briques) et les assembler pour en faire quelque chose de super (par exemple : les Canons du Destroyer Interstellaire qui sont en faire des jumelles).
Néanmoins, il existe bien une différence comme tu l'as décrite : le créateur de lego a à disposition toutes les briques, sans limite, sans changement, et son objectif est clair (faire la voiture de batman avec environ 300 briques)
6 De Anon - 10/05/2013, 16:04
Et encore le type n'a pas une notice en suédois traduite du russe par des togolais.
Pas de quoi se plaindre !
7 De Julien - 13/05/2013, 09:22
@Renaud : Oui je suis d'accord mais cela ne permet pas d'avoir une vision comme on l'entend habituellement ou chaque jour des 365 jours de l'année sont figés dans un tableau Excel.
Après je suis grand partisan des méthodes agiles, j'essaie juste de me mettre à la place du patron, faire l'avocat du diable en quelque sorte.
8 De xecolo - 17/05/2013, 08:16
D'ou l'intérêt de faire comprendre au client que le travail d'analyse des besoins en amont du projet n'est pas une perte de temps mais bien au contraire un investissement.
Et ensuite la nécessité de son implication et d'un dialogue continu tout au long du projet.