La loi de Brooks et la loi de Conway dans la gestion de projets informatique

• Loi de Brooks  (Frederick Brooks):

Texte de la loi : "Ajouter des développeurs à un projet qui est déjà en retard, le retarde encore plus." (Adding manpower to a late software project makes it later)

Cette loi touche à la productivité des projets, le projet est divisé en plusieurs tâches dont la plupart ne sont plus divisibles est partitionnables et que les nouveaux membres de l’équipe vont faire perdre encore plus de temps aux membres déjà en place, les causes de cette perte sont multiples (intégration des nouveaux dans l’équipe, formation au contexte du projet et des systèmes utilisés, autonomie des nouveaux, communication entre les membres de l’équipe, …) et ce temps ne peut être compensé par la monté en productivité des nouveaux arrivants.

Brooks estime que ce temps perdu est proportionnel à n(n-1) (n étant le nombre de personnes impliquées) et donc la productivité et le rendement d’une équipe informatique est influencé par la taille de l’équipe projet.

Brooks exprime aussi un autre concept dans la gestion des projets informatiques, il avance qu'un travail de 1 personne pendant n mois peut parfaitement être réalisé par n personnes pendant 1 mois, le proverbe cité par Brooks pour exprimer cette idée est : « Neuf femmes ne font pas un enfant en un mois ».

• Loi de Conway

Texte de la loi :« Une organisation qui conçoit un système concevra un système dont la structure est une copie de la structure de communication de l'organisation » (Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure) 

Conway explique qu’un système logiciel est une forme de miroir de l’équipe qui l’a fait, le système reflétera une image identique de l’équipe qui l’a mis au point en terme de communication, d’ambiance générale, d’entente entre les membres et les groupes réalisants les différentes couches logiciel du système.

Ainsi si deux équipes réalisent deux composants logiciel d’un même système et si les deux équipes ne communiquent pas entre elles pour définir les interfaces applicatives entre les deux composants le produit final sera à l’image de cette coopération entre ces deux équipes un résultat non fonctionnel et non applicable, donc les interfaces qui en résultent entre les deux composants reflètent la qualité et la nature de la communication interpersonnelle entre les équipes de production.

La NASA a eu des problèmes causant la perte d’un satellite (Mars Climate Orbiter), mettant en cause les méthodes d’ingénierie utilisées chez le géant spatial américain, les problèmes résultent d’une mauvaise communication entre les équipes réalisant les logiciels de navigation et utilisant des unités des Etats-Unis (pouces, pieds et livres) et les équipes réalisant les logiciels des composants périphériques (cm, mètre, kilomètre)

Donc si on rencontre un projet fait d’une manière bancale il ne faut pas blâmer les développeurs (pas parce que j’en fait parti), mais il faut penser que le problème est plus profond, ce qui montre la loi de Conway c’est que le problème peut toucher la conception même de l’équipe sur le point communication, ententes entres les acteurs du projet (concepteurs, développeurs, architectes logiciel, clients, qualiticiens, …). Pour résoudre ces problèmes une refonte générale de l’équipe est envisageable et un conseil quittez le projet !

Je pense que cette loi peut être projetée dans le domaine psychologique, ce que tu reflète aux autres et à l’environnement qui t’entour te reviendra de la même manière que tu l’a projeté !