Les défis du développement distribué: partie 1

Les projets de développement distribué sont une pratique de plus en plus courante dans le monde du développement de logiciels. Dans ces projets de collaboration, des équipes réparties dans différents endroits travaillent ensemble pour livrer. Les grandes entreprises réparties dans le monde ont souvent des projets de développement distribués.

Le développement distribué a des défis comme des avantages, qui dépendent des efforts que tu y consacres. Travailler avec des équipes à distance présente de nombreux défis de communication, dont je parlerai avec toi dans cette partie 1 de notre article divisé en deux parties.

Les avantages

D'abord, pourquoi les entreprises font-elles du développement distribué? Il existe de nombreuses raisons telles que l'expertise, le coût et la disponibilité des ressources. Si ton équipe de développement ne maîtrise pas certaines compétences essentielles, il peut être utile de travailler avec une équipe à distance qui possède l'expertise dont tu as besoin pour apprendre par osmose.

Une autre raison de faire du développement distribué est l’économie de coûts qu'il peut apporter. Les entreprises peuvent obtenir plus de développeurs pour le même tarif en transférant leur travail vers des centres de développement à l’étranger, dans des pays comme l'Inde et la Chine. Le secret bien gardé du développement à l’étranger est que ces économies sont initialement moindres en raison des problèmes de communication, de la mise à niveau de l'équipe à distance et du temps requis pour leur faire adopter vos processus.

En plus des économies de coûts, l'incapacité à trouver des personnes possédant les compétences requises dans ton marché peut t’inciter à travailler avec une équipe dans un endroit où il est plus facile de recruter les talents avec les compétences dont tu as besoin.

Les équipes onshore versus offshore

Il existe différents types d'équipes de développement à distance avec lesquelles tu peux travailler : des équipes onshore, near shore et offshore. Il n'est pas rare de travailler dans des équipes distribuées avec une combinaison de types d'équipes sur un projet donné.

Les équipes onshore sont situées dans le même pays que toi. Les problèmes de communication sont beaucoup moins fréquents, car tout le monde parle généralement la même langue. Les différences de fuseau horaire sont aussi plus faciles à gérer entre les équipes.

Les équipes near shore sont situées à proximité de ton pays d'origine. Les équipes du Canada et des États-Unis qui travaillent ensemble en sont un exemple.

Les équipes offshore sont généralement situées dans des pays émergents, tels que l’Inde et la Chine. On y a recours en raison de coûts inférieurs, d'expertise ou de ces deux facteurs. Lorsqu'un produit grand public est sur le point d'être retiré, on peut également faire appel à ces équipes pour effectuer la maintenance tandis que l'équipe de développement principale conçoit et travaille sur la prochaine génération du produit.

La journée de développement de 24 heures

Comme il y a 24 heures dans une journée, tous les chefs de projet n'ont-ils pas rêvé à un moment donné d'avoir des développeurs travaillant sur leur projet 24 heures sur 24? Pour des raisons évidentes, les développeurs ne sont tout simplement pas disposés à le faire. Avec le développement distribué, ce rêve peut devenir réalité.

Lorsque tu travailles avec des équipes de développement distribuées, selon la manière dont le développement est réparti dans le monde, le codage peut se dérouler presque 24 heures sur 24. Mais à quel point est-ce souhaitable?

En raison du décalage horaire entre les pays, communiquer efficacement entre les équipes est un grand défi. La communication par courriel fonctionne jusqu’à un certain point, mais il y a toujours un décalage dans le temps de réponse. Il faut planifier des conférences téléphoniques tôt le matin ou tard dans la nuit afin que tous soient disponibles en même temps.

Le décalage se reflète également lorsque tu trouves un problème de dernière minute qui doit absolument être réglé aujourd'hui. Si ton équipe est offshore, tu n'obtiendras peut-être pas de réponse ni même de correctif avant le lendemain, ce qui peut avoir un impact très négatif sur une sortie.

L’un des avantages secondaires d'avoir une équipe offshore est que, comme ils sont dans un fuseau horaire différent, ils ne peuvent pas être traînés dans les réunions quotidiennes qui ont un impact sur la productivité de ton équipe locale.

La communication

La communication est l'un des plus grands défis auxquels sont confrontées les équipes de développement distribuées. Ce problème a de nombreux aspects différents tels que les difficultés linguistiques, la collaboration entre les équipes et les enjeux liés aux différentes cultures. Certains de ces problèmes sont plus faciles à résoudre que d'autres.

Les défis linguistiques se présentent sous plusieurs formes. L'une d'elles est une situation dans laquelle certains ou tous les membres de l'équipe à distance ne parlent tout simplement pas la même langue que l’équipe. Un autre est celui où on ne peut pas comprendre ce qu'ils disent, soit en raison d'accents lourds, soit simplement d'une incapacité à parler la langue.

Lorsque tu te retrouves dans ces situations, tu dois créer un vocabulaire commun à un niveau de base que tout le monde comprend, puis progresser à partir de là. Il faut également valider que les équipes se comprennent. Tu peux y parvenir en posant des questions ouvertes sur ce dont vous parlez afin de confirmer leur compréhension. De temps en temps, répète ce qu'ils disent dans tes propres mots afin de valider que ta compréhension est bonne.

La collaboration d’équipe

Comme la collaboration d'équipe est essentielle, les équipes travaillant dans différents lieux ont besoin de répertoires de code source communs, de référentiels d'exigences et d'outils de suivi des défauts. Il faut également trouver des moyens de communiquer efficacement entre les équipes.

Les outils de collaboration, tels que Teams, Zoom ou Miro peuvent être très utiles pour permettre aux deux équipes de partager des écrans ou de travailler avec un tableau blanc partagé lors de réunions. Les outils de messagerie instantanée aident également les équipes à collaborer et à mieux communiquer.

Il faut s’assurer que les informations circulent entre les équipes et que tout le monde évolue pour devenir égal. Outiller les gens est la raison d'être de la collaboration d'équipe. Ne laisse pas ton équipe faire le gros du travail. Cela ne permet pas aux autres équipes de vous aider à réussir.

Méfie-toi des personnes ayant une forte personnalité dans ton équipe, ceux qui n'aiment pas collaborer ou qui veulent ternir l’image des autres équipes autant que possible. Ces personnes travaillent généralement sur le produit depuis longtemps et peuvent avoir l'impression que vous recherchez leurs remplaçants.

Mon exemple préféré lié à la création d'équipes pour les rendre égales concerne les révisions de code. Dans ces situations, l'équipe principale, surtout au début, peut ressentir le besoin de revoir tout ce que fait l'autre équipe. C'est une bonne chose, bien sûr. Mais pour aller de l'avant, tu dois impliquer les personnes des équipes à distance dans les revues de code de l'équipe principale. Cela apporte deux avantages importants. Tout d'abord, la connaissance de la base de code se répand lors des revues de code. Deuxièmement, il y a une autre paire d'yeux (et dans ce cas, un regard frais et objectif) qui regarde le code.

Les différences culturelles

Tu dois comprendre les différences culturelles entre ton équipe et l'équipe à distance et trouver des compromis si nécessaire pour que le projet continue de fonctionner correctement.

Tu dois également être capable de distinguer les différences culturelles des mauvaises habitudes. Les mauvaises habitudes (comme ne pas partager d'informations avec les autres membres de l'équipe, ne pas faire de révisions de code, les mauvaises pratiques de codage, etc.) doivent être découragées et éliminées au fur et à mesure.

L’un des plus grands défis que j’ai vu en ce qui concerne les différences culturelles est l’incapacité de certains membres de l’équipe à dire qu’ils ne comprennent pas quelque chose, parce que ce n’est pas approprié dans leur culture.

Le principal symptôme de ce problème est que l'une des équipes dise simplement « oui » à tout ce qu’ils entendent sans rien remettre en question ni poser de questions. Ensuite, ils partent et font ce qu'ils pensent nécessaire. Tu n’apprends généralement qu'à la fin du cycle qu'ils ont suivi leur propre chemin et fait la mauvaise chose. Il existe deux façons de remédier à cette situation. Tu peux soit leur fournir un ensemble d'exigences à toute épreuve avec de la documentation, soit tu leur demandes de documenter les exigences et d’en faire la révision.

Voici un exemple concret que j'ai déjà vécu. J'avais passé des heures avec l'équipe à concevoir une solution à un problème et lorsque nous avions terminé, tout le monde comprenait et convenait que c'était la bonne solution. Lorsque le code a finalement été livré, j'ai réalisé que le problème n'était pas résolu. J'en ai discuté avec l'équipe et on m'a dit que la solution originale ne fonctionnait pas, alors ils sont allés dans une direction différente à la place.

Quand je leur ai demandé d'expliquer ce qui n'allait pas avec la solution originale, j'ai réalisé en écoutant leur explication qu'ils n’avaient pas du tout compris la solution proposée. Alors une cascade d’événements malencontreux se sont enchaînés :

• Ils n'ont pas compris la solution originale
• Ils ne me l'ont pas communiqué pour que je puisse les aider
• Ils sont partis de leur côté (ce qui aurait pu être mauvais si d’autres équipes dépendaient d’eux pour les API par exemple)
• Ils ont livré quelque chose qui n'a pas fonctionné

Pour résoudre la situation, je me suis assis avec les développeurs et j'ai écrit le code avec eux, en m'assurant qu'ils comprenaient étape par étape ce que nous faisions et pourquoi. En fin de compte, la solution originale a très bien fonctionné.

C'est frustrant de se retrouver dans cette situation, car tu aurais pu faire le travail avec des développeurs locaux et la communication aurait probablement été meilleure.

Je ne recommande pas que tu donnes des morceaux de code importants à n'importe qui. Ce que je dis, c’est que tu dois créer une nouvelle culture de confiance et de coopération. Une culture où les gens peuvent poser des questions aux chefs d'équipe et obtenir leur soutien pour résoudre leurs problèmes.

Reste à l'affût pour la partie 2 de cet article, qui parlera de la création de processus pour garder tes équipes sur la même longueur d'onde.

Ceci est une version éditée du tout premier article publié par Steffan. Le Dr. Dobbs Journal a publié une version raccourcie de l'original dans son numéro d'août 2007.