Plus il y a de développeurs, plus on prend du retard

Proposé par
le

La loi de Brooks est une prédiction contre-intuitive sur la productivité des projets, principalement informatiques, et qui pourrait s'énoncer ainsi : "Ajouter des personnes à un projet en retard accroît son retard de façon proportionnelle à n(n-1) (où n est le nombre de personnes impliquées)".

En effet, ajouter du personnel n'est pas gage d'une productivité plus élevée car les taches d'un projet ne sont pas nécessairement faciles à partager et l'ajout de personnel rajoute du travail de formation et de communication.


Tous les commentaires (30)

a écrit : Tiré de la 1ère source également :
" être 300 dans une cuisine ne fera pas qu'un œuf au plat sera servi 300 fois plus vite ".
Ok pour l’idée, mais les projets informatiques sont quand même plus complexe qu’un œuf au plat

a écrit : Par contre, on peut dire que 300 œufs seront servis dans le même laps de temps. Tout dépend du projet analysé : « faire un œuf » ou « restaurer les clients ». Et la poule, on en parle?

a écrit : Et la poule, on en parle? Et puis le nombre d'ustensiles, de plaques de cuisson, de couteau ect, si on reste avec l'effectif d'une personne, ça bloquera à toutes les étapes de la recette pour 300 oeufs en simultané et cela même avec 300 cuistot ! ;)

Les deux analogie censé illustré le phénomène ne fonctionnent pas. Car l'anecdote stipule que vous ajouter des gens au projet et non pas juste dans la pièce. Le fait d'ajouter des femmes dans la pièce ou des cuisinier dans la cuisine ne fait pas augmenter le temps de gestation proportionnellement ou le temps de cuisson.
Une fois l'oeuf dans l'eau ou la gestation amorcé les temps sont fixe, non flexible et indépendant de l'action humaine.

Surtout que cette affirmation n'a pas vraiment de réalité chiffrable mais ressemble plutôt à un exercice de pensé. Puisque cela dépend du niveau d'avancement du projet, de la qualité du code déjà écrit, de l'expérience des anciens, de l'expérience des nouveaux, du temps restant au projet, du retard déjà accumulé, du programme de formation, du management des équipes, de la rémunération, de l'investissement, de l'ambiance général des équipes, des languages et librairies utilisés etc. Bien trop de variable pour sortir une loi de proportionnalité aussi simpliste et universelle que n(n-1).

Le truc qu'est vraiment bizarre pour moi c'est que la productivité individuelle et le temps pour atteindre une productivité optimale n'est pas pris en compte.
En gestion et conception de projets on calculerais le coût de formations, le manque a gagné du fait de cette formation, on aurait calculé le temps qu'il faudrait et le nombre de chaussures a produire pour que l'ajout de personne deviennent rentables.

Nous somme 2 pour fabriquer dix milles paires de chaussures en un mois. Ça fait 5000 paire a produire chacun au rythme de 10 par jour. On arrivé à 300 par individu maximum, 600 a deux et donc on observe un retard de 9400 paires. Combien de personnes dois je recruter et combien de temps les former pour que (temps restant - temps de formation) x nombre d'individus x productivité individuelle = temps suffisant.

Je dirai plutot: Quand un projet est mal calibré depuis le début alors c'est des ennuis jusqu'à la fin et un résultat médiocre...rajouter du personnel - en cours de projet - ne permet generalement pas de finir dans le temps voulu mais - au moins - de terminer en limitant la casse. La recherche maximum de profits tend à sous evaluer les effectifs. Vos derniers commentaires me rassurent sur la vision réaliste que vous pouvez avoir concernant la gestion de projets.

a écrit : Non, cela veut juste dire qu'ajouter 1 personne n'augmente pas le retard...
En revanche il n'y a pas d'unité notifiée dans l'anecdote... Le retard se mesure en quoi ?
En volts ?

Pour l'unité, je pense que c'est soit en jours, soit la durée du retard au moment de l'ajout de la personne. Supposons que le retard soit de 3 jours et qu'on rajoute 2 personnes. 2(2-1) = 2.
Exemple avec unité= jour, le retard passe à 3+2=5 jours.
Exemple avec unité = durée du retard, le retard passe à 3+2×3=9 jours. Dans ce cas on est sur un rapport exponentiel, plus le retard est grand à la base, plus l'ajout de personnes va plomber le projet.
Ça me semble plus logique que ce soit en jours.

a écrit : les taches d'un projet => ce sont plutôt des tâches... Absolument !
Tâchons de ne pas faire tache avec nos commentaires. :)

Ça ne me parait pas si contre intuitif que ça, finalement.
Après les nombreuses citations déjà partagées, il y a celle de Jean de La Fontaine: « 5 iris ne sont guère plus majestueux qu’un iris si tant est qu’il le soit, qu’il le fut et qu’il y succombe  »
Absolument superbe.

a écrit : Pour l'unité, je pense que c'est soit en jours, soit la durée du retard au moment de l'ajout de la personne. Supposons que le retard soit de 3 jours et qu'on rajoute 2 personnes. 2(2-1) = 2.
Exemple avec unité= jour, le retard passe à 3+2=5 jours.
Exemple avec unité = durée du retard, l
e retard passe à 3+2×3=9 jours. Dans ce cas on est sur un rapport exponentiel, plus le retard est grand à la base, plus l'ajout de personnes va plomber le projet.
Ça me semble plus logique que ce soit en jours.
Afficher tout
"... de façon proportionnelle à n(n-1)." dit l'anecdote. C'est donc juste un coefficient, sans dimensions, c-à-d sans unité.
C'est d'ailleurs logique puisque 1 est sans unité... ;)