Pourquoi ajouter plus de personnes à un projet tardif le fait-il plus tard?

25

C'est un adage assez courant que l'ajout de programmeurs à un projet tardif aggravera les choses. Pourquoi est-ce?

project-management Henri
la source
14
Le terme pour cela est la loi de Brooks ( en.wikipedia.org/wiki/Brooks's_law ).
Macneil
7
Conseil: lisez le "Mois mythique de l'homme" de Brooks. Cela montrera d'où vient cet adage, c'est un livre très lisible, et tout le monde sur le terrain devrait le lire quand même.
David Thornley
Cette page Wikipedia est très bien écrite.
Henry
Pour des preuves de la façon dont la productivité diminue avec la taille de l'équipe (au-delà de 7 membres de l'équipe, vous obtenez des rendements décroissants), voir qsm.com/process_improvement_01.html
Joeri Sebrechts

Réponses:

33

Frais généraux d'introduction

Chaque nouveau développeur doit être initié à la base de code et au processus de développement, ce qui prend non seulement le temps de la nouvelle personne mais nécessite également l'aide d'un [développeur] senior (les guider à travers le processus de construction, expliquer le processus de test, les aider avec des pièges dans la base de code, des revues de code beaucoup plus détaillées, etc.) .

Par conséquent, plus vous ajoutez de nouveaux développeurs au projet, plus vous devez consacrer de temps à les amener à un point où ils peuvent réellement contribuer au projet.

Baelnorn
la source
Donc, si vous optimisez «Introduction», l'impact sera-t-il diminué?
Henry
9
@Henry: le problème est que vous ne pouvez généralement pas optimiser cet aspect dans une mesure où ce n'est pas le goulot d'étranglement. Un nouveau programmeur sait tout d'abord exactement 0 sur votre projet, votre code et vos processus. C'est la même surcharge qui est toujours requise lors de l'ajout d'un nouveau membre de l'équipe. Mais lorsqu'un projet est déjà en retard, l'équipe n'a souvent pas le temps de faire une introduction appropriée, et si c'est le cas, ce temps manque dans le développement réel. Par conséquent, c'est généralement une situation perdante pour l'équipe et la nouvelle personne prend beaucoup plus de temps jusqu'à ce qu'elle puisse contribuer de manière significative au projet.
Baelnorn
En ce qui concerne le coût d'une introduction, ne peut-elle pas être enregistrée sur bande vidéo puis diffusée à plusieurs, afin qu'elle puisse former un grand nombre de nouveaux programmeurs à la fois? (Exemples: réunions ou conférences de développeurs.)
rwong
7
@rwong: Ce n'est pas une mauvaise idée, mais ce n'est généralement pas pratique. Vous ne pouvez pas simplement présenter les informations, vous devez vous assurer que les nouveaux gars les comprennent. De plus, s'ils sont vraiment nouveaux (diplômés récents), il y a généralement trop d'informations à leur présenter à la fois. Nous avons constaté qu'un wiki fonctionne bien, car toutes les informations sont au même endroit, et les gens peuvent poser des questions s'il y a des éléments qu'ils ne comprennent pas.
TMN
Une possibilité consiste à affecter une nouvelle personne très compétente et à lui confier des tâches spécifiques sans déranger les autres. Ils pataugeront mal et travailleront lentement, et certains managers et / ou équipes ne supportent pas de voir cela. Cependant, le nouveau développeur peut être un avantage net lorsqu'il est géré de cette façon.
David Thornley
32

En plus des autres réponses: Un autre facteur à considérer est la communication.

Le pire des cas pour la quantité de canaux de communication dans une équipe (ce qui n'est pas rare), est un graphique complet . Comme vous pouvez l'imaginer, l'ajout d'un seul développeur peut augmenter considérablement les canaux de communication. Avec des méthodes de communication plus rationalisées, l'impact est moindre ... mais il s'additionne toujours.

Steven Evers
la source
J'écrivais tout de même à peu près au même moment! mais je ne l'ai pas nouveau, il avait un nom (un graphique complet) et votre explication est meilleure, alors voilà mon vote.
Miguel Veloso du
+1. D'accord, c'est le plus gros problème lors de l'ajout de membres de l'équipe.
Martin Wickman
+1 pour le problème à plus long terme avec l'ajout de personnes à un projet.
indyK1ng
23

Le problème cité dans le livre qui a initialement promulgué cette loi, Le Mois de l'homme mythique , est la communication. Il commence par dire:

Les hommes et les mois ne sont des produits interchangeables que lorsqu'une tâche peut être répartie entre de nombreux travailleurs sans aucune communication entre eux. Cela est vrai pour la récolte du blé ou la cueillette du coton; ce n'est même pas approximativement vrai de la programmation des systèmes.

Il mentionne la formation comme faisant partie du problème:

Le fardeau supplémentaire de la communication se compose de deux parties: la formation et l'intercommunication. Chaque travailleur doit être formé à la technologie, aux objectifs de l'effort, à la stratégie globale et au plan de travail. Cette formation ne peut pas être divisée, cette partie du travail varie donc linéairement avec le nombre de travailleurs.

... mais note que l'intercommunication est de loin le facteur le plus important:

Étant donné que la construction de logiciels est intrinsèquement un effort systémique - un exercice d'interrelations complexes - l'effort de communication est important et il domine rapidement la diminution du temps de tâche individuelle provoquée par le partitionnement. Ajouter plus d'hommes allonge, non raccourcit, le calendrier.

Il convient également de noter que Fred Brooks (l'auteur) a les antécédents pour savoir de quoi il parle. La majeure partie du livre est basée sur son expérience dans la gestion du projet OS / 360 d'IBM. Malgré des décennies d'adhérents prêchant toutes sortes de méthodes de gestion "améliorées", et certains proposant même des noms sympas (eXtreme, Agile, Scrum, etc.) quand vous y arrivez, peu d'essence 1 semble avoir changé depuis.

1 Pour la définition de "essence", voir le "No Silver Bullet: Essence and Accident in Software Engineering" du même auteur, inclus dans l' édition du 20 e anniversaire de The Mythical Man-Month .

Jerry Coffin
la source
12

Ce n'est pas simplement un adage; c'est vérifiable. Découvrez le mois mythique de Brooks .

John
la source
1
C'est un adage. Il peut être vérifiable ou non, mais cela ne l'empêche pas d'être un adage.
Peter Boughton du
3
Je n'ai pas ce livre (évidemment). Est-ce que cela est étayé par des chiffres ou est-ce anecdotique?
Henry
2
@Henry: Cela fait un moment que je ne l'ai pas lu mais IIRC, les deux sont présents en quantité suffisante pour faire le point de façon concluante.
Steven Evers
@Peter: Modification de ma réponse.
John
@PeterBoughton C'est un adage. De plus, ce n'est pas simplement un adage.
SantiBailors
6

Voici quelques réflexions sur cette question ...

  • Besoin d'utiliser les ressources actuelles pour mettre à jour les nouvelles ressources sur ce qui se passe avec le projet.
  • La nouvelle ressource peut ne pas être familière avec la base de code, donc a nécessité plus de temps pour s'acclimater au code.

maintenant, ajouter de nouvelles ressources pour les tests n'est peut-être pas une mauvaise idée ... cela pourrait accélérer le processus de test (si vos cas de test sont bien écrits), et oui, l'utilisation d'outils de test vous aidera aussi.

aggietech
la source
1
+1 pour l'ajout de ressources aux tests, pas au développement.
Baelnorn
4

Parce que la programmation n'est pas un travail de base sur la chaîne de production. Se familiariser avec un projet logiciel prend du temps. Les nouvelles personnes doivent poser beaucoup de questions, ce qui conduit à une productivité négative (c.-à-d. Nouvelle personne apprenant, personne âgée leur enseignant -> aucun travail réel n'est fait).

Pour simplifier, imaginez un projet individuel relativement simple qui devrait durer 1 semaine: jeudi, vous vous rendez compte que cela ne se fera pas à temps, qu'il faudrait plutôt un programmeur comme 6-7 jours à la place de 5. Si vous ajoutez un autre programmeur à ce stade, il devra travailler avec programmer1 pendant au moins quelques heures ou un jour environ, poser beaucoup de questions pour se mettre au courant, etc. Vous n'obtiendrez probablement pas toute productivité nette positive pour le reste de la semaine. Le nouveau programmeur est également susceptible d'introduire quelques bogues supplémentaires (car ils ne connaîtront pas le code existant ainsi que programmer1), ce qui fera exploser le cycle d'implémentation et de test d'ici un jour ou deux de plus. Le projet durera facilement deux semaines complètes au lieu de l'original!

Tables Bobby
la source
Eh bien, votre exemple est un peu artificiel par le court délai irréaliste laissé au projet. Changez-le en un mois et vous verrez que ce n'est pas nécessairement vrai. Personnellement, je pense que la citation a été abusée. C'est vrai lorsque l'on considère un programmeur ordinaire, moyen / pauvre. Si vous avez un bon programmeur et que le délai n'est pas quelque chose d'irréaliste comme 1 jour ou 1 semaine, alors le devis est faux: cela peut être fait (aidez le projet).
n1ckp
@ n1ck C'est une généralisation - comme "trop ​​de cuisiniers" - le point clé est que le simple fait de consacrer du personnel au projet n'entraînera pas nécessairement sa résolution plus rapide. 1 personne à 2? Sera probablement. 2 à 4? Trop de variables - cela dépend de la taille et de la structure du projet. 4 -> 8? Certainement marginal (au moins en termes de retour sur coût).
Murph
@Murph: vous semblez penser principalement aux mêmes choses que moi, mais vous avez oublié une variable très importante dans votre équation: le niveau de compétence de la main-d'œuvre ajoutée. C'était dans mon dernier commentaire, donc je trouve étrange que vous l'ayez manqué. L'ajout aveugle de main-d'œuvre n'est bien sûr pas la solution. L'ajout de main-d'œuvre très spécialisée (vous n'en avez pas besoin) peut bien sûr aider et c'est ce qui manquait dans la citation mythique du mois-homme. C'était mon point. Sinon, je sais déjà ce que signifie la citation.
n1ckp
Ok, l'exemple pourrait être meilleur mais la généralisation est toujours valable?
Murph
1
J'ai vécu assez de fois pour savoir que c'est une de ces choses qui POURRAIT fonctionner dans des cas très spécialisés, mais 99% du temps ce ne sera pas le cas. Peu importe à quel point cela semble bon en théorie à l'époque. Cela dit, oui, ce n'est pas un absolu en noir et blanc. C'est plus comme dire, comment les relations ouvertes ne fonctionnent pas. La théorie est sympa et tentante;) .... mais la nature de la bête est telle que dans la plupart des cas elle finit par échouer. Une sorte de chose "les exceptions prouvent la règle".
Bobby Tables
4

Fred Brooks a écrit un livre entier "The Mythical Man-Month" pour répondre à cette question.

Voici la version quick-n-dirty:

1) Il y a une limite à combien vous pouvez diviser un projet en morceaux distincts à affecter à plus de programmeurs.

2) La division d'un projet à plus de personnes augmente la quantité de communication requise pour coordonner toutes les parties de l'application. Plus de communication = plus de travail.

3) Pour chaque personne que vous ajoutez au projet, vous ajoutez plus d'un canal de communication qui doit être dirigé vers l'équipe. Ce nombre augmente géométriquement et augmente la quantité de communication qui doit se produire. Plus de communication = Plus de travail.

4) Il y a une "courbe en J" lorsque vous ajoutez chaque membre de l'équipe. Autrement dit, les ressources productives existantes doivent passer du temps à préparer les nouvelles personnes qu'elles auraient autrement pu consacrer à travailler sur le projet. En fin de compte, vous pouvez augmenter la capacité, mais cela ralentit temporairement le projet. Plus le projet est avancé, plus il faut en apprendre, donc plus l'effet est prononcé.

JohnFx
la source
4

Un autre facteur que je n'ai pas vu mentionné est que certaines tâches doivent être effectuées dans un ordre spécifique. Vous ne pouvez pas faire la tâche 4 tant que la tâche 3 n'est pas terminée car elle dépend de 3. Il n'est pas utile d'embaucher quelqu'un pour effectuer la tâche 4 en même temps que quelqu'un effectue la tâche 3. Souvent à la fin d'un projet , les tâches qui doivent être exécutées en premier sont les tâches restantes.

Ce sont aussi souvent certaines des tâches les plus complexes qui doivent être accomplies, celles-là mêmes qui nécessitent la meilleure compréhension de l'ensemble de la conception pour éviter de casser ce qui a déjà été accompli. Ils nécessitent également généralement la connaissance la plus étendue du domaine d'activité. Je pourrais après avoir travaillé sur le projet pendant des mois être en mesure de faire la tâche en une semaine ou moins. Quelqu'un de nouveau passerait plus d'une semaine à se mettre au courant (et à m'éloigner de mes tâches pour une bonne partie de ce temps pour répondre aux questions) et serait probablement même si extrêmement qualifié prend plus de temps pour faire la tâche. Ce n'est pas parce qu'il ou elle n'est pas compétent mais à cause de sa méconnaissance de la structure réelle du projet ou du backend de la base de données.

HLGEM
la source
+1. C'était un problème majeur lors de mon dernier emploi. La direction était en méga "mois homme" ajoutant "l'engouement pour un grand projet sans réfléchir. À un moment donné, notre équipe a été forgée pour être lente - parce que nos affaires devaient s'intégrer à ce projet majeur. Mais ensuite, les nouvelles embauches sur le projet majeur n'ont pas pu être mises à jour assez rapidement, alors NOUS sommes allés trop loin (sur des trucs qui avaient besoin que leurs backends soient terminés). À un moment donné, nous développions des frontaux pour des backends semi-cuits et des harnais de test. Pas un bon écoulement.
Bobby Tables
2

L'adage qui a toujours fonctionné pour moi est que vous ne pouvez pas obliger neuf femmes à faire un bébé en un mois.

rediffusion
la source
Si vous pensez qu'un projet logiciel est comme un bébé, vous ne vivez pas dans le monde réel. Il y a du vrai dans la citation mais c'est l'exemple parfait pour sortir les choses de leur contexte: -1
n1ckp
1
Ce n'est évidemment pas le cas. Mais les gens que vous avez vendent également des délais ne comprennent pas le développement de logiciels. Les analogies sont exactement à cet effet reliant un concept inconnu à une entité connue.
relancez
2
Une autre analogie que Brooks fait est de manger dans un restaurant. Une cuisine bien gérée peut préparer de nombreux repas en parallèle, mais il y a des limites à la vitesse à laquelle elle peut préparer un seul repas sans trop cuire ni brûler.
David Thornley
@rerun: le problème avec votre analogie est qu'il n'y a pas d'analogie avec les travailleurs pour les femmes enceintes. Les femmes dans votre cas pourraient être plus facilement comparées à l' entreprise , pas aux travailleurs. C'est pourquoi cela échoue autant à mon avis. Le plus proche que je peux penser serait la nourriture mais ce serait plus comme une ligne de codes, donc non, pas les travailleurs.
n1ckp
1
@ n1ck: Mon impression est que vous n'êtes pas d'accord parce que vous ne le comprenez pas, pour être honnête. Brooks ne parlait pas de remplacer des personnes inutiles par des personnes compétentes, car il était dans une situation où tout le monde toujours employé était considéré comme compétent.
David Thornley
2

Je suggérerais également "Peopleware" par DeMarco et Lister.

Et "The Deadline" par DeMarco présente cela, et un certain nombre d'autres maladies et erreurs fallacieuses de gestion de projet logiciel d'une manière légère et très lisible.

Il plonge également dans la dynamique des personnes qui font du travail de projet / d'équipe, et entre dans certains détails sur la façon dont des choses comme la communication et l'introduction épuisent le temps de travail disponible d'une équipe.

Ces livres sont assez bon marché, je vous suggère de les obtenir (Amazon ou The Book Depository en ont) et de les lire. Les réponses courtes ici ne peuvent pas vraiment rendre justice à la question posée.

vite_maintenant
la source
2

Parce que personne ne prend le temps d'avoir un processus bien pensé, planifié et testé pour: embaucher, former, développer et superviser des programmeurs et encore moins les mettre au courant d'un projet particulier.

Si vous dirigez une équipe de développeurs, vous devriez avoir plusieurs contacts en ce moment des personnes que vous souhaitez embaucher si vous avez une ouverture. Rejoignez des groupes de développeurs.

À quelle vitesse pouvez-vous obtenir une toute nouvelle configuration de machine de développement et prêt à démarrer?

Avez-vous déjà testé la documentation et les spécifications de votre projet en les montrant à un développeur sur un autre projet? L'ont-ils examiné et déterminé qu'ils pourraient commencer à travailler sur le projet si nécessaire?

À quel point le calendrier du projet est-il à jour?

Économisez pour un jour de pluie, car lorsqu'un projet prend du retard, il ressemble plus à un ouragan.

JeffO
la source
1

Mis à part le problème de communication (dont je pense que toutes les autres réponses parlent), il est également très possible qu'une personne ajoutée à un projet crée des bogues, car elle ne connaît pas encore très bien le code.

Chaque fois que je suis ajouté à un projet, je m'efforce toujours de ne pas casser les choses. Cela signifie que je suis beaucoup plus lent à réparer les choses au début.

Paul D. Waite
la source
0

Je voudrais signaler quelque chose de totalement ignoré jusqu'à présent par les autres réponses.

Au moment où les gens sont ajoutés à un projet tardif, beaucoup de choses ont mal tourné dans l'organisation. La direction et le client ne sont pas contents. Les gens ont subi des pressions pour continuer. Les choses sont assez tendues.

Imaginez maintenant que vous faites partie de cette équipe. De toute évidence, rien de tout cela n'est de votre faute. La planification (dont aucune n'était la vôtre) a été trop optimiste. Toutes les mauvaises décisions ont été prises sans vous consulter. Vous essayez d'en tirer le meilleur parti et tout à coup, un tas de nouvelles personnes arrivent. Quel message cela transmet-il?

Les gens à l'étage ont évidemment perdu confiance en vous. Ils ont appelé les grands garçons pour compenser ce que vous avez gâché.

Serez-vous toujours motivé pour en faire un succès? Ou ... serez-vous toujours plus frustré et préféreriez-vous tout voir s'écraser après tout?

Prends ton temps :-).

Martin Maat
la source