Combien de développeurs mettre sur un projet

Je considère la question intéressante : Combien de développeurs faut-il assigner à un projet ?

Intéressante parce que cette question revient à une fréquence relativement élevée, alors que sa réponse est simple à comprendre et qu’elle reste invariable au fil du temps.

Si cette question revient fréquemment, c’est bien parce que l’élan naturel de la plupart des décideurs (souvent des gens qui viennent du business et qui ne savent pas comment on fait du logiciel ; mais je connais des informaticiens qui ont le même tropisme) est de penser que pour aller plus vite, il faut mettre plus de ressources.

Après tout, le moyen le plus simple pour peindre un mur plus vite, c’est de faire appels à plus de peintres, non ?

Le mythe du mois-homme

Ce phénomène a été disséqué par Frederick Brooks dans son livre Le mythe du mois-homme. Paru en 1975 et réédité en 1995, c’est un classique des livres de management informatique. Eh oui, cela fait plus de 40 ans que ce problème a été analysé, et pourtant il est toujours autant d’actualité !

À défaut de le lire (l’édition française est introuvable, la seconde édition américaine est maintenant hors de prix, mais la première édition se trouve aisément en PDF − ne me demandez pas si l’auteur et l’éditeur ont donné leur accord pour sa diffusion), je vous conseille de lire l’article consacré au livre sur Wikipédia.

Pour faire un résumé très rapide, le livre présente deux concepts :

• Le premier est que c’est une illusion de croire que le travail réalisé par un développeur en deux mois peut être fait par deux développeurs en un mois. Le parallèle archi-connu est celui des femmes enceintes (si une femme fait un enfant en neuf mois, neuf femmes ne feront pas un enfant ensemble en un mois).
• Lorsqu’un projet est en retard, lui affecter des personnes supplémentaires ne fera qu’ajouter encore plus de retard. Chaque nouvel intervenant devra prendre le temps de monter en compétence, et devra communiquer avec tous ceux déjà en plus ; ainsi, ce n’est pas 1 canal de communication qui va s’ajouter, mais X canaux (X étant égal au nombre de personnes qui travaillent déjà sur le projet). Et cela peut aboutir à des situations ridicules, lorsque le temps de traitement des échanges d’information est supérieur au temps nécessaire à chacun pour réaliser son boulot.

Les spermatozoïdes

Personnellement, j’utilise fréquemment l’image des spermatozoïdes.
Oui, je sais, ça surprend un peu  

Bon, tout le monde voit à quoi ressemble un spermatozoïde. Mais parfois ils sont affectés par des malformations ; parmi celles-ci (vous pourrez en trouver la liste complète sur cette page), il existe des spermatozoïdes à double-flagelles :

 © Fondation Genevoise pour la Formation et la Recherche Médicales

Il faut savoir que ces petites bestioles sont bien moins performantes que leurs congénères qui n’ont qu’un seul flagelle. Dans leur cas, la performance se mesure facilement : c’est la vitesse à laquelle le spermatozoïde se déplace (pour ceux qui ne le sauraient pas, je rappelle que leur vie se résume à un sprint effréné).
On pourrait croire qu’avec deux flagelles, le petit gars ira plus vite, mais c’est tout le contraire. Les deux flagelles se gênent l’un-l’autre, rendant le tout moins efficace qu’un seul flagelle.

Eh bien pour les projets informatiques, c’est pareil. Deux développeurs se gêneront et seront moins efficace qu’un développeur seul.

À l’échelle d’une entreprise

En ce qui concerne le développement, le plus efficace est habituellement de conjuguer deux choses :

• Découper les projets aussi finement que possible. Que l’on soit dans une démarche agile ou non, ce principe est toujours valable.
• Confier chaque “découpage” à un nombre aussi réduit de développeurs que possible. Idéalement, un seul développeur fera l’affaire (ou un binôme développeur front + développeur back).

Car si on prend un peu de recul et qu’on ne se focalise pas sur un seul projet, on se rend compte qu’une entreprise a toujours plusieurs projets à mener. À l’échelle de la structure globale, il est donc plus rentable de s’assurer que l’ensemble des projets est mené de la manière la plus efficace possible.

Prenons l’exemple d’une entreprise ayant deux développeurs et deux projets à réaliser. Pour simplifier nos calculs, disons que chaque projet prendra un mois à réaliser par un développeur et seulement 3 semaines si les deux développeurs travaillent dessus en même temps.
Vaut-il mieux minimiser le temps pris par chaque projet, ou au contraire maximiser la productivité de l’équipe ? Un petit dessin fera bien comprendre les choses :

Si les deux développeurs travaillent conjointement sur le projet A, on peut voir qu’ils le sortiront une semaine plus tôt que si les deux projets étaient réalisés en parallèle. Mais au bout du compte, l’entreprise a tout intérêt à ce que chaque développeur soit seul sur son projet ; certes chaque tâche prendra plus de temps à être menée à bien, mais la productivité globale sera meilleure (et je ne parle même pas des bénéfices qu’il y a à donner des responsabilités et de l’autonomie).

Poussons le raisonnement un peu plus loin. Imaginons que les deux projets sont liés l’un à l’autre, ce qui fait que les deux développeurs doivent communiquer et réfléchir ensemble à certains aspects de leurs travaux − même en restant indépendants sur leurs développements. On peut se dire que cela va ajouter une semaine à la réalisation de leurs projets :

Comme vous pouvez le voir, cela reste toujours plus intéressant de mener les projets en parallèle que de les faire l’un après l’autre.

Le triangle qualité-coût-délai

Vous vous souvenez de ce triangle ? Si ce n’est pas le cas, je vous invite à lire l’article que j’avais écrit à son sujet. Petit rappel en image :

Et donc, on peut agir sur deux facteurs, le troisième se positionne de lui-même.

Sauf que ce raisonnement n’est valable qu’au niveau du projet seul. Lorsqu’on ramène ça à l’échelle supérieure, on peut voir qu’il n’y a pas besoin de rogner sur la qualité ou les coûts pour réduire les délais. Car il n’y a pas besoin de réduire le délai individuel des projets pour garder une productivité maximale au niveau de l’entreprise (regardez les deux schémas précédents) ; il suffit de gérer les projets correctement, et de leur affecter des ressources intelligemment.

C’est plutôt une bonne nouvelle, non ?

Conclusion

Donc si on revient à la question initiale, la réponse est simple :
Aussi peu de développeurs que possible, idéalement un seul