Comment ajouter un nouveau développeur à l'équipe

Je dirige une petite entreprise composée de seulement 2 développeurs. Nous construisons une très grosse application pour l'un de nos clients. Le développement de ce projet dure depuis un an et demi.

Maintenant, ce client a obtenu un parrainage important et il organise des événements liés à ce projet. Alors maintenant, nous avons un délai de 2 mois et nous ne pouvons pas le manquer.

Nous envisageons d'ajouter un nouveau développeur à l'équipe, et je me demande ce que nous pouvons faire pour faciliter son intégration.

Voici la situation:

• Nous approchons du seuil de la loi de Brooks - le point où l'ajout de nouveaux développeurs sera contre-productif.
• L'application est relativement bien conçue, mais l'implémentation est chaotique à certains égards (en particulier le code plus ancien).
• Il existe des tests unitaires uniquement pour les codes plus récents. Lorsque ce projet a démarré, nous n'avons pas effectué régulièrement de tests.
• La documentation et les commentaires sont incomplets.
• L'application est à la fois grande et complexe.
• Le client a écrit presque tous les détails de son projet, d'une manière très claire et "conviviale".

Est-ce une bonne idée d'ajouter une personne maintenant? Si oui, que pouvons-nous faire pour aider le nouveau développeur à s'intégrer dans l'équipe?

MODIFIER:

Le commanditaire organise un événement sportif sur Internet pour le printemps prochain. Il doit commencer un jour spécifique de l'année. Nous ne pouvons pas le changer.

Ce que nous, les développeurs (je suis l'un des deux), devons faire, c'est:

• Compléter la demande existante (environ 25% du travail à faire).

• Création d'un nouveau module, indispensable à l'organisation de cet événement (environ 75% du travail à faire). Ce nouveau module ne peut pas être développé sans comprendre l'API du programme principal.

Je ne peux pas faire d'estimation de temps exacte, mais nous sommes dans une situation à risque.

La meilleure chose à faire est de ne pas jeter le nouveau développeur dans le feu, mais de se tailler des fonctionnalités et / ou des corrections de bugs que le développeur ne devrait avoir aucun problème à résoudre. Trouvez un domaine qui nécessite un travail qui ne nécessite pas qu'une personne connaisse l'ensemble de l'architecture, des exigences et de la base de code à la fois. Peut-être demandez-lui de travailler sur la documentation pour apprendre le système plus rapidement.

Plutôt que d'ajouter un nouveau développeur à l'équipe, pensez à ajouter un consultant expérimenté pour la période de deux à trois mois pour gérer l'augmentation temporaire de la charge de travail de votre entreprise. L'idée est d'avoir quelqu'un qui peut gérer un temps de démarrage proche de zéro, mais en même temps, ce n'est pas nécessairement le meilleur ajout à votre équipe.

Même si vous pensez que l'augmentation de la charge de travail n'est pas temporaire, ce n'est probablement pas le meilleur moment pour développer votre équipe de manière organique: l'ajout d'un troisième développeur est une chose stressante pour une équipe même sans pression de la date limite du projet; un délai serré ne fait qu'empirer la transition.

Le compromis est qu'en échange d'une aide temporaire, vous obtiendrez du code écrit par un étranger. Pour atténuer ce risque, assurez-vous que vous effectuez tous les deux des révisions de code avec lui. Assurez-vous également de revoir et de comprendre tous ses tests unitaires.

Est-ce une bonne idée d'ajouter une personne maintenant?

Non. Si possible, essayez plutôt de faire en sorte que le client accepte de réduire la portée.

L'ajout d'une personne si tard entraînera un risque important et le délai ne peut pas être repoussé (pour autant que je sache).

Ne le fais pas.

Encore.

Vue traditionnelle

Dans votre question, vous faites référence à la loi de Brooks du Mythical Man-Month .

L'ajout de main-d'œuvre à un projet logiciel tardif le fait plus tard.

Ignorer la loi de Brook a un prix. Ne faites pas plusieurs tâches. Concentrez-vous sur la livraison de votre produit minimum viable (MVP). Ensuite, concentrez votre énergie sur le recrutement, les ressources, la formation et la gestion d'un nouveau membre de l'équipe.

Deux mois, c'est si court. Planifiez le recrutement avec une liste déroulante et vous verrez à quel point cela peut prendre du temps.

Larry Page et Sergei Brin ont passé deux ans à choisir l'équipe initiale de Google. Votre choix pour l'employé numéro trois doit également être prudent.

Agile, nouvelle vision du millénaire

La compétition stimule les équipes dynamiques plus maintenant qu'à l'époque où Mythical Man-Month a été écrit (milieu des années 1960). De longues carrières dans une entreprise ont disparu. Maintenant, nous migrons fréquemment entre les projets et les entreprises. Un team building rapide est un succès. La lente montée en puissance est un facteur limitant sévère. De grands exemples proviennent de projets open source, de startups et de l'utilisation accrue de projets d'équipe dans les cours d'informatique.

Potentiellement, les équipes Agiles tiennent compte des contraintes dans leurs plannings. Ils ne sont pas en retard car ils sont optimisés en fonction des ressources disponibles. L'intégration de nouveaux employés est une contrainte de plus et est considérée comme un compromis entre les objectifs à court terme et à long terme. L'équipe Agile intègre continuellement du code, alors pourquoi pas les gens aussi?

L'intégration technique et sociale d'une équipe agile pour les nouveaux employés peut utiliser:

• mêlées quotidiennes
• programmation en binôme
• refactoring
• ajout de tests unitaires manquants
• enrichir la documentation allégée
• revues de code

L'agneau sacrificiel

Dans " Modèles organisationnels de développement de logiciels agiles", James Coplien discute de la dynamique de groupe et des coûts de l'ajout de nouveaux membres de l'équipe. Son modèle "Sacrificial Lamb" assigne tout le mentorat et la formation à une seule personne, protégeant le reste de l'équipe contre les interruptions.

C'est une stratégie que vous voudrez peut-être envisager de mettre en œuvre.

Une autre stratégie consiste à affecter un ou plusieurs nouveaux mentors qui couvrent les questions des nouveaux employés pour des heures particulières chaque jour. Si vous ne pouvez épargner qu'un seul gars, il travaille peut-être sans interruption le matin ou l'après-midi et répond aux questions respectivement l'après-midi ou le matin. Le groupe dans lequel je faisais avait dix stagiaires l'été dernier, donc beaucoup de gens ont été souvent interrompus.

Actuellement, le mentorat est assuré par une seule personne, principalement pendant et immédiatement après notre mêlée matinale (de 8 h 30 à 9 h 15 environ) et l'après-midi de 12 h à 15 h 30 (il travaille de 7 h à 15 h 30). pm).

Je suis heureux que vous ayez mentionné la loi de Brook. Bien fait. Le principal problème avec l'ajout d'un autre développeur est la surcharge de mise à niveau et la surcharge de synchronisation avec eux sur la position du projet. Par conséquent, si vous décidez d'obtenir un troisième développeur, j'essaierais ceci:

• Donnez au nouveau gars un endroit où les coûts de mise à jour sont bas et il peut commencer le plus rapidement possible. Cela dépendra beaucoup de qui vous embauchez et de leurs compétences.
• Assurez-vous que cette zone est faiblement couplée avec d'autres zones de l'application afin que la surcharge de synchronisation soit moindre. L'envoyer pour faire un travail intense de DB et réorganiser les tables peut être trop.
• Faites ce que vous pouvez pour garder le moral. Comme d'autres l'ont fait remarquer, l'ajout d'un nouveau membre de l'équipe peut être stressant, alors peut-être qu'un investissement dans des boissons gazeuses pourrait aider.

Si vous suivez strictement la loi de Brook, vous ne ferez probablement jamais grandir votre équipe.

L'astuce consiste à faire venir la nouvelle personne sans se faire frapper avec trop de ralentissement sur votre équipe actuelle. Finalement, la nouvelle personne sera à la hauteur et vous pourrez surmonter la bosse.

Dans ton cas? Je recommanderais à la nouvelle personne d'écrire tous ces tests unitaires manquants.

1. Celles-ci sont absolument nécessaires comme protection contre les erreurs de régression, qui vous brûleront plus rapidement que tout ralentissement de Brooks.
2. Une nouvelle personne apprendra les tripes de votre système. C'est un peu un essai par le feu - mais leur sortie ne va pas dans le code de production, donc peu de risques là-bas.
3. Fixez une limite stricte sur le temps qu'ils peuvent consacrer aux autres membres de l'équipe. Par exemple, demandez-leur de faire la queue pour les questions, et ne permettez que 30 minutes par jour d'interagir avec les autres membres de l'équipe jusqu'à la date limite.

Aussi, avouons-le: vous devrez gérer la portée et les attentes des clients, que vous ameniez une nouvelle personne ou non. Le gain vient le cycle suivant.

Ed Yourdon a fait un excellent commentaire sur la loi de Brook. Il a déclaré: bien sûr, l'ajout de personnes vous ralentira - mais lorsqu'un projet est en danger, c'est le seul moment où la gestion fera appel à de nouvelles personnes. Alors: prenez-les, minimisez l'impact sur la version actuelle et débarrassez-vous des mauvais artistes dès que possible. De cette façon, au fil du temps, vous pouvez construire une équipe solide.

Si vous avez du travail sur d'autres projets que vous pouvez lui donner, cela libérera du temps pour que les 2 développeurs actuels se concentrent sur les livrables à grande échéance qui pourraient aider.

Vous dites que vous devez terminer 25% du travail original, plus un nouveau travail. Et vous devez le faire en deux mois - alors qu'il vous a fallu 18 mois pour effectuer 75% du travail. Pour être très franc, cela m'indique que vos capacités d'estimation sont à peu près moyennes pour un programmeur axé sur le code - c'est-à-dire que vous pensez que les choses vous prendront environ la moitié à un tiers aussi longtemps qu'elles le feront réellement.

Heroics peut vous permettre de livrer le produit pour lequel vous avez passé un contrat, mais cela ne vous rendra aucun service à vous ou à votre client. Il sera de mauvaise qualité et dépourvu de bogues dans ces conditions, et vous fonctionnerez avec des fumées.

Gardez à l'esprit que le temps que vous passez à l'embauche aura également un impact majeur sur votre disponibilité - ce n'est pas quelque chose que vous pouvez simplement faire un week-end, il faut du temps pour trouver des employés talentueux qui correspondent bien. Attendez-vous à passer au moins quelques semaines à chercher, interviewer, etc. Attendez-vous à ce que vous et votre employé actuel perdiez environ 10 heures par semaine de temps productif pendant votre recherche.

Ma recommandation:

Asseyez-vous avec votre client, expliquez que vous êtes au-dessus de votre tête et travaillez avec lui pour réduire la portée au strict minimum.

Modifier Je viens de voir la date ici. Alors, comment at-il fini? (Merci Ars Technica d'avoir posté une question vieille de trois mois;)

Il y a plusieurs façons d'envisager une enquête:

1. Retenez d'embaucher le nouveau développeur jusqu'à ce que la date limite soit passée afin qu'il soit plus facile de se concentrer sur la transmission des connaissances du domaine au nouveau gars. Ce serait ma préférence car cela pourrait être légèrement difficile à plusieurs égards.

2. Amenez le nouveau développeur à travailler sur la documentation, les tests unitaires et d'autres choses qui ne changent pas le code existant. Ce serait ce que je suggérerais si vous amenez le nouveau gars à essayer de minimiser l'impact sur la charge de travail actuelle.

La date est déjà passée, mais pour tous ceux qui le liront plus tard.

L'essentiel à considérer est que le client dans cette situation a beaucoup plus à perdre que vous. Ils ont déjà dépensé beaucoup d'argent et un événement clé se prépare qui pourrait faire ou défaire leur entreprise. Vous avez déjà leur argent et perdre un seul client ne devrait pas ruiner votre entreprise. Si c'est le cas, alors vous avez d'autres problèmes commerciaux graves au-delà de la terrible gestion de projet.

Votre meilleur pari est de négocier un sous-ensemble essentiel de fonctionnalités, puis de faire des heures supplémentaires pour le faire. Si vous ne pouvez pas créer un sous-ensemble plus petit ou si vous n'êtes pas disposé à faire des heures supplémentaires dans cette situation, vous ne devriez probablement pas être en affaires. Cela peut signifier mettre d'autres clients en attente, mais je suppose que vos autres clients n'ont pas payé pendant 3 années-homme, alors mettez vos ressources là où se trouve l'argent.

S'ils ne sont pas prêts à négocier la portée, vous êtes prêt à échouer.

Il n'y a aucune chance de livrer ce projet complètement dans les délais. Si vous pensez qu'il vous reste 25% sur un projet qui a pris 18 mois à livrer jusqu'à présent, alors il vous reste au moins 6 mois (sur ~ 2 développeurs). L'ajout d'une autre personne ne changera pas cela de manière significative.

Comme cela a été souligné, le recrutement prend du temps. D'après mon expérience, cela prend un mois au minimum. Ajoutez ensuite la formation et votre temps est écoulé.

J'espère que cela a fonctionné pour vous.