Développer votre équipe de développement avec des ingénieurs externes sans perdre la qualité du code

Introduction

Points clés

1. Faites appel à des ingénieurs externes lorsque votre feuille de route est trop chargée pour votre équipe principale.
2. Définissez des garde-fous simples en matière de qualité et un pipeline de livraison de base avant leur arrivée.
3. Intégrez les développeurs externes à l'aide d'une liste de contrôle claire et d'un collègue référent.
4. Appliquez un ensemble commun de règles, d'évaluations et de mesures pour tous les ingénieurs.
5. Appuyez-vous sur de brèves mises à jour écrites pour maintenir la cohésion d'une équipe mixte en pleine croissance.

Pourquoi devriez-vous agrandir votre équipe de développement avec des ingénieurs externes ?

Vous devriez élargir votre équipe de développement avec des ingénieurs externes lorsque votre feuille de route est pleine et que vos propres collaborateurs ne peuvent pas suivre le rythme de manière saine. Le principe est simple : les ingénieurs externes doivent apporter rapidité et compétences sans nuire à la qualité. S'ils vous aident à fournir un travail régulier et facile à maintenir, cette configuration est judicieuse. S'ils ne font qu'ajouter du stress et des changements aléatoires, ce n'est pas le bon moment.

De nombreux dirigeants d'entreprises de produits ressentent cette même pression. Le retard s'accumule, les délais ne sont pas respectés et le recrutement d'ingénieurs compétents dans votre ville prend beaucoup de temps. C'est à ce moment-là que vous commencez à envisager de renforcer votre équipe d'ingénieurs avec l'aide de l'extérieur. Vous pouvez vous tourner vers une équipe de développement externalisée dans une autre région ou vers un groupe plus petit plus proche de votre fuseau horaire. La vraie question n'est pas de savoir si vous pouvez faire appel à une aide externe, mais quand celle-ci soutiendra votre feuille de route au lieu de masquer des problèmes plus profonds.

L'une des raisons d'inviter des ingénieurs externes est d'accéder à des compétences dont vous ne disposez pas actuellement en interne. Vous pouvez avoir besoin d'une aide à court terme dans des domaines tels que les données, les applications mobiles ou les nouvelles configurations cloud. Vous ne souhaitez peut-être pas constituer une toute nouvelle équipe pour chaque nouveau sujet. Dans ce cas, le renforcement de l'équipe de développement logiciel peut vous apporter un soutien flexible autour de votre groupe principal. Vous conservez les connaissances et l'orientation fondamentales au sein de votre entreprise et vous faites appel à une aide externe pour des tâches claires et ciblées. Au quotidien, cela s'apparente davantage à l'ajout d'un expert calme à une équipe très occupée qu'à la création d'une deuxième entreprise.

Il y a également un aspect très basique lié au temps et aux coûts. Recruter vous-même des personnes compétentes peut prendre plusieurs semaines, voire plusieurs mois, et pendant ce temps, votre retard ne cesse de s'accumuler. Vous pouvez ici constater clairement les avantages du renforcement du personnel informatique. Vous pouvez faire appel à des ressources supplémentaires pour une durée et un périmètre définis, tout en continuant à réfléchir à un recrutement à long terme. Pour certaines équipes, cette option permet de lisser les pics de demande au lieu d'imposer une forte augmentation des effectifs fixes. Ce type de configuration vous permet de tester l'impact d'une capacité supplémentaire sur votre produit avant de modifier définitivement l'ensemble de votre structure.

Vous pouvez également choisir différents modèles pour l'intégration de ces personnes dans votre environnement. Dans un modèle d'augmentation du personnel, vous ajoutez des ingénieurs externes à votre propre équipe et vos responsables guident leur travail au quotidien. Dans le cadre d'une équipe de développement nearshore, les personnes se trouvent dans un fuseau horaire proche et peuvent participer à vos appels et discussions pendant les heures normales. De nombreuses entreprises travaillent avec un partenaire de développement logiciel expérimenté qui sait déjà comment développer des logiciels nearshore et s'intégrer aux équipes internes. Plus la culture, le fuseau horaire et les outils sont proches, plus il est facile de donner à plusieurs personnes le sentiment de former une seule et même équipe, même si les contrats diffèrent. Cette base commune est ce qui rend le travail externe naturel plutôt que fragile.

Comment préparer votre base de code et vos processus avant d'ajouter une équipe de développement externe ?

Vous vous préparez à l'arrivée d'une équipe de développement externe en établissant une base claire et simple pour la conception et la livraison de votre produit. Vous avez besoin de règles communes, d'outils de base et d'une méthode de travail visible avant l'arrivée de nouveaux collaborateurs. Sans cette base, chaque changement dépend du style personnel et de la mémoire de chacun, et les nouveaux arrivants n'ont aucun moyen de deviner la bonne marche à suivre. Avec cette base, même les nouveaux venus peuvent avancer à un rythme sûr et régulier.

Vous pouvez considérer cette base comme des garde-fous de qualité pour le code. Ces garde-fous sont de simples contrôles que chaque changement doit passer, peu importe qui l'a écrit. Ils peuvent couvrir la façon dont vous nommez les choses, la façon dont vous formatez les fichiers et ce que signifie « terminé » pour chaque petite tâche. Lorsque les garde-fous restent les mêmes pour tout le monde, votre produit semble stable même lorsque l'équipe s'agrandit et change. Il est ainsi plus facile de faire confiance à l'ensemble du processus, et pas seulement aux personnes que vous connaissez déjà.

Vous avez également besoin d'un pipeline de base pour l'intégration et la livraison continues. Cette longue expression décrit une idée simple. Chaque fois que quelqu'un modifie le code, le système effectue des vérifications et aide à transmettre cette modification aux utilisateurs par petites étapes sûres. Ce pipeline peut être hébergé sur des plateformes courantes et s'exécuter à chaque push vers votre référentiel de code principal. Un pipeline fonctionnel transforme de nombreuses petites modifications en une progression claire, plutôt qu'en une pile de versions importantes et intimidantes. Les nouveaux arrivants peuvent apprendre ce processus une fois pour toutes, puis le suivre sans avoir à se poser de questions.

Les tests sont un élément clé de ce processus. Les tests automatisés dans CI/CD signifient que vos tests s'exécutent automatiquement chaque fois que quelqu'un partage un nouveau code. Vous pouvez commencer par des vérifications simples qui couvrent les chemins les plus utilisés dans votre produit. Au fil du temps, vous pouvez ajouter d'autres tests à mesure que vous identifiez les endroits où les bogues ont tendance à apparaître. Même un petit ensemble de tests stables vous offre plus de sécurité qu'une longue liste de vérifications manuelles que personne n'effectue à temps. Cette approche permet de rester réaliste et soutient à la fois les ingénieurs internes et externes.

Elle permet également d'examiner les parties les plus anciennes de votre système avant de demander à d'autres de les modifier. C'est là qu'intervient la gestion de base de la dette technique. La dette technique est une façon de décrire un code qui fonctionne mais qui est difficile à modifier sans risque. Vous pouvez marquer les zones qui sont sûres pour les nouveaux arrivants et celles qui nécessitent encore l'attention de votre personnel le plus expérimenté. Lorsque vous savez où se trouvent les parties risquées, vous pouvez guider une équipe de développement externe vers les zones les plus sûres en premier lieu. Cela protège votre produit et éloigne les nouveaux arrivants des pièges cachés.

La dernière partie de la base concerne la sécurité et l'accès. Un cycle de vie de développement logiciel sécurisé peut sembler lourd, mais il repose sur des étapes claires. Vous ne donnez aux personnes que l'accès dont elles ont besoin, vous protégez les données réelles des utilisateurs et vous traitez les clés secrètes avec soin. Vous notez également ce qu'il faut faire lorsque quelque chose ne va pas, même à petite échelle. Lorsque la sécurité fait partie du travail normal, les ingénieurs externes peuvent rejoindre votre processus sans susciter de nouvelles craintes. Vos équipes juridiques et de sécurité voient également que cette croissance suit un plan et n'est pas une solution rapide.

À quoi ressemble un plan d'intégration sécurisé pour les développeurs externes ?

Un plan d'intégration sécurisé pour les développeurs externes leur fournit le contexte, les outils et les premières étapes claires sans les précipiter dans le grand bain. Il doit s'agir d'un parcours guidé où chaque jour a un objectif simple et concret. Lorsque le plan est clair, les nouveaux arrivants peuvent apporter une valeur ajoutée en quelques semaines, et non en plusieurs mois, et votre propre équipe ne se sent pas épuisée par des questions constantes.

L'intégration des développeurs externes commence par une vision commune de ce qu'ils doivent apprendre en premier. Cela inclut votre produit, vos utilisateurs et votre façon habituelle de travailler. Une liste de contrôle d'intégration pour les développeurs peut regrouper tous ces éléments en un seul endroit. Elle peut prendre la forme d'un document simple que les deux parties peuvent ouvrir et modifier. Une liste de contrôle visible transforme « Je pense que nous leur avons déjà dit cela » en « Nous savons exactement ce qui a été fait et ce qui reste à faire ». Ce petit changement élimine beaucoup de stress latent pour tout le monde.

Voici une liste simple qui sert souvent de base à une telle liste de contrôle :

1. Accès au code, au suivi des tâches et aux principaux salons de discussion.
2. Étapes à suivre pour exécuter le produit sur un ordinateur portable ou un serveur de test.
3. Un guide succinct à l'intention des utilisateurs, présentant les principaux flux et les règles commerciales clés.
4. Noms des personnes à contacter pour obtenir des informations sur le produit, le code et les outils.
5. Deux ou trois petites tâches claires, prêtes pour un premier changement réel.

Il est également utile de désigner une personne de contact claire. Un responsable technique ou un ingénieur senior peut jouer le rôle de parrain pendant les premières semaines. Cette personne peut examiner tous les changements initiaux, répondre aux questions et expliquer pourquoi les choix passés ont été faits. De brefs points quotidiens, même cinq minutes dans le chat, peuvent permettre de garder le cap. Un parrain calme et des points de contact réguliers sont plus efficaces pour une intégration en toute sécurité qu'un grand discours le premier jour. Au fil du temps, vous pouvez transférer davantage de mises à jour vers une communication asynchrone pour les équipes de développement, par exemple sous forme de brèves notes écrites.

D'après mon expérience, le plus grand risque lors de l'intégration est une confusion silencieuse. Les nouveaux arrivants ont peur de poser trop de questions, et les anciens membres de l'équipe espèrent que les choses se mettront en place d'elles-mêmes. Un plan clair pour l'intégration des développeurs externes et un seul responsable de ce plan changent la donne. Lorsqu'une seule personne est responsable du processus, vous pouvez repérer les schémas, corriger les points faibles et faciliter chaque nouvelle intégration. En quelques mois, le plan devient un atout reproductible au lieu d'une nouvelle difficulté à chaque fois que vous ajoutez quelqu'un.

Comment maintenir la qualité du code dans une équipe de développement mixte lorsque vous gérez des développeurs externes ?

Vous maintenez la qualité du code dans une équipe de développement mixte en utilisant les mêmes règles, contrôles et chiffres simples pour tout le monde. Vos normes doivent s'appliquer à tous les ingénieurs si vous voulez que le produit soit perçu comme un système propre et sûr. Une fois que vous divisez les règles par type de contrat, vous divisez également la confiance et la clarté au sein de votre équipe.

Une équipe de développement mixte est un groupe dans lequel des ingénieurs internes et externes travaillent sur le même produit. Ils peuvent être situés à des endroits différents, mais ils partagent un backlog et un référentiel de code communs. Cette combinaison peut être très efficace, car elle associe une connaissance approfondie du domaine à des points de vue nouveaux. Elle peut également être fragile si chaque groupe suit ses propres habitudes. Sans directives claires, cette combinaison se transforme en clusters de code qui semblent différents et entre lesquels il est difficile de passer. C'est à ce moment-là que la qualité et la vitesse commencent à décliner.

De simples bonnes pratiques en matière de révision du code peuvent aider dans ce cas. Chaque modification doit être révisée par au moins une autre personne, quelle que soit la personne qui l'a apportée. Les révisions doivent porter sur la clarté, la sécurité et l'adéquation avec le reste du système, et pas seulement sur le style. Vous pouvez vous aider d'outils légers qui analysent le code à la recherche de problèmes courants. Ces routines permettent de maintenir la qualité du code des développeurs externes au même niveau que celle du reste de votre équipe, de manière calme et reproductible. Les gens apprennent les uns des autres et développent une vision commune de ce qui est « bon ».

Vous pouvez également suivre un petit ensemble de mesures relatives à l'équipe de développement logiciel. Celles-ci peuvent indiquer le temps nécessaire pour terminer un travail, le nombre de problèmes rencontrés par les utilisateurs et la fréquence des livraisons. Vous n'avez pas besoin de dizaines de chiffres. Il vous suffit d'en avoir quelques-uns que vous pouvez lire et discuter facilement. Lorsque ces indicateurs restent stables ou s'améliorent pendant que vous gérez les développeurs externes et agrandissez l'équipe, vous savez que votre configuration favorise la qualité. S'ils baissent, vous disposez d'un signal précoce pour revoir vos règles, votre champ d'action ou la répartition des tâches.

Les modes de communication sont tout aussi importants que les règles et les chiffres. De nombreuses équipes de développement mixtes sont également considérées comme des équipes agiles distribuées, car leurs membres travaillent depuis plusieurs endroits ou fuseaux horaires. Elles ont besoin d'une communication asynchrone pour que les équipes de développement puissent progresser sans dépendre de longs appels téléphoniques. De courtes mises à jour écrites, des notes de tâches claires et des balises simples pour indiquer le statut sont très utiles. De bonnes mises à jour écrites permettent à tous les ingénieurs de rejoindre, suivre et améliorer le produit au fil du temps. Les discussions en direct restent importantes, mais elles ne sont plus le seul lieu où les décisions sont prises.

La manière dont vous intégrez les personnes extérieures influe également sur la qualité. Si vous les traitez comme un flux distinct avec des objectifs flous, elles ne se sentiront pas pleinement responsables du produit. Si vous les intégrez à des équipes existantes selon un ensemble de règles, elles peuvent agir comme n'importe quel autre membre de l'équipe. Certaines entreprises utilisent pour cela une configuration d'augmentation d'équipe, dans laquelle elles mélangent des personnes internes et externes sous une seule direction. Des objectifs, des outils et des évaluations communs contribuent davantage à la qualité du code dans le développement de logiciels que n'importe quel document de contrôle rigoureux. Au fil du temps, vous pouvez ajuster la composition des équipes et le travail, mais le cadre commun reste le même.