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?

12

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.

Dmitry Negoda
la source
2
si vous embauchez plus de développeurs, vous ne perdez de productivité que dans les premiers mois - je n'en ai jamais entendu parler, mais je suis sûr que c'est plus
BЈовић
2
Que se passe-t-il lorsque vous essayez de réintégrer les deux parties ensemble? Y a-t-il une chance que les deux pièces passent chacune leurs propres tests, mais un gros test d'intégration sur l'ensemble du lot échouera? Je soupçonne que vous allez constater que la loi de Brook n'est pas si facilement contournée. Excellente pensée créative cependant; vaut un +1. Et j'aimerais vraiment savoir comment cela fonctionne pour vous.
Dawood dit de réintégrer Monica le
1
javana: Nous allons embaucher des développeurs expérimentés
Dmitry Negoda
2
@DmitryNegoda Si vous pouvez les trouver en temps voulu. Les développeurs expérimentés ne sont généralement pas au chômage, même si vous les interviewez et leur offrez un poste demain, ils devront probablement donner à leur employeur actuel un préavis de quelques semaines avant de pouvoir même commencer. Si j'étais vous, je préparerais un plan d'urgence au cas où, comme se préparer à travailler les nuits et les week-ends pendant un certain temps.
maple_shaft
4
peu importe à quel point un développeur que vous obtenez est incroyable, il ne comprendra pas 100 000 lignes de code en moins de ~ 1 mois peut-être 3 semaines
Ryathal

Réponses:

1

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.

umlcat
la source
Nous ne parlons que de 100 000 lignes de code, ce n'est pas si complexe, cependant merci pour l'inquiétude
Dmitry Negoda
1
@Dmitry Negoda: la complexité n'est pas fonction du LOC.
jmoreno
Il y a des recherches considérables (par exemple par Boehm) qui montrent que la productivité du programmeur, en moyenne, est fonction du LOC.
Dmitry Negoda
15

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.

Caleb
la source
1
+1 à l'ensemble d'exigences écrites, elles sont un peu dépassées ...
Dmitry Negoda
3
Et qui va interviewer ces nouvelles recrues, mettre à jour les exigences écrites et les documents de conception, remplir la base de données de bogues, passer du temps sur les sessions de formation ... ?? Est-ce les développeurs actuels? Parce que cela signifie qu'ils ne se développeront pas à temps plein. La vitesse de développement diminue donc . Oups.
MarkJ
Le code est auto-documenté, et nous n'engagerons que des développeurs expérimentés. Et oui, les développeurs actuels aideront les nouveaux, et leur vitesse baissera un peu. J'espère juste que l'embauche de développeurs dans le projet de locomotion 100K ne sera pas aussi pénible que l'embauche dans le projet de locomotion 270K, et c'était la question.
Dmitry Negoda le
Avez-vous un wiki interne ou tout est-il stocké dans des documents Word dispersés sur le LAN?
Spencer Rathbun
1
100k, 50k ou 10k représenteront tous la même chose - une tonne de code que personne ne transfèrera dans leur tête. S'il y a plusieurs centaines de lignes de code, c'est raisonnable. Une fois que vous en avez dépassé plusieurs milliers, votre système est complexe et les souhaits de vitesse ne sont souvent pas atteints.
Michael Durrant
12

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

Péter Török
la source
4
+1 - vous voulez certainement utiliser vos anciens développeurs pour intégrer les nouveaux gars. Bien qu'il soit inévitable que cela vous ralentisse un peu.
mikera
+1 également. Vous voulez que vos développeurs chevronnés encadrent les nouvelles personnes. Même si les nouveaux gars ont beaucoup d'expérience, ils ne sauront pas exactement comment votre entreprise fait les choses.
Andy
9

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.

Alex D
la source
Il n'y a pas encore de délais. Nous nous attendons à une augmentation importante du nombre de clients potentiels en créant des partenariats. Nous voulions juste que notre solution soit plus compétitive, pour que les partenaires nous choisissent. Ce ne sont pas les délais que nous respectons, sa capacité démontrable à offrir de nouvelles fonctionnalités. Mais merci pour l'inquiétude.
Dmitry Negoda
Si tel est le cas, peut-être plutôt que de viser à doubler votre rythme de développement en une seule étape, vous pouvez peut-être essayer de "monter en puissance" sur une période de temps.
Alex D
4

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.

mhoran_psprep
la source
Je ne comprends pas comment le test de nouvelles fonctionnalités aidera à comprendre la base de code. Nous recrutons également des ingénieurs QA, alors laissez les développeurs développer et tester les testeurs.
Dmitry Negoda
2

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

HLGEM
la source
Oui à toutes vos questions sauf la dernière.
Dmitry Negoda
0

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

JeffO
la source
Mike Partridge a changé ma question. Je ne vais jeter personne de la falaise. Bien sûr, les nouveaux développeurs travailleront avec les expérimentés, uniquement sur un sous-projet différent.
Dmitry Negoda le
J'espère juste que l'embauche de développeurs dans le projet de locomotion 100K ne sera pas aussi pénible que l'embauche dans le projet de locomotion 270K, et c'était la question.
Dmitry Negoda du