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 appel à 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 archiconnu 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 :
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 efficaces 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
Je m’attendais à trouver une réponse orienté « combien de dev selon le nombre de features » ou des pistes de calculs à base de / .
Je ne pense pas qu’il soit suffisant de dire qu’il faut découper les projets, d’ailleurs difficile de faire des micro-services d’un client web par exemple.
Donc oui l’argument du 9 mamans 1 bébé en 1 mois reste valable, j’ai cru pouvoir trouver un nouvel article qui allait au delà.
Et je suis étonné de voir que 1 dev = 1 projet soit mis en avant, comme s’ils étaient chacun dans un tunnel et maître de leur bébé.
Le but d’un dev c’est pas seulement de faire du code pour la machine mais pour les autres dev, c’est de se rendre interchangeable pour éviter la perte de compétences sur tel ou tel projet s’il décide quitter le navire.
Avec seulement 2 devs full-stack, ça me paraît évident de faire des projets en mode séquentiel, c’est plus facile pour chacun de s’investir dans les code-reviews et il y aura toujours de la maintenance à prévoir qui pourra être pris en charge par l’un ou l’autre.
3 devs me semble un nombre correct pour un projet, ça ne fait que 3 cannaux de com, ça gère les code reviews, le bus factor et les congés
Ton nombre de 3 me semble encore plus empirique 😉
Tout dépend de ton niveau de granularité. Appelle-ça comme tu veux : projet, feature, user story, tâche, …
Mon point est qu’il faut découper précisément ce qu’il y a à faire, et donner chaque morceau à un nombre minimal de personnes. Et si tu as une logique en terme de développement, il vaut parfois mieux regrouper les développements sur un même développeur.
Tout en gardant évidemment en tête de faire tourner les développeurs sur les projets.
Mon point était de mettre en avant que c’est une perte de temps et d’énergie − contrairement à ce qu’on pourrait croire − de mettre plusieurs personnes en même temps sur la même réalisation. À l’échelle de l’entreprise, il n’y a aucun gain.
Maintenant, si on veut absolument regarder à l’échelle d’un projet unique (ce qui est le biais des projets développés par les SSII, quand elles n’ont pas une relation à long-terme avec les clients), c’est différent. Mon prisme est bien sûr de m’intéresser aux entreprises qui ont des besoins de développements en continu.
Je ne vois pas en quoi 3 est empirique au contraire, 3 = 3 canaux de com.
À 4 ça passe à 6 canaux de com. et 5 on passe à 10 et ce sans même parler du reste de la « hierarchie »
Il y a des schemas dans les blogs qui traitent d’orga agile qui exposent très bien ce pbm.
Autre chose, pour remettre en contexte, je ne suis ni manager ni chef de projet, juste un dev.
Mon expérience me dit que 3 c’est pas mal oui, il y a une meilleur émulation et le code est de bien meilleur qualité (des code reviews, des tests unitaires/fonctionnels, des compétences différentes sur l’UX ou l’optim. par exemple).
Au final la granularité du découpage n’a pas grand chose à voir ici, on reste toujours sur un mode 1 tache = 1 dev sauf en cas de pair prog (ou crowd programing ou ce genre d’expérimentations qui restent souvent exceptionnelles).
1 seul : on a un mec (ou une meuf bien entendu) qui est dans son tunnel, et de temps en temps qui va sortir la tête.
2 en pair prog ou pire chacun dans leur tunnel et quand ils sortent la tête ce sera pour faire de la politique de « c’est ma solution qui est la bonne »
3 me parait bien, c’est de la psycho 101 (avec les trucs sur pallo alto) qui fait qu’en cas de désaccord, il y en a toujours un pour trancher.
Bien sûr là je sous-entends qu’il est question d’entités auto-gérées. Et non ce n’est pas qu’une question de temps (même si ça ne sera visible que plus tard).
Et je ne vois comment tu peux anticiper des congés (surtout en cette période estivale) ou des départs avec juste un gars aux commandes.
Les devs ne sont pas juste des ressources interchangeables.
Il leur faut du temps pour être efficace sur un projet, qu’il se l’approprie (et qu’il en ait envie).
Mais tout ça ne répond toujours pas à la question initiale … finalement que je détourne un peu suite à mon raisonnement :
« Combien d’équipes de développeurs mettre sur un projet ? »
Je crois que tu confonds. Moi je parle du nombre de développeurs qui codent sur le même projet. Toi tu parles du nombre de développeurs dans la même équipe…
Non non je confond rien du tout.
Tu expliques très bien la fausse bonne idée qui est de croire que l’on gagnera du temps à rajouter des développeurs. Je ne revient pas là dessus.
Je dis les choses suivantes:
– j’espérais que ton article aille au-delà (de ce sujet traité assez régulièrement)
– que je ne suis pas d’accord avec ta conclusion « Aussi peu de développeurs que possible, idéalement un seul »
Ou alors on a pas la même définition de « projet ».
Dans ce cas je trouve ton explication un peu bizarre. Tu penses qu’être seul sur son projet veut forcément dire qu’on se met dans un tunnel et qu’on ne communique pas ?
Tes remarques sur les congés ou sur le fait que je sous-entendrais que les développeurs sont des ressources interchangeables sont tellement hors de propos que ça me fait vraiment penser que tu es passé à côté de quelque chose (ou alors c’est moi qui ne suit vraiment pas clair).
Et désolé si mes articles ne vont pas assez en profondeur à ton goût… J’ai rencontré tellement de personnes pour qui ce n’est pas d’une évidence folle que ça me semble important de le dire et le redire.
Pour le reste, “let’s agree to disagree” 🙂
Merci pour cet article !
Je partage quelques peu le point de vue d’Amaury sur ta conclusion… Même en communiquant, en étant un seul cela fait défaut aussi bien dans la productivité que dans la qualité au travail, et si vos 2 dev s’entendent à merveille alors vous ne pourrez qu’être comblé en tant que responsable !
@marcel : Je ne suis pas certain de comprendre. Tu es d’accord avec moi ou pas ?
Encore une fois, je dis juste de ne pas mettre plusieurs développeurs sur le même développement, ce sera plus efficace à l’échelle de l’entreprise. Cela ne veut pas dire qu’il n’y a aucune communication entre les développeurs d’une même équipe, ni qu’il n’y a pas de relecture de code.
Le pair-programming est à mes yeux une technique à utiliser ponctuellement, en fonction des besoins, et non pas à pratiquer en permanence.
Merci pour cet article! J’ai récemment participé à un gros dév et nous étions trop nombreux, du coup je suis plutôt d’accord avec ce que tu exposes. Je suis également d’accord avec la première moitié de la conclusion (« Aussi peu de développeurs que possible»). Pour le reste (« idéalement un seul »), ça dépend d’autres paramètres qui ne sont pas abordés ici (taille et avenir du projet, pérennité qu’on veut y donner, souplesse d’organisation, budget…).
En tout cas, je vais partager cet écrit :).
Merci.
@Maxx : Merci.
Attention, un projet dont la durée commence à être conséquente (plusieurs semaines voire plusieurs mois) doit être découpé en unités plus courtes. Je ne dis pas de mettre un seul développeur du début à la fin, mais un seul développeur à la fois. J’ai toujours fait tourner les développeurs sur les projets, c’est primordial.
Dans ce cas on est d’accord, un dév par tâche c’est le top. Attention, la conclusion ne le précise pas, et du coup on comprend un dev par projet 😉
Relis ce que j’ai écrit :
«
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).
»
Ça me semblait clair 🙂
Le sujet m’intéresse beaucoup mais comme les commentaires l’indiquent, il y a confusion sur le découpage et ce qui est réellement assigné à chaque développeur à un temps T, et dans la durée. Les diagrammes montrent des projets en parallèle (1 dev par projet suggéré), mais dans les commentaires j’ai l’impression que tu suggères en fait 1 dev par tâche découpée (un projet étant composé de plusieurs tâches).
Je crois qu’un exemple concret, même simple, aiderait beaucoup à s’assurer de quoi on parle.
Mmh… de manière générale, si ton projet se découpe en plusieurs tâches parallélisables, il y a un soucis. On peut en débattre, mais de mon point de vue, si tu vises un tant soit peu d’agilité, un même besoin (exprimé dans une spécification fonctionnelle ou une user story) devrait entraîner idéalement une seule tâche de développement. Dans certains cas, tu peux découper ce développement en plusieurs parties qui doivent être faites séquentiellement. Dans ce cas, il est plus efficace qu’un seul développeur se charge de l’intégralité du développement.
Si par contre tu peux découper le développement en plusieurs tâches qui peuvent être codées en même temps, je pense qu’il y a un problème. Ça veut dire que la spécification aurait dû être découpée en plusieurs projets séparés.
Chacun place le curseur où il le souhaite, mais quand même. C’est sûr que si tu considères que le développement d’un site de e-commerce entier est un seul et unique projet, tu vas pouvoir paralléliser les développements de ton projet. Mais je pense pouvoir dire sereinement que c’est un très mauvais découpage.
Si par contre, ton projet est d’ajouter le support de l’authentification OpenID à ton site e-commerce, chaque étape sera plus efficacement réalisée si une seule personne la prend en charge : un seul graphiste sur la maquette, un seul développeur back sur le développement, un seul développeur front sur l’intégration HTML/CSS, un seul développeur sur la revue de code, et ainsi de suite.
Pour revenir à ce que tu disais : « un projet étant composé de plusieurs tâches »
Oui et non. Oui, un projet est composé de plusieurs tâches. Dans mon exemple précédent, il s’agit de tâches différentes : définir le besoin, faire les wireframes et/ou les maquettes (dans le cas d’un projet web), écrire les spécifications fonctionnelles, écrire le cahier de tests, écrire la spécification technique, faire le développement back & front, faire la revue de code, dérouler les tests automatisés, dérouler les tests humains, déployer en production et faire la recette par le client (toutes ces étapes ne sont pas obligatoires, et il peut en nécessiter d’autres, suivant les projets). Mais j’insiste, si ton projet contient des tâches de même nature qui peuvent être faites en parallèle, c’est la plupart du temps un indicateur d’un mauvais découpage.
C’est intéressant tout ça. Je pense que j’écrirai un article sur ce sujet.
en faite tu confond juste les mots. pour toi un projet = une tache et c’est pour cela qu’on ne comprend pas ta conclusion.
il est impossible pour une entreprise de concevoir un projet avec 1 seul Dev.
va demander à google ou microsoft de mettre 1 seul dev sur le développement d’angular ou de windows ^^
faut faire attention au mot qu’on utilise. Un projet ce n’est pas une taches mais l’ensemble des taches qui forme le produits.
« Ça veut dire que la spécification aurait dû être découpée en plusieurs projets séparés »
NON
une spécification = une tache donc : aurait du être découpée en plusieurs taches et non projet.
il n’y a plusieurs taches ou spécification pour 1 seul projet.
et je pense que c’est logique de mettre qu’un seul dev sur une tache pas besoin d’un article pour cela.
et Oui plus tu mets de Dev sur un projet plus le projet sera fini vite car plus de tache développées en parallèle. et la je parle bien du projet global et non de toutes les taches qui compose le projet.
Si tu es chef de projet (PO …) fait attention au mot que tu emplois, parce qu’a première vue, pour un dev ce doit être compliqué de travailler avec toi qui mélange les mots. ça porte à confusion.
@momo : Merci, mais je sais très bien quels mots j’utilise. Ta condescendance est amusante mais inutile.
Un projet, c’est quelque chose qui a un début et une fin.
Pour un site web, on peut imaginer qu’un intitulé de projet soit « Modification de la procédure d’inscription ». Ce projet est constitué de plusieurs étapes (appelle-les “tâches” si ça te permet de mieux dormir la nuit, pas de soucis), qui pourraient être par exemple : Expression de besoin, wireframes, maquettes, spécification fonctionnelle, rédaction du cahier de tests, spécification technique, développement, code review, test, validation en préprod, livraison, validation en prod.
Chacune de ces étape est nécessaire à la réalisation de ce projet. Et tu ne peux pas les faire en parallèle ; si tu développes en même temps que tu écris les spécifications, tu auras des mauvaises surprises (cf. mon article sur les spécifications à problème).
Plus on travaille de manière agile, plus ces étapes seront raccourcies et on travaillera par itérations courtes ; mais il n’en reste pas moins qu’il faut passer par des étapes de définition fonctionnelle, puis par le développement, puis par de la validation.
Mon propos est donc de dire qu’il vaut mieux ne mettre qu’un seul développeur sur ce projet. Si on a un deuxième développeur, il vaut mieux l’affecter à un autre projet, ce sera plus productif.
Peut-être que c’est quelque chose d’évident pour toi, et dans ce cas-là j’en suis très heureux. Mais je peux t’assurer que ce n’est pas le cas de tout le monde, en particulier chez les non-informaticiens.
Et je me passes très bien de ton avis pour choisir mes sujets d’articles 😉
Merci beaucoup 😉