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é 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):

• Les personnes proposées à ajouter 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 / pas / être beaucoup moins ou beaucoup plus grande que le membre existant le plus faible ou le plus fort respectivement. Les membres faibles épuiseront votre personnel actuel avec des problèmes tertiaires tandis qu'une nouvelle personne trop forte perturbera l'équipe en expliquant que tout ce qu'elle a fait et fait est mal.
  • Avoir de bonnes compétences en communication
  • Être très motivé (par exemple, être capable de travailler de manière autonome sans incitation)
• Les membres de l'équipe existants doivent avoir:
  • Excellentes capacités de communication
  • Excellentes compétences en gestion du temps
• Le chef de projet / la direction doit avoir:
  • Bonnes capacités de hiérarchisation 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 de logiciel, complète et documentée
  • Bonne documentation des choses déjà implémentées
  • Une conception modulaire pour permettre de dégager des responsabilités claires
  • Processus automatisés suffisants pour l'assurance qualité pour le niveau de défaut requis.Ils peuvent inclure des éléments tels que: des tests unitaires, des tests de régression, des déploiements de build automatisés, etc.)
  • Un système de suivi des bogues / fonctionnalités qui est 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 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:

• Étiez en retard avant de commencer (plus de choses que de temps) et / ou
• glissé 1h, 1jour à la fois.

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:

1. Les nouveaux programmeurs comprennent déjà le projet et n'ont pas besoin de temps de démarrage.
2. Les nouveaux programmeurs maîtrisent déjà l'environnement de développement.
3. Aucun temps administratif n'est nécessaire pour ajouter les développeurs à l'équipe.
4. 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 à 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é.

• 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 visuelle / la mise en page, 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 travailler dessus pendant que les autres continuent avec le code de l'application
• Si les gens se connaissent, que la technologie, les exigences commerciales et la conception sont assez bien pour être en mesure de faire les choses en sachant quand ils se marcheront sur les pieds et comment éviter de le faire bien sûr, c'est assez difficile à arranger si ce n'est pas déjà le cas)

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:

1. Le travail peut être effectué en parallèle.

2. 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.

• Modules autonomes qui n'ont pas encore démarré
• Manque d'outils de développement qu'ils peuvent intégrer (comme un gestionnaire de build automatisé)

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):

1. 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 les bogues presque instantanément avec peu d'assistance. Cette compétence est rare mais peut être apprise.
2. La ségrégabilité des tâches. Ils doivent pouvoir travailler sur des objets et des fonctions sans trébucher sur les développeurs existants et les ralentir.
3. La complexité du projet et la documentation disponible. S'il s'agit d'une application ASP.Net basée sur les meilleures pratiques à la vanille et de scénarios commerciaux courants et bien documentés, un bon développeur peut tout simplement s'y retrouver. Ce facteur déterminera plus que tout autre combien de temps les ressources existantes auront à investir dans l'enseignement et donc l'impact négatif initial des nouvelles ressources.
4. Le temps restant. Ceci est également souvent mal estimé. Souvent, la logique sera qu'il ne reste plus que x semaines et qu'il faudra x + 1 semaines pour mettre quelqu'un au courant. En réalité, le projet va déraper et il reste en fait 2 semaines de développement à faire et obtenir plus de ressources le plus tôt possible aidera.

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.

L'ajout de développeurs est logique lorsque la productivité apportée par les développeurs supplémentaires dépasse la productivité perdue en raison de la formation et de la gestion de ces développeurs.