Est-il toujours préférable d’avoir plus de personnes sur un projet donné ?

On pense parfois qu’ajouter des ressources ou de la main-d’œuvre est toujours la bonne solution pour accélérer un processus.

Mais est-ce vraiment le cas ? Explorons quelques concepts clés de la loi de Brooks, qui explique comment l’augmentation du facteur humain dans un projet peut entraîner d’autres résultats indésirables.

Qu’est-ce que la loi de Brooks ?

Il s’agit d’un phénomène observable en génie logiciel et en gestion de projet : ajouter de la main-d’œuvre à un projet de grande envergure, généralement peu encadré quant à la divisibilité des tâches, va retarder ce projet au lieu d’en accélérer l’achèvement.

Facteurs clés et explication

Selon Brooks, les points suivants résument la compréhension générale (simplifiée) de la règle :

1. Il y a un surcoût d’apprentissage lorsqu’on intègre de nouveaux acteurs à un projet, surtout en génie logiciel. Les bogues introduits par des acteurs qui ont peu d’expérience sur le projet peuvent en retarder la progression. Il faut garder en tête qu’il ne s’agit pas nécessairement de l’ancienneté globale dans la carrière d’un développeur, par exemple, mais plutôt du temps passé sur le projet en question, surtout si ce projet est particulier et n’a jamais été réalisé auparavant.
2. Lorsqu’on travaille sur une tâche dont l’information doit être synchronisée avec d’autres personnes, un surcoût de communication apparaît. Il découle de la combinaison des liens entre les acteurs, qui augmente de façon combinatoire, puisqu’un lien est créé pour chaque nouvel acteur dans le groupe.
3. Les tâches doivent être divisibles pour que ce surcoût soit presque nul. Autrement, le travail sera généralement ralenti. Un exemple célèbre : il faut 9 mois pour faire un bébé, mais on ne peut pas le faire en 1 mois en y mettant 9 personnes.

Comment éviter ce phénomène dans les projets de génie logiciel ?

Selon moi, et c’est une opinion personnelle, voici des actions possibles pour réduire les surcoûts dans les projets de génie logiciel :

1. Avoir un bon processus Agile/SCRUM et diviser les tâches sans laisser de dépendances entre elles. Autrement, les acteurs devront beaucoup communiquer pour des informations banales, et vous aurez à gérer de nombreux conflits de fusion (GitHub).
2. Offrir un canal de communication global pour les questions générales. On réduit ainsi l’aspect combinatoire des liens entre les nombreux acteurs d’un groupe.
3. Mettre en place un solide processus de documentation pour réduire la courbe d’apprentissage et les questions banales des nouveaux développeurs. Ils pourront apprendre et vérifier par eux-mêmes au besoin, ce qui réduit l’utilisation des canaux de communication.
4. Adopter une ligne directrice de gestion équilibrée. Un cadre de gestion rigide peut parfois réduire ou altérer la progression d’un projet à cause de tous les surcoûts qu’il engendre. Bien sûr, l’absence de règles réduira considérablement la qualité de la base de code et rendra la compilation des métriques inefficace. Il est donc important de trouver un équilibre entre les processus et l’autonomie des personnes, et c’est ce qui explique pourquoi Agile/SCRUM est si populaire et efficace en pratique.