Pensez à votre bermuda

Une partie de mon temps, la semaine dernière, a été consacrée à un chiffrage. Loin d’être une première pour moi, cet exercice présentait la particularité d’être mené dans un contexte non contraint d’un point de vue calendaire. C’est donc avec une liberté exceptionnelle que je me posais, après avoir produit une estimation de l’effort, la question du dimensionnement de l’équipe. Une liberté qui expose particulièrement aux dangers du mythe du mois-homme.

La réalisation d’un logiciel est une activité de construction intellectuelle qui peut s’apparenter, en plusieurs points, au travail d’un écrivain. La cohérence de la structure de l’œuvre est l’un de ces points communs que l’on peut trouver entre le travail d’écriture et celui du développement. Dans le premier cas, l’implication en général d’un seul contributeur, l’écrivain, est un facteur très favorable. Mais dans le cas d’un développement informatique, il est rare que l’œuvre soit le fruit d’un seul individu ; il s’agit en général d’une œuvre collective qui implique une collaboration efficace pour garantir la cohérence du résultat. La recherche de cette efficacité est ce qui motive la définition de méthodologies de développement informatiques de ces cinquante dernières années. Le « mythe du mois-homme », essai de Frederick Brooks dont la première version est parue en 1975, est l’une des œuvres les plus influentes en la matière. Le concept clé du chapitre 2 adresse justement les difficultés d’une projection des efforts de réalisation d’une œuvre collective sur un planning. Ce chapitre explique pour quelles raisons il ne faut pas considérer qu’il existe une relation de proportionnalité entre effort et planning. Parmi ces raisons, celle de l’impact de la coordination sur l’effort global du projet est évoquée.

Dès que le projet implique deux contributeurs, il est nécessaire pour eux d’échanger un minimum d’informations pour assurer la cohérence de leurs travaux respectifs. Cette coordination passe alors par une unique relation au sein de l’équipe. Si l’équipe est constituée de trois contributeurs, le nombre de relations passe à trois. Et pour une équipe de quatre collaborateurs, il passe à six. En généralisant, le nombre de relations est le produit du nombre de collaborateurs (n) avec ses collègues (n-1), en tenant compte du fait que les relations sont bidirectionnelles. Ainsi, le nombre de relations dans une équipes de « n » personnes est (n×(n-1))/2.

Plutôt que de partir dans une modélisation mathématique du sujet, prenons l’exemple d’un projet dont la charge de réalisation est estimée à 1000, effort que j’estime en hommes-jours, certainement parce que j’ai la prétention d’être plus précis que Fred Brooks qui avait au moins la modestie de chiffrer en hommes-mois. Céder à la tentation du mythe du mois-homme conduit à estimer que le délai nécessaire pour réaliser est de 100 jours si on mobilise une équipe de 10 personnes. Ça a bien entendu été la tentation à laquelle j’ai failli succomber lors de mon exercice de la semaine dernière. J’ai donc cherché à intégrer, dans mon estimation, l’effort de coordination qui est nécessaire lorsque la taille de l’équipe s’accroît. Dans une équipe de 10 personnes, le nombre de relations est de (10×9)/2 = 45. Prenons maintenant pour hypothèse que l’effort nécessaire de coordination avec chaque membre de l’équipe pour maintenir un niveau de connaissance commun nécessaire au bon déroulement du projet soit de l’ordre de 5%. Dans ce cas, l’effort global intégrant cette coordination atteint 3250 jours, soit une valeur supérieure au triple de l’effort de production « utile », et le délai de réalisation est de 325 jours. Avec ces hypothèses, il peut être intéressant de faire varier la taille d’équipe pour mesurer ma sensibilité du délai global à la taille d’équipe :
 

Ce qu’il est intéressant de noter, c’est que le délai de réalisation connaît d’abord une diminution (bénéfices du partage des activités) pour atteindre un minimum avec une équipe de 6 personnes, taille au-delà de laquelle l’effort de coordination devient plus important que le bénéfice que l’on peut tirer de l’augmentation de la taille d’équipe. La formulation de la loi de Brooks fait directement référence à une telle situation : « Adding Manpower to a Late Project Makes It Later »

Dans l’exemple proposé on peut critiquer l’hypothèse d’un effort de communication estimé arbitrairement à 5%. Pour mesurer l’impact de cette hypothèse, on peut prendre l’exemple d’un effort de 2% (une dizaine de minutes par jour). On obtient alors la courbe suivante (série 1 à 5% et série 2 à 2%) :
 

Avec cette hypothèse revisitée, on note que l’inflexion est moins évidente ; néanmoins la tendance globale reste la même et le gain de planning avec une équipe de 7 personnes est marginale par rapport à une équipe de 6 personnes. Dans le même temps, l’effort global augmente proportionnellement à la taille de l’équipe mobilisée. Ces courbes nous invitent donc plutôt à envisager de mobiliser des équipes 4 à 5 personnes.

Ces observations nous invitent à tirer quelques leçons :

1. Idéalement, une équipe de développement informatique doit être composée de 4 à 5 personnes. Personne ne m’aura attendu pour proposer cette règle ; c’est ce qu’on appelle la « Two-pizza team rule » que l’on attribue en général à Jeff Bezos et que l’on peut formuler ainsi : « any team should be small enough to be fed by two pizzas ». Cette règle ne doit pas inviter nos RH à recruter sur un principe de frugalité des collaborateurs, mais bien à limiter à la taille des équipes autour de 5 personnes (la règle ne précise pas la taille des pizzas).
2. Viser une équipe de taille minimale a pour conséquence de chercher à la composer de profils assez polyvalents pour y être affectés à temps plein. Il est contre-productif de chercher à cumuler des experts en temps partiels ; la plus-value apportée par ces experts sera en effet gommée par le coût de leurs tickets d’entrée et de sortie et par les coûts de coordination qu’ils induisent. Là encore, je n’invente rien ; une méthodologie agile telle que Scrum propose de mobiliser une petite équipe à temps plein en limitant ou évitant toute perturbation extérieure.
3. Il existe une durée minimale incompressible pour la réalisation d’un composant logiciel. Quels que soient les moyens qu’on soit prêt à consentir, on ne pourra pas réaliser un composant logiciel donné en dessous d’un délai qui correspond au temps que mettrait une équipe de 5 personnes à le réaliser. Et si un projet prend du retard, la seule décision qui puisse être prise consiste à savoir si on accepte de publier le logiciel plus tard ou de savoir si on veut en publier une version partielle à date.
4. Le point précédent précise que la durée minimale incompressible concerne un composant logiciel, c’est-à-dire un périmètre qui nécessite un effort de coordination qui pénalise une augmentation de la taille de l’équipe. Le délai de réalisation d’un système doit être vu différemment ; en réduisant la nécessité pour certains membres d’une équipe de collaborer on casse la progression géométrique des efforts de communication. Par conséquent, si on veut mobiliser plus de 5 personnes sur un projet, il faut veiller à proposer une architecture dans laquelle les couplages entre composants sont si faibles qu’ils nécessitent un minimum de coordination entre équipes. C’est là que réside la valeur de l’architecte. On notera au passage que cette proposition répond implicitement à cette question récurrente sur les micro-services : « C’est quoi une taille micro ? » Selon moi, c’est un service qui puisse être réalisé en autonomie par une équipe de 4 à 5 personnes.

La loi de Brooks n’est pas une nouveauté. Néanmoins, on constate dans les faits qu’elle n’est pas toujours respectée. Il facile de négliger la progression géométrique des efforts de coordination et de penser acceptable un rapport de proportionnalité entre effort et délai. C’est pourtant une grave erreur qui engage de nombreux projets dans une marche funèbre. Lors de votre prochain « daily meeting », regarder autour de vous ; si vous comptez plus de quatre collaborateurs, pensez sérieusement à adopter le « bermuda plan ».