L’été bat son plein, et vous donneriez votre plus belle robe pour vous poser en terrasse et contempler la vie ensoleillée. Mais voilà, votre projet démarré il y a deux mois dérive en termes de délais, ce qui perturbe sensiblement votre tranquillité.
Le sponsor de votre projet, désireux lui aussi de ramener le projet dans la course au jalon, vous fait alors une proposition tout à fait alléchante : « et si tu intégrais Ingmar dans l’équipe ? Il a la pêche, il est super compétent. Je suis sûr qu’il pourrait vous aider à accélérer ».
Vous pensez au soleil qui pourrait lécher votre peau une fois le stress évacué, au plaisir de travailler avec Ingmar.
Et pourtant, vous allez dire non.
Le Mythe du mois-homme
En 1975, Frederick Brooks publie un ouvrage intitulé « Le Mythe du mois-homme » (titre original : The Mythical Man-Month: Essays on Software Engineering).
Le titre de l'ouvrage fait référence à une unité de coût de développement : le mois-homme, c'est-à-dire le travail d'un homme pendant un mois. Brooks met en évidence une représentation mythifiée de la productivité des projets : le travail de 1 personne pendant n mois peut parfaitement être réalisé par n personnes pendant 1 mois. Selon cette idée, on pourrait diviser les temps de développement par deux en mettant deux fois plus de personnel.
Mais essayez de mettre 6 personnes plutôt que 3 dans une cuisine de 10m², et vous verrez le résultat !
Conscient de cette hérésie, Brooks formule alors la loi suivante : « Ajouter des personnes à un projet en retard accroît son retard » (formulation originale : « Adding manpower to a late software project makes it later »).
« Neuf femmes ne font pas un enfant en un mois »
D’une part, la plupart des tâches du projet sont difficilement répartissables entre plusieurs acteurs, et si elles le sont, c’est que leur maille initiale était trop large et qu’il y a eu un problème dans l’identification de ces tâches.
D’autre part, il ne faut pas négliger le temps d’ « onboarding » d’un nouvel arrivant. En effet, l’équipier qui arrive devra être acculturé au projet, à ses enjeux et objectifs, aux rituels mis en place au sein de l’équipe. Tout cela consomme un temps important, difficile à compenser par la productivité ajoutée par ce nouvel arrivant.
Enfin, le nouvel arrivant va faire perdre du temps à l’équipe en place en temps de communication. Vous avez déjà certainement constaté que loi de Brooks ou pas, plus une équipe est grande plus le temps perdu pour la communication l'est aussi. Si n personnes de l’équipe doivent échanger entre elles, quand n augmente, leur extrant décroît et peut même devenir négatif (c'est-à-dire que le travail total à réaliser à la fin d'une journée est plus grand qu'au début de cette journée !).
Mais alors… peut-on contourner la loi de Brooks ?
Le scénario idéal, pour absorber un retard sur le projet, est d’augmenter le niveau de charge des ressources qui sont déjà mobilisées dans l’équipe.
Plutôt qu’un expert travaille 1 jour par semaine sur votre projet, il vaut mieux vous battre pour qu’il soit disponible 2 jours plutôt que d’obtenir un 2ème expert.
Il convient également de noter que certains projets collaboratifs massifs, développement autour d’approches open source ou hackatons, se nourrissent d’une communauté large et ouverte, et ne redoutent pas l’ajout de nouveaux contributeurs.
