Comment informer les nouveaux membres de l'équipe du projet? [fermé]

Nous sommes sur le point d'embaucher 1 à 2 nouveaux ingénieurs pour l'équipe logicielle (composée de 3 développeurs, 1 testeur).

Quelles sont les étapes pour les intégrer dans l'équipe?

Mes idées sont:

• lire la documentation (normes de codage, documents dans les méthodologies de développement que nous utilisons)
• leur faire lire le code existant
• leur assigner des tâches simples
• à la fin, rendez-les responsables de la partie code

Que pourrions-nous faire d'autre?

Le projet se situe dans un secteur médical (échographe), et dure déjà 5 ans. Nous avons des versions annuelles, et nous sommes sur le point de terminer une version, lorsque nous voulons ajouter 1-2 ingénieurs.

Le projet est en phase de maintenance (refactoring du code hérité, plus ajout de nouvelles fonctionnalités). Les choses sont à peu près conformes au calendrier (plus ou moins).

Venant de quelqu'un qui a dû se familiariser avec de nombreuses bases de code différentes dans ma carrière, voici ce que je suggérerais:

1. Passez un peu de temps (peut-être un jour ou deux) aux activités liées à l'utilisation du produit afin qu'ils puissent se familiariser avec ce que fait le produit. Cela peut être la vérification de bogues, l'exécution de plans de test d'assurance qualité ou la formation des utilisateurs.
2. Travaillez sur de petits bugs localisés. Cela permet à l'ingénieur de savoir comment créer et déboguer l'application sans avoir à apprendre beaucoup d'architecture.
3. Idéalement, écrivez une petite nouvelle fonctionnalité localisée. Cela leur permet d'écrire un morceau de code et au fur et à mesure qu'ils l'écriront, ils se familiariseront avec les bits de code environnants avec lesquels leur nouveau code doit travailler.

À partir de là, étendez la portée et la complexité des missions au fil du temps en fonction du niveau d'expérience et des aptitudes de l'ingénieur. Cela permettra au développeur d'élargir naturellement sa connaissance de la base de code.

J'éviterais de lire uniquement les tâches (documentation ou code). La lecture de la documentation devient vraiment ennuyeuse très rapidement et la lecture de code aléatoire n'est pas utile car ils n'auront aucun contexte avec lequel travailler. Il est assez difficile de lire le code pour les révisions de code lorsque vous connaissez déjà le produit et la base de code. Je ne vois rien d'utile de voir un tout nouvel ingénieur lire le code.

Mon sentiment est que la tolérance de la plupart des gens à la lecture de la documentation est assez faible (bon pour un jour ou deux, mais au-delà, ils seront probablement impatients de faire quelque chose d'un peu plus pratique).

Je ne pense pas que vous puissiez vraiment comprendre le code d'une application sans une compréhension raisonnable de l'application elle-même. Le logiciel a vraisemblablement beaucoup de fonctionnalités avec lesquelles ils pourraient jouer avec l'utilisateur; ils devront éventuellement pouvoir le tester, donc je m'attends à ce qu'il soit assez important qu'ils sachent comment l'installer, le configurer et effectuer des tâches courantes avec.

Personnellement, je trouve qu'un aperçu de l'architecture de haut niveau est généralement très pratique pour avoir une idée de base du fonctionnement des choses - Peut-être allouer une heure ou deux du temps d'un ingénieur senior (ou vous-même si nécessaire?) Dans leur première semaine simplement pour passer par les nut'n'bolts de base de l'application principale. Par exemple, comprendre tous les sous-systèmes et comment les choses sont liées entre elles, savoir quels bits sont gérés par des logiciels / bibliothèques tiers et quels bits doivent être maintenus en interne. (À moins que votre organisation ne dispose d'une documentation à jour d'une qualité vraiment exceptionnelle, je suppose qu'il n'y a aucun moyen de maîtriser ce genre de choses sans que quelqu'un leur explique directement à l'aide d'un tableau blanc: - ))

Quant à leur donner quelque chose de "pratique", les tâches de maintenance / recherche de bogues peuvent être un bon moyen de les mettre à niveau pendant un certain temps (quelques semaines / mois?) - ils seront dans des situations où des domaines spécifiques de fonctionnalité doivent être compris, testés et débogués; aider à acquérir des connaissances sur le code, les exigences, les outils utilisés par l'entreprise, les processus de développement et le (s) produit (s) dans son ensemble tout en espérant ne pas avoir à prendre trop de temps du reste de l'équipe de développement

En tant que Lead, je passe au moins 2 jours avec de nouveaux développeurs. J'ai trouvé que le développement d'une relation dans laquelle il est confortable de poser la question inévitable "comment sont vos progrès?" est un MUST. Il y a de la peur dans toute nouvelle communauté à s'intégrer ... nous cachons les erreurs, agissons parfaitement, rendons les choses meilleures qu'elles ne le sont, atténuons les difficultés. Un manager qui passe 2 jours avec quelqu'un lui fera savoir que ce n'est pas sa culture et lui permet de montrer l'exemple. Les nouveaux codeurs ont besoin d'une leçon d'histoire sur d'où vous venez et où vous en êtes. Les documents ne rendent pas justice à la tâche.

Je ne travaille dans l'industrie que depuis 10 mois (en stage) mais j'ai trouvé que ce qui suit m'a aidé:

• Faire équipe avec d'autres développeurs et observer comment ils abordent les problèmes.
• Le test du logiciel a aidé, je devrais tester la fonctionnalité x, ce qui signifie que j'ai lu la documentation sur la fonctionnalité x. J'ai beaucoup fait ça, ça a aidé.

Ces deux éléments m'ont beaucoup aidé. Bonne chance.

Je passerais de haut en bas.

Démonstration de l'application dès que possible

L'une des choses les plus importantes est que le développeur a une idée de ce sur quoi il va travailler. Au cours de la démo, indiquez certaines des choses qui ont été récemment développées et la direction que prend l'application.

Expliquer l'architecture de haut niveau

Ceci est également très important. Laissez le nouveau développeur écouter et poser des questions. Faites-le comme un exercice de groupe avec les autres développeurs, qui, nous l'espérons, vous aideront et vous aideront. Cela permettra au nouveau développeur de savoir qu'il est correct de parler ouvertement et honnêtement.

Préparez un excellent document d'intégration

Avoir un bon document d'intégration n'aide pas seulement les nouveaux développeurs, mais aussi les anciens. Il peut contenir des attentes, des liens utiles et des informations sur la configuration de l'environnement. (Je ne peux pas vous dire combien de fois j'ai utilisé notre intégration pour configurer mon environnement lorsque j'obtiens un nouvel ordinateur ...) Cela devrait être bien structuré et pertinent et ne pas s'attarder et ne pas être un dépotoir pour chaque petit détail.

Encouragez-le à poser des questions (et à être disponible pour y répondre)

Avec les réponses, guidez-les, mais ne leur dites pas quoi faire. Donnez-leur des indices mais permettez-leur enfin de comprendre eux-mêmes.

Aidez les autres membres de l'équipe à accueillir le nouveau venu

Il y a deux côtés de la médaille lorsque quelqu'un rejoint une équipe. L'équipe doit également disposer des outils nécessaires pour accueillir le nouveau développeur.

Laissez-les prendre une petite tâche ou deux

Permettez-leur d'ajouter quelque chose de nouveau et visible au projet qui est démontrable. Quand il est démo, dites qui l'a fait et quel bon travail il a fait. Cela peut vraiment augmenter l'estime de soi. Plus vite ils se sentent comme s'ils ajoutent de la valeur, plus vite ils sentent qu'ils font partie de l'équipe. Plus vite ils se sentiront autorisés à faire de leur mieux.

Encouragez-les à se lancer dans des tâches plus difficiles une fois qu'ils se sentent de plus en plus à l'aise

Les bons candidats le feront naturellement.

Un flux "d'orientation" que j'ai traversé (et trouvé utile) était quelque chose comme:

1. Une brève présentation donnant le "Big Picture" ce que sont les composants, comment ils s'intègrent et l'architecture générale.
2. Une vue d'ensemble du code, une introduction aux fonctions qui gèrent la logique principale des composants qui m'ont été attribués. Couvert quelques trucs liés aux conventions de codage et au style.
3. Un tas de problèmes ouverts et de bogues de faible priorité ont été attribués (qui étaient largement localisés dans le composant qui m'a été attribué et assez simples).
4. Je devais déboguer via l'application et demander de l'aide pour des choses que je ne pouvais pas déchiffrer.
5. Une fois le correctif effectué, j'ai suivi le processus (révision de code, test au niveau du développeur, etc.) de la libération à l'intégration.
6. Répétez l'opération pour les tâches / bogues restants alloués.

Je pense que cette approche (et ses variantes) sera utile car:

• Il s'agissait d'une approche plus pratique et relativement indépendante (pas de prise de main constante, etc.). Ainsi, il fournit suffisamment d'espace / de temps pour que la nouvelle personne s'habitue au code et à la façon dont les choses sont faites dans l'équipe.
• Il est également bénéfique pour l'équipe dans son ensemble, car quelques tâches / bogues de faible priorité peuvent être résolus. La personne qui aide les nouvelles personnes a également plus de temps pour s'acquitter des tâches qui lui sont assignées, car une prise en main constante n'est pas nécessaire et du temps peut être spécifiquement prévu pour traiter les problèmes / problèmes auxquels la nouvelle personne pourrait être confrontée.

Les premières embauches ont besoin d'une tâche petite, mais pas trop petite et bien définie pour travailler. De cette façon, ils peuvent commencer à comprendre comment le code est structuré en essayant de comprendre comment accomplir leur tâche. Au cours du processus, des questions surgiront et à ce stade, vous pouvez les diriger vers la documentation ou d'autres ressources qu'ils peuvent utiliser pour les aider à internaliser la base de code. Cela aide également si votre cycle de développement, de validation et de déploiement est court et qu'ils peuvent voir les fruits de leur travail en action le plus rapidement possible.

Voilà comment je vais

1. Donnez-leur des tâches liées au projet (par exemple: si votre projet est une application de base de données, demandez-leur de créer simplement une application pour se connecter à la base de données et d'effectuer une opération simple).
2. Lorsque vous constatez qu'ils ont compris l'idée de travailler, faites-leur une démonstration du projet
3. Demandez-leur de lire la documentation.
4. Familiarisez-les avec les styles et les normes de codage
5. Plus tard, donnez-leur quelques exercices de débogage (pour connaître le déroulement du projet).
6. Demandez-leur de fixer un point que vous avez déjà fixé (juste pour découvrir leur logique avec lui).
7. Enfin, intégrez-les au projet.

N'oubliez pas: peu importe combien vous essayez, jusqu'à ce que et à moins que le conjoint ne comprenne complètement le projet, vous ne pourrez pas travailler plus efficacement avec lui.

Numéro un - apprenez d'abord à utiliser le logiciel pour découvrir les problèmes qu'il résout du point de vue de l'utilisateur. S'il n'a pas d'interface utilisateur (par exemple, c'est un service backend ou quelque chose), laissez-les utiliser n'importe quelle interface disponible pour le consommer. Obtenir une nouvelle vision de l'utilisateur sur votre logiciel est toujours bon, et cela pourrait aider le nouvel employé à voir des choses que vous ne pouvez pas, car vous êtes déjà intégré dans le projet.

Après cela, un bon premier projet pourrait être quelque chose comme un module complémentaire ou un nouveau module à ajouter au logiciel, minimisant la quantité de connaissances nécessaires de la base de code existante. Écrire quelque chose de nouveau sera toujours plus facile que d'effectuer une correction de bogue, ce qui pourrait nécessiter de nombreuses modifications dans de nombreux fichiers source. À mon avis, confier à un nouvel employé une tâche de correction de bogue va probablement le désactiver pour votre entreprise.

Votre plan pour familiariser les nouveaux avec le projet semble raisonnable. Mais gardez à l'esprit qu'ils auront beaucoup à apprendre au début. Il s'agit généralement d'une situation accablante. Vous devrez être patient et répondre aux mêmes questions à plusieurs reprises. C'est normal, les nouveaux développeurs doivent apprendre beaucoup, ne sous-estimez pas cela. Si vous vous fâchez à propos de ces questions répétées, vous risquez de ne pas les poser et d'essayer de trouver des choses seules qui peuvent être au mieux très lentes mais souvent impossibles. Ils devront également apprendre le jargon. La plupart des projets d'équipes développent leur propre langage. Lorsque vous expliquez consciemment, essayez d'éviter le jargon. Expliquez ce truc comme vous l'expliqueriez à votre maman. Encore une fois, soyez patient.

De plus, vous pouvez essayer de les intégrer aux autres membres de l'équipe en essayant certaines tâches de style du centre d'évaluation, par exemple construire un pont en 45 min à partir de 4 feuilles de papier supportant une tasse de café. Nous utilisons cette technique dans un cours pratique en génie logiciel pour amener un groupe de 8 étudiants à briser la glace avant de travailler sur un seul projet pendant 3 semaines. Cela aide à accélérer les phases de formation de l'équipe.

1) Donnez-leur une explication de vos règles et directives de code. Donnez également une explication générale du fonctionnement de votre application et de la structure générale du code.

2) Trouvez quelques petits bugs ou projets qui sont largement indépendants des autres codes. Expliquez ce qui doit être fait, où dans le code et vérifiez-les régulièrement.

3) Commencez lentement à leur donner des projets de plus en plus gros tout en les vérifiant de moins en moins.

4) Asseyez-vous de temps en temps à côté d'eux. Vous pouvez apprendre beaucoup en regardant simplement comment quelqu'un d'autre aborde un problème. De petites choses comme "oh, vous pouvez rechercher des fonctions dans votre code en appuyant sur ctrl-." sont très utiles.

Maintenant, j'ai trouvé qu'il y a deux extrêmes :

• Quelqu'un qui pose une question toutes les cinq minutes. "Que fait ce Path.Join?". Ils devraient d'abord Google pour une réponse et ne viennent à vous que lorsqu'ils ne trouvent pas de réponse.

• Et l'autre extrême, quelqu'un qui travaille une demi-journée sans poser une seule question. Ils devraient penser que c'est une bonne chose de poser des questions. Je veux juste qu'ils essaient d'abord eux-mêmes.

C'était ma formule et utilisée avec plusieurs nouveaux venus - ces étapes se sont avérées très efficaces.

a) Tous les nouveaux développeurs recevront une introduction sur les exigences du projet et les processus de développement pendant 2 jours.

b) Attribuer une tâche de 3 semaines pour écrire des tests Junit pour le code qui n'a pas une couverture suffisante.

c) Une fois que 3 est terminé, attribuez de petites tâches

d) Attribuer des tâches complexes et fait.

Je pense simplement assigner quelques petites tâches, leur demander d'écrire quelques tests unitaires, leur faire déboguer une régression échoue. Rien de trop grand ou de trop exigeant, mais assez pour les avoir sur pied.

Vous devez également désigner un développeur senior, de préférence par nouveau développeur, qui pourrait aider à encadrer le candidat.

Et oui, faites-leur documenter ce qu'ils apprennent sur le système. Je suppose ici que vous avez une sorte de pages wiki internes. Sinon, c'est définitivement un must à la fois à court et à long terme - un moyen étonnamment rapide pour que les gens montent en puissance. Les pages Wiki ne doivent pas contenir uniquement la documentation du code, mais aussi des éléments comme les limitations connues (il s'agit du logiciel: D), les solutions de contournement, les mesures de performances temps / mémoire, etc.

N'expliquez pas seulement les bonnes pratiques et les normes de codage, mais expliquez comment le code lu est structuré. Expliquez ce que le logiciel est censé faire et comment cela est ou sera réalisé.

Ils ne comprendront pas tant qu'il n'y aura pas de travail à faire, je suggère donc de diviser en deux parties, une avant de commencer le vrai travail et la deuxième partie, après avoir commencé à travailler. Ils vont chercher dans du code ou des documentations et penser " WTF !? ". Lorsque cela se produit, quelqu'un les accompagnera et expliquera les détails mineurs.