Donner aux nouvelles recrues un sous-projet distinct de développeurs expérimentés aidera-t-il les débutants à monter en puissance plus rapidement?

Nous avons 7 développeurs dans une équipe et devons doubler notre rythme de développement en peu de temps (environ un mois). Je sais qu'il existe une règle de bon sens selon laquelle "si vous embauchez plus de développeurs, vous ne perdez en productivité que pendant les premiers mois". Le projet est un service Web de commerce électronique et compte environ 270 000 lignes de code.

Mon idée pour l'instant est de diviser le projet en deux sous-projets plus ou moins indépendants et de laisser la nouvelle équipe travailler sur le plus petit des deux sous-projets, tandis que l'équipe actuelle travaille sur le projet principal. À savoir, la nouvelle équipe travaillera sur la fonctionnalité de paiement, qui deviendra éventuellement un service Web indépendant afin de réduire le couplage. De cette façon, la nouvelle équipe travaille sur un projet avec seulement 100K lignes de code.

Ma question est: cette approche aidera-t-elle les développeurs débutants à s'adapter facilement au nouveau projet? Quelles sont les autres façons d'étendre rapidement l'équipe de développement sans attendre deux mois jusqu'à ce que les débutants commencent à produire plus de logiciels que de bogues?

=======

MISE À JOUR

Cette entreprise a complètement échoué, mais pas pour les raisons que vous avez mentionnées. Tout d'abord, j'ai été mal informé sur la taille et les capacités de la nouvelle équipe. J'aurais dû les évaluer moi-même. Deuxièmement, l'embauche s'est avérée être un travail difficile sur ce site. Sur le site du bureau principal, l'embauche était beaucoup plus facile, mais dans la ville de la deuxième équipe, il y avait apparemment une pénurie de développeurs possédant les qualifications requises. En conséquence, au lieu de 1,5 mois prévu, le travail s'est étendu à environ 4,5 mois et a été annulé au milieu par la direction.

Une autre erreur que j'ai commise (et qui a été prévenue par Alex D) est que j'essayais de vendre du refactoring à la direction. Vous ne vendez jamais de refactoring, seulement des fonctionnalités.

Le démarrage s'est avéré réussi de toute façon. Le refactoring qui n'a jamais eu lieu s'est transformé en dette technique: le système est devenu plus monolithique et moins maintenable, la productivité des développeurs a progressivement diminué. Je ne suis pas dans l'équipe maintenant, mais j'espère qu'ils le termineront dans un avenir proche. Sinon, je ne donnerais pas un sou pour la survie du projet.

Mais je suis d'accord comme tout le monde ici:

"... ajouter plus de développeurs à un projet retardé, rend le projet, pour retarder plus ..."

J'ai le sentiment que tu vas le faire n'importe où, alors ...

Votre idée peut aider, si votre projet existant est suffisamment organisé, par modules, sous-systèmes ou sous-projets.

Ce que vous voudrez peut-être essayer, c'est de leur donner de petits morceaux / modules / formulaires / classes de votre projet, pour travailler avec, au lieu de tout le projet.

Si vous utilisez une base de données, vous souhaiterez peut-être faire une copie d'une base de données de travail avec des données et y accéder à partir du module ou du sous-système de code qui va y travailler.

Avoir de nouveaux développeurs qui connaissent le langage de programmation ou l'environnement de programmation ne suffit pas, les applications logicielles peuvent devenir très complexes.

Avez-vous une documentation de l'application comme: UML, ER, Codd-Yourdon, peu importe?

Bonne chance.

Ma question est: cette approche aidera-t-elle les développeurs débutants à s'adapter facilement au nouveau projet?

"Débutant" pourrait signifier nouveau pour vous, ou cela pourrait signifier nouveau pour travailler en tant que développeurs de logiciels. Si vous allez embaucher un groupe de développeurs pour travailler sur un projet important selon un calendrier, assurez-vous qu'au moins la plupart des nouvelles recrues sont des développeurs expérimentés, et de préférence ceux qui ont écrit des projets similaires à ce que vous essayez. construire.

Quelles sont les autres façons d'étendre rapidement l'équipe de développement sans attendre deux mois avant de commencer à produire plus de logiciels que de bogues?

• Achetez ou achetez un produit existant au lieu d'essayer d'en créer un. Avez-vous vraiment besoin de réinventer la roue de paiement?

• Comme je l'ai dit plus haut, embauchez des personnes qui ont de l'expérience dans la construction du type de système que vous souhaitez.

• Avant même d'embaucher cette nouvelle équipe, vous devriez penser à ce qu'elle devra savoir sur vos affaires existantes. Assurez-vous de réserver suffisamment de temps pour les sessions de formation afin de les aider à se mettre au courant.

• Avez-vous créé un ensemble d'exigences écrites? Sinon, faites-le maintenant. Si vous prévoyez de concevoir le projet au lieu de laisser la nouvelle équipe le faire, vous devez également préparer un document de conception clair, mais être ouvert aux changements en réponse aux commentaires des nouveaux membres de l'équipe.

• Avez-vous un processus de développement bien défini? Base de données de bogues? Contrôle de version? Processus d'examen du code? Guide de style? Mettez ces choses en place.

• Ne vous attendez pas à des miracles. Vous voulez embaucher une équipe de sept personnes et les faire travailler de manière productive en quelques semaines, mais le vouloir ne signifie pas que vous pouvez avoir cela. Selon l'endroit où vous vous trouvez, cela peut prendre beaucoup plus d'un mois juste pour trouver sept personnes appropriées. Essayer de précipiter les choses maintenant ne fera que causer de la douleur et des dépenses plus tard.

À mon humble avis, mettre tous les nouveaux développeurs sur le nouveau projet, séparés de votre équipe existante, est susceptible de poser des problèmes. Oui, cela (peut) permettre à votre ancienne équipe de continuer à travailler plus ou moins à son rythme actuel. Cependant, les nouveaux gars n'auront aucune idée de l'architecture globale et de la vue d'ensemble, ils prendront donc beaucoup de temps à se mettre au courant ... et même dans ce cas, ils pourraient se diriger dans la mauvaise direction.

Je suggère de diviser votre équipe existante en deux et d'embaucher de nouveaux membres dans les deux équipes. De cette façon, il y a des personnes dans les deux équipes qui peuvent encadrer les nouveaux arrivants et s'assurer qu'une vision architecturale commune et cohérente est maintenue.

Sinon, je suis d'accord avec Caleb concernant la documentation d'exigences claires, la définition du processus et des outils de développement, et la réservation de temps pour la formation ... et aussi sur le fait qu'attendre une équipe de 7 pour être embauché et se mettre à jour dans un mois est irréaliste.

Dmitry, doubler votre rythme de développement en peu de temps est un objectif incroyablement ambitieux. Quelques bonnes suggestions ont été publiées ici; mais, quoi que vous essayiez, sachez que cela peut ne pas arriver . si votre rythme de développement ne double pas , quelles en seraient les conséquences d'un point de vue commercial? Essayez-vous de faire pression pour respecter un délai?

Si vous essayez de respecter un délai, pourriez-vous le faire de manière plus fiable en réduisant les fonctionnalités? J'ai trouvé un excellent moyen de rendre les «délais manqués» acceptables pour un client: faire des versions incrémentielles; libérez une version qui a un sous-ensemble des fonctionnalités requises, puis à mesure que d'autres fonctionnalités sont prêtes, libérez-les progressivement jusqu'à la version finale.

Vous essayez donc d'être l'équipe qui ne soit pas victime du Mois de l'homme mythique . Vous aurez plusieurs problèmes, un membre de l'équipe devra faire les entretiens techniques, puis vous devrez attendre quelques semaines après avoir accepté le poste avant de pouvoir commencer. Cela peut prendre deux mois avant que les nouveaux développeurs ne soient devant leurs claviers.

Chaque nouvel employé a une productivité négative au cours des premiers mois. La situation est aggravée car les développeurs actuels devront les encadrer, ce qui diminuera encore la productivité des tems.

L'autre partie du MMM était qu'à mesure que l'équipe grandit, les problèmes de communication augmentent également. Les réunions deviennent plus grandes, les chaînes de messagerie s'allongent ...

Je les amènerais en petits groupes et je saurais que pendant longtemps la productivité ne sera pas proportionnelle à l'augmentation de la taille de l'équipe. Sachez également que la fuite des flux de trésorerie au cours des premiers mois peut être importante, en raison des coûts d'embarquement et des équipements.

Dans votre commentaire à Alex D, vous avez mentionné "Ce ne sont pas les délais que nous respectons, sa capacité démontrable à fournir de nouvelles fonctionnalités." Passez donc à un style de développement qui répartit les fonctionnalités en petits morceaux, et plus souvent. Demandez aux nouveaux membres de l'équipe de tester les nouvelles fonctionnalités, qui les aideront à comprendre la base de code.

Vous feriez mieux d'embaucher personne de nouveau et d'examiner vos processus pour voir où vous pouvez apporter des modifications pour accélérer les choses. Plus les bogues sont détectés tôt, moins il faut de temps pour les corriger, alors comment testez-vous? Faites-vous des révisions de code? Faites-vous attention à la qualité de l'exigence? Avez-vous des builds et des processus de déplotage automatisés? Avez-vous des tests automatisés? Organisez-vous des réunions quotidiennes (étonnant à quel point le développement peut aller plus vite quand quelqu'un vous demandera votre progrès tous les jours!)? Utilisez-vous des processus agiles? Avez-vous des défauts de conception de base à corriger pour accélérer le reste du développement (une mauvaise conception peut ralentir considérablement un projet de développement).

Veuillez lire le Mythical Man-month. Vous allez clairement avoir besoin de le faire pour pouvoir dire à la haute direction pourquoi elle fait les choix usés pour accélérer un projet. .

Vous voulez donc les jeter d'une falaise et voir s'ils peuvent voler? Je pense que lorsque vous découvrez des choses par vous-même, elles ont tendance à rester avec vous à long terme plutôt que de simplement vous proposer des solutions. Cependant, cela suppose que vous découvrez réellement de meilleures solutions. Je ne vois pas pourquoi vous ne pouvez pas permettre à cette équipe d'avoir un leader qualifié qui équilibrera les laissant faire des erreurs par eux-mêmes tout en leur donnant des conseils et des instructions en apprenant à partir d'exemples de qualité.