Passer d'un projet individuel à un projet d'équipe à l'avenir. Que dois-je faire maintenant en préparation et qu'est-ce qui peut attendre?

Pour élaborer, je suis intéressé à savoir ce que les gens pensent que vous devez mettre en place tout en étant un projet individuel (contrôle des sources d'équipe, documentation, builds, etc.) et quelles choses ne doivent pas être faites jusqu'à ce moment où la deuxième personne arrive sur le projet.

Quiconque ayant une expérience de la progression dans ce scénario, ses idées seront appréciées.

Ce que j'ai appris. (J'ai essayé un ordre différent. J'avais tort. C'est l'ordre dans lequel les choses deviennent pertinentes.)

1. Mettez tout dans le contrôle du code source. Utilisez quelque chose auquel tout le monde a accès et commencez dès maintenant . Aucune exception. Pas de retards. Pas d'excuses.

2. Créez un espace QA / Test totalement séparé de votre environnement personnel de "travail" ou de "développement". Au moins un ID utilisateur distinct. Idéalement sur une VM distincte.
   Complètement séparé. Aucun chevauchement possible avec votre environnement de travail actuel.

3. Arrêtez les tests au-delà du test unitaire dans votre propre environnement de travail. Code et test unitaire que vous faites "comme vous-même". Tous les autres tests (intégration, performances, etc.) que vous effectuez sur la machine virtuelle séparée. Ne testez jamais vous-même. Testez toujours en tant qu'utilisateur QA distinct. Idéalement sur une VM distincte.

   «Ça marche pour moi», c'est une mauvaise chose à dire aux membres de votre équipe. Très mauvais. Vous devez comprendre ce qu'ils font de mal. Plusieurs fois par jour.

4. Prévoyez de tout noter. Utilisez un outil de balisage en texte brut (RST ou Markdown ou autre) pour que toute la documentation soit en texte brut dans le référentiel de contrôle de version. Un outil peut créer des pages HTML (par exemple, Docutils pour RST) ou PDF ou tout ce qui semble le mieux. N'utilisez pas de formats de document propriétaires (c.-à-d. MS-Word). Ils peuvent ne pas bien fonctionner avec certains systèmes de contrôle de code source.

5. Les premières choses que vous devez noter sont les suivantes.

   • Comment créer un environnement de développement fonctionnel. En cas de doute, créez une machine virtuelle et effectuez toute l'opération sur cette machine virtuelle. Assurez-vous que les étapes fonctionnent vraiment et que la documentation est claire . Lignes réelles tapées avec le type de clarté de la ligne de commande réelle.

   • Comment exécuter la suite de tests unitaires. Encore. Assurez-vous que les instructions fonctionnent et ne nécessitent pas de réflexion. "Tapez ceci:" "Confirmez que:" genre de choses. Ce n'est pas que les membres de votre équipe soient stupides. C'est que vous ne vous souvenez pas de ce que vous supposez, sauf si vous écrivez tout cela.

   • Comment exécuter la suite de tests d'intégration.

   Ne perdez pas beaucoup de temps à décrire l'architecture ou les principes de conception. Vous devez d'abord faire fonctionner quelqu'un. Vous pourrez expliquer des choses plus tard.

6. Les prochaines choses à documenter sont les user stories. Et les cas de test qui soutiennent ces histoires. Et les montages de données requis pour les cas de test qui prennent en charge ces user stories.

   Vous allez partager cela. Il passe sous contrôle de code source.

7. Finalement, vous pouvez documenter les 4 autres vues.

   • La vue logique est utile pour documenter. Les photos sont acceptables ici. Cela a tendance à évoluer rapidement, alors ne perdez pas de temps à capturer les informations héritées. Trouvez un moyen de coopérer avec les membres de votre équipe.

   • La vue du processus est souvent utile. Dépend de l'application globale de son importance.

   • La vue de développement - modules, bibliothèques, frameworks, etc. - est souvent décrite de manière informelle. Une image peut aider, mais il est notoirement difficile de la rendre suffisamment complète pour que quelqu'un puisse prendre un document et en faire des têtes ou des queues. Même les projets établis depuis longtemps et très publics ont une documentation de bibliothèque qui est tout simplement ignorée. (Menant à beaucoup de questions de débordement de pile.)

     En plus d'être acceptable pour être informel, cela a tendance à changer rapidement.

   • Informations sur le déploiement. Les serveurs. Adresses IP. Informations d'identification de la base de données. Tout ça doit être écrit. Finalement.

Outils et méthodologie

De quoi a-t-on besoin pour collaborer avec succès et être productif?

• Identifiez les parties / composants de votre projet: Distinguez clairement les différentes parties (base de données, couche d'accès aux données, site Web, service, API, projets de test, scripts de construction, ...) et les environnements (développement, mise en scène, production) et nommez-les a un impact constant sur votre communication orale et écrite (documentation, noms de projets, ...)
• Utilisez un système de gestion de code source (au cas où vous ne l'auriez pas encore fait). Pensez à l'utilisation de la branche avec votre projet et votre configuration.
• Automatisez vos builds - simplifiez au maximum la configuration d'un environnement à partir de votre référentiel source.
• Les projets de test sont indispensables sur les grands projets, du moins pour les projets plus complexes.
• Utilisez un ou plusieurs environnements de mise en scène où votre projet est prêt à être utilisé. Créez et gérez également des exemples de données pour une configuration de transfert automatisée.
• Utilisez un système de suivi des bogues qui peut aider à hiérarchiser et à planifier le développement, et sert également de mémoire pour les bogues passés et la façon dont ils ont été résolus.
• Documentez chaque partie de votre projet, certaines plus que d'autres. Personnellement, j'aime: Aperçu - Architecture - Dépendances - Configuration - Problèmes courants (d' ici ). Parfois, moins c'est plus - afin de ne pas laisser votre documentation devenir obsolète, il vaut mieux être concis et laisser la documentation faire partie de votre activité quotidienne.

Gestion / travail d'équipe

... ou autre chose au niveau interpersonnel

• Définissez vos attentes envers l'autre développeur. Soyez raisonnable, personne n'est susceptible d'apporter la même implication et la même passion que vous - du moins pas dès le départ. Communiquez ce que vous attendez ou non, définissez vos responsabilités et celles de l'autre. Tout le monde n'est pas ingénieur, architecte, développeur, dba et administrateur système, mais si c'est ce que vous recherchez, choisissez la bonne personne ou vous serez déçu.
• Dans un premier temps , définissez les tâches avec précision , puis examinez et discutez les résultats. Progressivement, commencez de moins en moins la micro-gestion. L'idée est de bâtir la confiance et d'augmenter la responsabilité.
• Planifiez votre projet , fixez des objectifs pour votre projet et pour votre équipe pour la prochaine année. Notez-le et vérifiez-le plus tard, cela donnera une perspective . Ces objectifs peuvent ou non être communiqués aux autres (tant qu'il s'agit d'objectifs que vous devez atteindre, pas d'autres), il peut simplement s'agir de votre propre liste de contrôle.
• Prenez une journée pour préparer et planifier le premier mois (ou les deux / trois mois) de votre nouveau développeur. Je trouve cela extrêmement motivant de travailler avec des gens bien préparés. Personne ne devrait avoir l'impression que son temps est perdu.
• Lâchez . C'est votre bébé, il devrait aussi appartenir à quelqu'un d'autre. Permettez à l'autre de devenir un expert meilleur que vous, au moins dans certaines parties du projet. Cela signifie que vous avez réussi.
• Écoutez - si vous l'avez embauchée, elle a quelque chose à dire. Soyez prêt à apprendre.
• Soyez prêt à partager vos connaissances et votre expérience (et par conséquent, soyez patient).
• Des erreurs seront commises, c'est la façon dont elles sont traitées et ce que tout le monde apprend à leur sujet qui compte.
• Accordez-vous du temps pour apprendre et expérimenter

Références de livres

Je vais énumérer quelques-uns des livres couramment mentionnés que j'ai réellement lus et je pense que cela vaut la peine d'être lu, pour une description plus détaillée ou pour plus de livres, vous voudrez peut-être consulter certaines des questions sur SO demandant exactement cela, comme telle ou telle question.

Ces livres méritent vraiment d'être lus en ce qui concerne les équipes, les organisations et les projets de programmation:

• Peopleware
• Mois de l'homme mythique
• Estimation logicielle, démystifier l'art noir

Aucun de ceux-ci ne sont des guides pratiques sur la façon de mettre en œuvre la méthodologie X (à l'exception de l'estimation du logiciel, ce manuel vous aide à choisir un processus d'estimation approprié). Bien sûr, les livres plus axés sur la programmation elle-même comme Code Complete sont également très enrichissants.

Je vais parler de l'expérience, mais gardez à l'esprit que tout le monde est différent. Ces choses ne sont pas universelles.

Une chose est de le laisser aller personnellement. Ce projet est quelque chose avec lequel vous avez vécu et vécu pendant 18 mois - vous voudriez naturellement que chaque changement soit comme vous le feriez. Donnez un tampon pour qu'un collègue fasse des erreurs, apprenne. Créez une salle pour qu'ils soient utiles. Et gardez à l'esprit que cela pourrait ne pas arriver tout de suite. Ce serait également formidable s'il y a quelque chose, une partie du code qu'ils peuvent sentir qu'ils réussissent à améliorer ou à créer, qui ressemble à du succès dans un court laps de temps. La patience et la tolérance ont un bon taux de rentabilité ici. N'essayez pas de microgérer, et si vous voulez critiquer, dire "vous avez tort", assurez-vous d'avoir un mérite, vous pouvez le prouver, ce n'est pas un combat "religieux".

Un autre problème clé est de trouver la bonne personne pour vous. Idéalement, il vaut mieux trouver quelqu'un de plus intelligent que vous. C'est subjectif et relatif, mais si vous sentez qu'une personne a des connaissances et des compétences que vous n'avez pas, c'est pour le mieux. Ce sera une collaboration mutuellement enrichissante.

Il y a deux façons de procéder: le collègue sera un frein et vous finirez par refaire ce qu'il ou elle a fait, ou les compétences de deux d'entre vous se multiplieront, pas seulement s'additionneront, et vous apprécierez vraiment de travailler ensemble.

Sur un sujet de "code propre, rapide et réutilisable" - je suggère lors d'une interview, de demander à écrire un petit micro-noyau / gestionnaire de service et / ou exécuteur de poste. Découvrez comment les composants enfichables sont spécifiés et configurés. Ne doit pas être terminé, c'est une pensée qui compte. Et aussi vous apprendrez rapidement des gens qui savent bien le faire voudront de l'argent décent ;-) Bonne chance!

Mon point de vue: commencez par documenter l'architecture de votre projet interne pour quelqu'un ... qui ne le connaît pas. Essayez d'expliquer quelles hypothèses sont en place et quand / où vous vous êtes détourné des pratiques courantes et pourquoi.

Automatisation de la construction: Excellente idée, puis-je ajouter une automatisation de la configuration pour une machine de développement. Le plus simple est de construire plus il sera (donc plus / plus rapide de déploiement de tests).

Une autre idée (cela m'a beaucoup aidé une fois): demandez au nouveau développeur de faire des tâches de nettoyage à petite échelle dans différentes zones de votre base de code, afin qu'il s'habitue aux outils de mise en page, etc. Une bonne idée est de supprimer les zones obscures qui pourraient ajouter de la confusion plus tard (exemple: si vous avez utilisé emmm python pour deux lignes d'un script shell quelque part et que votre projet est basé sur java, demandez à ces deux lignes d'être réécrites en java afin que le développeur # 3 doive savoir moins pour travailler)

Je me concentrerais sur l'automatisation de tout ce qui nécessite un travail manuel, donc peut être foutu par une personne inexpérimentée . Qui, sur la base de votre bref commentaire ci-dessus, comprend les éléments suivants:

• installer le contrôle de version et remplacer les sauvegardes manuelles par des sauvegardes automatisées,
• configurer le déploiement automatique autant que possible (au minimum, écrivez un script à déployer via FTP plutôt que de le faire à la main.

Si vous ne le faites pas, soit vous serez enchaîné pour faire ces tâches pour toujours, soit (certains) les nouveaux gars vont inévitablement gâcher quelque chose tôt ou tard.

Comme @dimitris l'a noté, l'autre tâche importante est la documentation. @S. Lott a ajouté beaucoup plus de détails à ce sujet, il suffit donc de lui attribuer +1 plutôt que de répéter :-)

Voici quelques réflexions, basées en partie sur l'expérience personnelle:

• Documentez votre projet. Les spécifications de conception, les diagrammes, les manuels et les commentaires aideront le nouvel employé à se mettre au courant. Expliquer un système complexe uniquement verbalement peut s'avérer lent et frustrant. La documentation est souvent négligée dans les projets individuels. Assurez-vous que le vôtre est une exception.

• Dans un premier temps, concentrez-vous sur le code de niveau API / core vous-même, tout en donnant au nouvel employé un travail de "couche d'application" ou une correction de bogue pour le familiariser progressivement avec le code. En général, commencer avec plus facile , mais significatifs et donc récompenser les tâches .

• La communication est importante. Soyez attentif aux questions, commentaires et idées du nouvel employé. Expliquez pourquoi vous pensez qu'une idée n'est pas bonne si vous le faites. Une nouvelle paire d'yeux peut surprendre étonnamment bien. Si votre nouvel employé est décent, il peut revoir votre code par les pairs et éventuellement participer aux décisions architecturales. Discutez, faites rebondir vos idées. C'est l'un des plus grands avantages d'avoir un collègue sur votre projet.

• Définissez clairement les responsabilités , une fois que vous savez à quel type de tâches appartient votre nouveau membre de l'équipe. Établissez des pratiques de documentation et des conventions de codage pour garder les choses en douceur.

• Utilisez un système de contrôle des révisions . Maintenez une disposition logique du fichier source et développez la discipline .

Quant à l'entretien - je ne suis pas un grand fan des tests de codage artificiel ou des questions pièges, à moins que vous ne souhaitiez essayer la capacité de résistance au stress du candidat. Même le plus intelligent des résolveurs de problèmes peut s'enfermer dans une telle situation. Les qualités que vous rechercherez, entre autres, sont: l' honnêteté , la capacité professionnelle , les connaissances / connaissances technologiques , l' enthousiasme et la compatibilité mutuelle . L'atmosphère de travail peut signifier beaucoup; il est déconseillé de choisir un coéquipier que vous n'aimez pas. Posez vos questions correctement et faites une discussion informelle pour obtenir une bonne image de votre candidat. Bonne chance!

La technologie

Si vous invitez quelqu'un d'autre en tant que développeur, il y a trois choses clés que je recommanderais d'avoir en place avant de commencer.

1. Contrôle de source
2. Suivi des problèmes
3. Intégration continue

Si ces trois choses fonctionnent correctement, vous éliminerez environ 75% du problème courant qui se produit lorsque vous recrutez un nouveau membre de l'équipe. Le point de ces technologies est de prendre une grande partie de ce qui se passe uniquement dans votre tête et de le faire sortir où les membres de votre équipe peuvent interagir avec.

Le contrôle de source s'assure que vous travaillez tous les deux sur la même chose. Le suivi des problèmes vous aide à garder une trace de ce qui doit être fait et vous permettra de savoir plus facilement sur quoi ils travaillent et accomplissent. L'intégration et les tests continus vous aideront à vous assurer que vous disposez d'un processus de génération reproductible et que les nouvelles améliorations ne cassent pas d'autres parties du code.

Le programmeur pragmatique a de très bons livres à ce sujet. En voici quelques-unes que je recommanderais. Ils ont d'autres titres similaires en fonction du langage de programmation que vous utilisez ou du contrôle de version que vous souhaitez utiliser:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog. com / titres / auto / pragmatique-projet-automation

Personnel

Souvent, les difficultés que vous rencontrerez sont moins du côté technique des choses que de l'apprentissage du lâcher-prise. Il peut être difficile de donner à quelqu'un d'autre le contrôle sur les aspects du projet - en particulier si vous avez l'habitude de tout faire vous-même et de prendre chaque décision. Vous vous épargnerez du chagrin si vous pouvez trouver un domaine où vous pouvez faire travailler la nouvelle personne avec une quantité raisonnable de liberté au début afin que vous puissiez développer une fondation de confiance. Si vous embauchez une bonne personne, la principale chose que vous apprendrez probablement est de savoir comment faire confiance à l'autre personne pour faire du bon travail, même si toutes ses décisions individuelles ne sont pas les mêmes que celles que vous auriez prises.

Vous voulez donner à votre nouvel embauché la liberté de résoudre les problèmes de la manière qui lui convient tout en gardant les garanties en place afin de pouvoir détecter les problèmes dès le début.

Ces points sont les plus importants à mon avis:

1. Lisez les parties cruciales de votre code et assurez-vous qu'elles sont faciles à comprendre. Utilisez des commentaires ou des noms de fonction et de variable intuitifs.
2. Facilitez la soumission du code par la nouvelle personne.
3. Si ce n'est pas trivial, créez un fichier README qui explique toutes les étapes nécessaires pour le nouveau développeur sur la façon de configurer l'environnement de développement. Vous pouvez également aider étroitement à la mise en place de cet environnement.
4. Donnez au nouveau développeur des tâches très clairement définies lorsqu'il travaille sur ce nouveau projet. À mon avis, ces tâches devraient impliquer des fonctionnalités nouvelles mais simples. Les tâches de nettoyage n'ont pas beaucoup de sens à mon avis, car le nouveau développeur doit d'abord s'habituer à votre style de codage et à ces habitudes, même si elles sont mauvaises. Le nettoyage ou même la refactorisation sont des tâches qui doivent être effectuées par des personnes qui connaissent le code.
5. Indiquez clairement le processus de soumission du code. (Par exemple, ne soumettez que des éléments compilables.) Mais ne soyez pas trop strict, cela peut être frustrant au début.
6. Préparez un document avec les conventions de codage. Il peut être très frustrant de deviner quelles sont les autres conventions de codage.
7. Si l'application est complexe, préparez une documentation expliquant l'architecture. Ou expliquez l'architecture à la nouvelle personne en utilisant des organigrammes ou quelque chose de similaire. Vous ne voulez pas que le nouveau développeur perde trop de temps sur la rétro-ingénierie de votre projet.
8. Si le nouveau développeur est censé effectuer lui-même les déploiements, préparez une liste de contrôle ordonnée expliquant toutes les étapes nécessaires au déploiement.

Et enfin et surtout: obtenez un système de contrôle de version. Subversion est très bien. Mais assurez-vous de ne pas ajouter ces fichiers Eclipse (ou autre) qui sont spécifiques à l'utilisateur et changent donc constamment. Ils vous font perdre des heures. N'hésitez pas à demander sur Stackoverflow si vous avez des problèmes avec.