Dans quelles circonstances - le cas échéant - l'ajout de programmeurs à une équipe accélère-t-il réellement le développement d'un projet déjà en retard?
Dans quelles circonstances - le cas échéant - l'ajout de programmeurs à une équipe accélère-t-il réellement le développement d'un projet déjà en retard?
Réponses:
Les circonstances exactes sont évidemment très spécifiques à votre projet (par exemple, équipe de développement, style de gestion, maturité des processus, difficulté du sujet, etc.). Afin de mieux définir cela afin que nous puissions en parler autrement que par des simplifications excessives, je vais reformuler votre question:
Dans quelles circonstances, le cas échéant, l'ajout de membres de l'équipe à un projet de développement logiciel en retard peut-il entraîner une réduction de la date d'expédition réelle avec un niveau de qualité égal à celui si l'équipe existante était autorisée à travailler jusqu'à son achèvement?
Il y a un certain nombre de choses que je pense nécessaires , mais pas suffisantes, pour que cela se produise (sans ordre particulier):
L'une des premières choses à discuter est de savoir si la date d'expédition peut être glissée, si les fonctionnalités peuvent être coupées et si certaines combinaisons des deux vous permettront de satisfaire la libération avec votre personnel actuel. Plusieurs fois, ce sont quelques fonctionnalités qui monopolisent vraiment les ressources de l'équipe et qui n'apporteront pas une valeur égale à l'investissement. Examinez donc sérieusement les priorités de votre projet avant toute autre chose.
Si le résultat du paragraphe ci-dessus n'est pas suffisant, consultez la liste ci-dessus. Si vous avez détecté la fiche de planification tôt, l'ajout des bons membres de l'équipe au bon moment peut enregistrer la version. Malheureusement, plus vous vous rapprochez de la date de livraison prévue, plus les choses peuvent mal tourner lors de l'ajout de personnes. À un moment donné, vous franchirez le «point de non-retour» où aucune modification (autre que l'envoi de la branche de développement actuelle) ne pourra enregistrer votre version.
Je pourrais continuer encore et encore, mais je pense que j'ai touché les principaux points. En dehors du projet et en termes de carrière, de réussite future de l'entreprise, etc., l'une des choses que vous devez absolument faire est de comprendre pourquoi vous êtes en retard, si quelque chose aurait pu être fait, vous alerter plus tôt et quelles mesures vous avez besoin à prendre pour l'empêcher à l'avenir. Un projet tardif se produit généralement parce que vous étiez soit:
J'espère que ça t'as aidé!
Cela n'aide que si vous avez un projet axé sur les ressources.
Par exemple, considérez ceci:
Vous devez peindre une grande affiche, disons 4 mètres sur 6. Une affiche aussi grande, vous pouvez probablement mettre deux ou trois personnes devant elle et les faire peindre en parallèle. Cependant, placer 20 personnes devant lui ne fonctionnera pas. De plus, vous aurez besoin de personnes qualifiées, à moins que vous ne vouliez une affiche de merde.
Cependant, si votre projet consiste à remplir des enveloppes avec des lettres prêtes à être imprimées (comme Vous pourriez avoir gagné! ), Plus vous ajoutez de personnes, plus cela va vite. Il y a des frais généraux dans la distribution de piles de travail, de sorte que vous ne pouvez pas obtenir d'avantages au point où vous avez une personne pr. enveloppe, mais vous pouvez bénéficier de bien plus que de 2 ou 3 personnes.
Donc, si votre projet peut facilement être divisé en petits morceaux, et si les membres de l'équipe peuvent se mettre à jour rapidement (comme ... instantanément), ajouter plus de personnes le fera aller plus vite, jusqu'à un certain point.
Malheureusement, peu de projets sont comme ça dans notre monde, c'est pourquoi le conseil de docgnome sur le livre Mythical Man-Month est un très bon conseil.
Peut-être si les conditions suivantes s'appliquent:
Je vous ferai savoir la première fois que je vois tout cela à la fois.
Selon le Mythical Man-Month, la principale raison pour laquelle l'ajout de personnes à un projet tardif le rend plus tard est la surcharge de communication O (n ^ 2).
J'ai vécu une exception principale à cela: s'il n'y a qu'une seule personne sur un projet, c'est presque toujours voué à l'échec. L'ajout d'un second accélère presque à chaque fois. C'est parce que la communication n'est pas une surcharge dans ce cas - c'est une occasion utile de clarifier vos pensées et de faire moins d'erreurs stupides.
De plus, comme vous le saviez évidemment lorsque vous avez posté votre question, les conseils du mois de l'homme mythique ne s'appliquent qu'aux projets en retard . Si votre projet n'est pas déjà en retard, il est fort possible que l'ajout de personnes ne le fasse pas plus tard. En supposant que vous le fassiez correctement, bien sûr.
Si les programmeurs existants sont totalement incompétents, l'ajout de programmeurs compétents peut aider.
Je peux imaginer une situation où vous aviez un système très modulaire, et le ou les programmeurs existants n'avaient même pas démarré sur un module très isolé. Dans ce cas, attribuer uniquement cette partie du projet à un nouveau programmeur peut aider.
Fondamentalement, les références du mois de l'homme mythique sont correctes, sauf dans des cas artificiels comme celui que j'ai inventé. M. Brooks a fait de solides recherches pour démontrer qu'après un certain temps, les coûts de réseautage et de communication liés à l'ajout de nouveaux programmeurs à un projet l'emporteront sur les avantages que vous tirerez de leur productivité.
Ce n'est que lorsque vous avez à ce stade avancé des tâches indépendantes (presque 0% d'interaction avec d'autres parties du projet) qui ne sont encore abordées par personne et que vous pouvez faire appel à quelqu'un qui est un spécialiste dans ce domaine. L'ajout d'un membre de l'équipe doit minimiser les perturbations pour le reste de l'équipe.
Plutôt que d'ajouter des programmeurs, on peut penser à ajouter une aide administrative. Tout ce qui supprimera les distractions, améliorera la concentration ou améliorera la motivation peut être utile. Cela comprend à la fois le système et l'administration, ainsi que des choses plus prosaïques comme les déjeuners.
Évidemment, chaque projet est différent, mais la plupart des emplois de développement peuvent être assurés d'avoir une certaine collaboration entre les développeurs. Là où c'est le cas, mon expérience a été que de nouvelles ressources peuvent en fait ralentir involontairement les personnes sur lesquelles elles comptent pour les mettre à niveau et dans certains cas, il peut s'agir de vos personnes clés (d'ailleurs, ce sont généralement des personnes `` clés '' qui le temps d'éduquer un nouveau b). Lorsqu'ils sont à jour, rien ne garantit que leur travail s'inscrira dans les «règles» ou la «culture de travail» établies avec le reste de l'équipe. Encore une fois, cela peut faire plus de mal que de bien. Cela mis à part, voici les circonstances dans lesquelles cela pourrait être bénéfique:
1) La nouvelle ressource a une tâche difficile qui nécessite un minimum d'interaction avec d'autres développeurs et un ensemble de compétences déjà démontré. (c'est-à-dire porter du code existant sur une nouvelle plateforme, refactoriser en externe un module mort qui est actuellement verrouillé dans la base de code existante).
2) Le projet est géré de manière à ce que le temps des autres membres de l'équipe plus expérimentés puisse être partagé pour aider à mettre le newb à niveau et à les encadrer tout au long du processus pour s'assurer que leur travail est compatible avec ce qui a déjà été fait.
3) Les autres membres de l'équipe sont très patients.
Je suppose que l'ajout de personnes vers la fin du travail pourrait accélérer les choses si:
Le travail peut être effectué en parallèle.
Le montant économisé par les ressources supplémentaires est plus que le temps perdu en demandant aux personnes expérimentées dans le projet d'expliquer les choses à ceux qui sont inexpérimentés.
EDIT: J'ai oublié de mentionner, ce genre de chose n'arrive pas trop souvent. Habituellement, il s'agit de choses assez simples, comme les écrans d'administration qui font de simples CRUD à une table. De nos jours, ces types d'outils peuvent être générés automatiquement de toute façon.
Attention cependant aux managers qui misent sur ce genre de travail pour les remettre. Cela sonne bien, mais en réalité, il n'y en a généralement pas assez pour réduire le temps nécessaire au projet.
Je pense principalement à des choses qui leur permettent de rester en dehors de la voie des gens en développement. Je suis d'accord avec Mythical Man-Month, mais je pense aussi qu'il y a des exceptions à tout.
Je pense que l'ajout de personnes à une équipe peut accélérer un projet plus que les ajouter au projet lui-même.
Je rencontre souvent le problème d'avoir trop de projets simultanés. N'importe lequel de ces projets pourrait être achevé plus rapidement si je pouvais me concentrer uniquement sur ce projet. En ajoutant des membres d'équipe, je pourrais effectuer la transition hors d'autres projets.
Bien sûr, cela suppose que vous avez embauché des développeurs compétents et motivés, capables d'hériter de grands projets et d'apprendre de manière autonome. :-)
Si la ressource supplémentaire complète votre équipe existante, elle peut être idéale. Par exemple, si vous êtes sur le point de configurer votre matériel de production et de vérifier que la base de données est réellement réglée au lieu de simplement renvoyer de bons résultats (que votre équipe connaît en tant qu'experts du domaine), emprunter du temps à un bon dba qui travaille ensuite sur le projet. le vôtre peut accélérer l'équipe sans trop de frais de formation
Tout simplement. Cela revient à comparer le temps restant et la productivité que vous obtiendrez de quelqu'un en excluant le temps qu'il faut aux ressources supplémentaires pour se mettre à niveau et être productif et en soustrayant le temps investi dans leur enseignement par les ressources existantes. Les facteurs clés (par ordre d'importance):
Lorsqu'une équipe est déjà habituée à coupler la programmation, l'ajout d'un autre développeur déjà qualifié en couplage peut ne pas ralentir le projet, en particulier si le développement se déroule selon un style TDD.
Le nouveau développeur deviendra lentement plus productif à mesure qu'il comprendra mieux la base de code, et tout malentendu sera détecté très tôt soit par leur paire, soit par la suite de tests exécutée avant chaque enregistrement (et il devrait idéalement y avoir une vérification au moins toutes les dix minutes).
Cependant, les effets des frais généraux supplémentaires de communication doivent être pris en compte. Il est important de ne pas trop diluer les connaissances existantes sur le projet.