J'ai besoin de ce bébé dans un mois - envoyez-moi neuf femmes!
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?
Les circonstances exactes sont évidemment très spécifiques à votre projet (par exemple, équipe de développement, style de gestion, maturité du processus, difficulté du sujet, etc.). Afin de mieux définir cela afin que nous puissions en parler dans autre chose que 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 entraîne 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'à la fin?
Il y a un certain nombre de choses qui, selon moi, sont nécessaires , mais pas suffisantes, pour que cela se produise (sans ordre particulier):
- Les personnes proposées pour être ajoutées au projet doivent avoir:
- Au moins une compréhension raisonnable du domaine problématique du projet
- Maîtriser la langue du projet et les technologies spécifiques qu'ils utiliseraient pour les tâches qui leur seraient confiées
- Leur compétence doit/ne doit pas être beaucoup moins ou beaucoup plus élevée que le membre existant le plus faible ou le plus fort respectivement. Les membres faibles draineront votre personnel existant avec des problèmes tertiaires tandis qu'une nouvelle personne qui est trop forte perturbera l'équipe avec la façon dont tout ce qu'ils ont fait et font est mal.
- Avoir de bonnes compétences en communication
- Être très motivé (par exemple, être capable de travailler de manière indépendante sans insister)
- Les membres de l'équipe existants doivent avoir:
- Excellentes capacités de communication
- Excellentes compétences en gestion du temps
- Le chef de projet/gestion doit avoir:
- Bonnes capacités de priorisation et d'allocation des ressources
- Un haut niveau de respect de la part des membres de l'équipe existants
- Excellentes capacités de communication
- Le projet doit avoir:
- Une bonne spécification de conception logicielle, complète et documentée
- Bonne documentation des choses déjà implémentées
- Une conception modulaire permettant de tailler des morceaux de responsabilité clairs
- Processus automatisés suffisants pour l'assurance qualité pour le niveau de défaut requis Ceux-ci peuvent inclure des éléments tels que: tests unitaires, tests de régression, déploiements de builds automatisés, etc.)
- Un système de suivi des bogues/fonctionnalités actuellement en place et utilisé par l'équipe (par exemple trac, SourceForge, FogBugz, etc.).
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 permettent de satisfaire la libération avec votre personnel existant. Plusieurs fois, ce sont quelques fonctionnalités qui monopolisent vraiment les ressources de l'équipe qui ne fourniront pas une valeur égale à l'investissement. Alors, examinez 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é le bordereau de calendrier tôt, l'ajout des bons membres de l'équipe au bon moment peut sauver la version. Malheureusement, plus vous vous rapprochez de votre date d'expédition prévue, plus les choses peuvent mal se passer avec l'ajout de personnes. À un moment donné, vous traverserez le "point de non-retour" où aucune quantité de changement (autre que l'expédition de la branche de développement actuelle) ne peut enregistrer votre version.
Je pourrais continuer encore et encore mais je pense que j'ai touché les points principaux. 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:
- Étaient en retard avant de commencer (plus de choses que de temps) et/ou
- glissé 1h, 1 jour à l'heure.
J'espère que cela pourra aider!
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 par 6 mètres. 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 ne fonctionnera pas. De plus, vous aurez besoin de personnes qualifiées, sauf si vous voulez une affiche merdique.
Cependant, si votre projet consiste à bourrer les enveloppes de lettres prêtes à imprimer (comme Vous POURRIEZ avoir gagné!), plus vous ajoutez de personnes, plus vite cela va. Il y a des frais généraux dans le fait de distribuer des piles de travail, donc vous ne pouvez pas obtenir d'avantages sociaux au point où vous avez une personne seule. 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 avancer plus rapidement, 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 que si les conditions suivantes s'appliquent:
- Les nouveaux programmeurs comprennent déjà le projet et n'ont pas besoin de temps de montée en puissance.
- Les nouveaux programmeurs maîtrisent déjà l'environnement de développement.
- Aucun temps administratif n'est nécessaire pour ajouter les développeurs à l'équipe.
- Presque aucune communication n'est requise entre les membres de l'équipe.
Je vous ferai savoir la première fois que je vois tout cela en même temps.
Selon le Mythical Man-Month, la raison principale pour laquelle des personnes sont ajoutées à un projet tardif le fait plus tard est la surcharge de communication O (n ^ 2).
J'ai rencontré une exception principale à cela: s'il n'y a qu'une ne personne sur un projet, c'est presque toujours condamné. L'ajout d'un second accélère presque à chaque fois. C'est parce que la communication n'est pas overhead 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 Mythical Man-Month ne s'appliquent qu'aux projets tard. Si votre projet n'est pas déjà en retard, il est fort possible que l'ajout de personnes ne se 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 être utile.
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, l'attribution de cette partie du projet à un nouveau programmeur peut être utile.
Fondamentalement, les références Mythical Man Month sont correctes, sauf dans des cas artificiels comme celui que j'ai inventé. M. Brooks a fait des recherches solides pour démontrer qu'après un certain point, les coûts de mise en réseau et de communication de l'ajout de nouveaux programmeurs à un projet l'emporteront sur tous les avantages que vous retirerez de leur productivité.
- Si les nouvelles personnes se concentrent sur les tests
- Si vous pouvez isoler des fonctionnalités indépendantes qui ne créent pas de nouvelles dépendances
- Si vous pouvez orthogonaliser certains aspects du projet (en particulier les tâches non codantes telles que la conception/mise en page visuelle, le réglage/l'indexation de la base de données ou la configuration du serveur/la configuration du réseau) afin qu'une personne puisse y travailler tandis que les autres continuent avec le code d'application
- Si les gens se connaissent et connaissent la technologie, les exigences commerciales et la conception, suffisamment bien pour pouvoir faire les choses en sachant quand ils marcheront sur les pieds et comment éviter de le faire (ceci, bien sûr, est assez difficile à organiser si ce n'est pas déjà le cas)
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.
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 pas encore abordées par quiconque 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.
Je suppose que l'ajout de personnes vers la fin du travail pourrait accélérer les choses si:
Le travail peut se faire en parallèle.
Le montant économisé par les ressources ajoutées est plus que le temps perdu en faisant expliquer les choses aux personnes inexpérimentées par les personnes expérimentées dans le projet.
EDIT: J'ai oublié de mentionner, ce genre de chose n'arrive pas trop souvent. Habituellement, ce sont des choses assez simples, comme les écrans d'administration qui font un CRUD simple à une table. De nos jours, ces types d'outils peuvent de toute façon être générés automatiquement.
Faites attention aux gestionnaires qui misent sur ce genre de travail à confier. Cela semble génial, mais en réalité, il n'y en a généralement pas assez pour couper un temps significatif hors du projet.
Évidemment, chaque projet est différent, mais la plupart des travaux de développement peuvent être assurés d'avoir une certaine collaboration entre les développeurs. Dans ce cas, mon expérience a montré que de nouvelles ressources peuvent en fait ralentir involontairement les personnes sur lesquelles elles comptent pour les mettre à niveau et dans certains cas, ce peuvent être vos personnes clés (d'ailleurs, ce sont généralement des personnes `` clés '' qui prendraient le temps d'éduquer un nouveaub). Quand 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. Donc, à part cela, ce sont les circonstances où cela pourrait être bénéfique:
1) La nouvelle ressource a une tâche exigeante qui nécessite un minimum d'interaction avec d'autres développeurs et un ensemble de compétences qui a déjà été démontré. (c'est-à-dire le portage du code existant vers une nouvelle plate-forme, la refonte externe d'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 plus expérimentés de l'équipe puisse être partagé pour aider à mettre le newb à niveau et à les encadrer en cours de route 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.
- Modules autonomes non encore démarrés
- Manque d'outils de développement qu'ils peuvent intégrer (comme un gestionnaire de build automatisé)
Je pense principalement à des choses qui les empêchent de suivre le chemin des gens qui se développent actuellement. 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 de 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 réalisé plus rapidement si je pouvais me concentrer uniquement sur ce projet. En ajoutant des membres de l'équipe, je pouvais passer d'autres projets.
Bien sûr, cela suppose que vous avez embauché des développeurs capables et motivés, capables d'hériter de grands projets et d'apprendre de manière indépendante. :-)
Si la ressource supplémentaire complément 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) en empruntant du temps à un bon dba qui travaille sur le projet suivant chez vous 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, à l'exclusion du temps nécessaire aux ressources supplémentaires pour accélérer et être productif et en soustrayant le temps investi à leur enseigner par les ressources existantes. Les facteurs clés (par ordre d'importance):
- Quelle est la capacité de la ressource à la récupérer? Les meilleurs développeurs peuvent accéder à un nouveau site et être productifs en corrigeant des bugs presque instantanément avec peu d'aide. Cette compétence est rare mais peut être apprise.
- La séparabilité des tâches. Ils doivent pouvoir travailler sur des objets et des fonctions sans trébucher sur les développeurs existants et les ralentir.
- La complexité du projet et la documentation disponible. S'il s'agit d'une application ASP.Net conforme aux meilleures pratiques de Vanilla et de scénarios commerciaux courants bien documentés, un bon développeur peut tout de suite être bloqué. Ce facteur déterminera plus que tout le temps que les ressources existantes auront à investir dans l'enseignement et donc l'impact négatif initial des nouvelles ressources.
- Le temps restant. Cela est également souvent mal estimé. Souvent, la logique sera qu'il ne nous reste que x semaines et il faudra x + 1 semaines pour mettre quelqu'un au courant. En réalité, le projet IS va glisser et il reste en fait 2 semaines de développement et obtenir plus de ressources plus tôt que tard aidera.
L'ajout de développeurs est logique lorsque la productivité apportée par les développeurs supplémentaires dépasse la productivité perdue pour la formation et la gestion de ces développeurs.
Lorsqu'une équipe est déjà habituée à coupler la programmation, l'ajout d'un autre développeur qui est déjà qualifié pour le couplage peut ne pas ralentir le projet, en particulier si le développement se poursuit avec 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 sa paire, soit par la suite de tests exécutée avant chaque enregistrement (et il devrait idéalement y avoir un contrôle au moins toutes les dix minutes).
Cependant, les effets des surcharges de communication supplémentaires doivent être pris en compte. Il est important de ne pas trop diluer les connaissances existantes sur le projet.