L'agilité dans une équipe de développeurs logiciels répartie mondialement

En février 2001, les 17 apôtres du développement de logiciel Lightweight se réunissaient pour un week-end en un lieu devenu mythique, le « Snowbird Resort », en Utah, depuis connu comme le lieu de naissance du mouvement Agile. Il en est sorti 12 principes qui ont débouché sur la rédaction du manifeste pour le développement Agile de logiciels qui énoncent quatre grande valeurs.

• Les individus et leurs interactions, plus que les processus et les outils
• Des logiciels opérationnels, plus qu’une documentation exhaustive
• La collaboration avec les clients, plus que la négociation contractuelle
• L’adaptation au changement, plus que le suivi d’un plan.

À l’examen de ces valeurs, on comprend mieux pourquoi le développement Agile de logiciels invite à plusieurs pratiques : des cycles de diffusion de logiciels plus courts, l’inspection et l’adaptation, la réactivité aux changements, la diminution des frais généraux, des priorités axées sur la valeur… Au cœur de cette philosophie se trouve l’efficacité de la collaboration entre les parties concernées et, qui dit collaboration, dit également plus de communications. Cependant, ces dernières années nous avons observé un changement radical dans la façon dont se pratique le développement de logiciels : l’amélioration continue de l’accès à l’Internet et la plus grande prépondérance du télétravail ont amené les équipes de développement modernes à évoluer. Cela n’a pas été sans poser un certain nombre de défis à la collaboration au sein des équipes de programmeur, notamment par la collaboration entre régions (accents) et par l’apparition du phénomène de décalage horaire au sein d’une même équipe.

Dans le présent article, et en nous fondant sur nos expériences personnelles, nous explorerons les différents outils de communication et de collaboration et verrons quels en sont les forces et les faiblesses. Enfin, à supposer que nous abordions cette question sous le mauvais angle, nous traiterons aussi des autres approches applicables aux équipes distribuées.

La communication

L’un des principes sous-jacents du manifeste des 17 est le suivant : « La méthode la plus simple et la plus efficace pour transmettre l’information à l'équipe de développement et au sein de cette équipe est le dialogue en face à face. » (Kent et al.) David Parnas corrobore cette vision des choses en affirmant que la cause profonde de la plupart des échecs en développement de logiciel est l’inefficacité des communications. Cependant, comment remplacer le contact en personne dans une équipe géographiquement dispersée ? Pour répondre à cette question, nous nous proposons d’examiner les trois vecteurs de communication les plus courants : le texte, l’audio et l’audiovisuel.

Le texte

De tous les modes de communications par texte, soit le courriel, le clavardage et le message texte (SMS), nous ne traiterons pas du dernier parce que nous ne l’avons jamais vu employé en tant que véritable outil de communication en dehors des applications dont nous traitons ici. Nous ne nous arrêterons donc qu’aux courriels et au clavardage.

Par définition, la communication écrite est très précise parce que l’auteur a la possibilité de revoir chaque question, réponse ou énoncé et de les reformuler à volonté jusqu’à les rendre parfaits à ses yeux. Malheureusement, la perfection est celle perçue par le rédacteur qui n’a peut-être aucune idée de la façon dont le lecteur va interpréter ses écrits.

La communication écrite n’est généralement pas un bon véhicule pour transmettre les émotions et l’ironie, et elle est souvent mal comprise au point d’occasionner parfois des frictions inutiles entre les membres d’une même équipe. Dans les équipes où l’on s’en remet principalement aux communications écrites, il est très difficile de promouvoir la camaraderie.

Dans le cas du courriel, c’est l’effet de latence qui pose problème, car il arrive souvent que les destinataires ne répondent pas tout de suite à un message, qu’ils attendent d’avoir le temps de formuler une réponse au point d’en arriver parfois à oublier le courriel reçu (par accident ou intentionnellement). Ainsi, le règlement d’une question qui n’aurait nécessité que quelques minutes dans une conversation en personne peut s’étirer sur plusieurs heures, voire plusieurs jours dans le cas d’échanges de courriels. Afin de pallier ce problème, l’équipe peut toujours convenir d’un délai maximum pour répondre aux courriels. Par exemple, que si l’expéditeur ne reçoit pas de réponse dans l’heure, il peut envoyer un message texte (SMS) à tous les autres correspondants pour confirmer l’envoi de son courriel et en rappeler l’existence.

Le clavardage présente l’avantage d’être plus engageant et interactif, un peu comme la conversation en personne, si ce n’est que la fenêtre de clavardage peut tomber dans l’oubli sur le bureau. Et puis, le rythme qu’impose ce mode de communication, par son alternance des messages, peut distraire les participants désireux de répondre à chaque message entrant, ce qui est d’autant plus le cas quand une sonnerie en ponctue l’arrivée.

L’audio

Viennent ensuite les moyens de communication par l’audio, c’est-à-dire par le téléphone et d’autres systèmes reposant sur la phonie. Cependant, lors d’une téléconférence, il arrive souvent que les participants soient distraits; ils peuvent griffonner sur un morceau de papier ou jeter un coup d’œil de temps en temps sur leur boîte de courriels et ils peuvent même se hasarder à composer une réponse. Autrement dit, ils ne suivent pas le déroulement de la réunion tant qu’on ne les rappelle pas à l’ordre.

Certains aiment à détecter les émotions de leurs interlocuteurs en observant leur non verbal. Ils savent ainsi si tout va bien ou si leurs interlocuteurs souhaiteraient ajouter quelque chose, mais préfèrent le garder pour eux. Quand on ne sait pas vraiment comment réagissent les autres par l’observation de leur comportement gestuel, on risque de laisser passer l’occasion d’intervenir sur le champ et de ne le faire qu’au moment où la personne décide de s’exprimer. À cause de cela, on peut se sentir isolé et démuni.

Et puis, il peut être difficile de composer avec les accents. J’ai déjà fait partie d’une équipe constituée d’un fort contingent d’Européens de l’Est. À un moment donné, l’un d’eux m’a dit que j’aurais vraiment intérêt à faire une certaine chose avant une date donnée. J’ai alors pensé que mon emploi était menacé tandis qu’il ne faisait que me rappeler, amicalement, qu’une fois cette date passée j’aurais beaucoup de difficulté à faire ce que j’envisageais. Afin de réduire au minimum ce risque d’incompréhension, les membres de l’équipe ne doivent pas craindre de demander des précisions jusqu’à ce qu’ils aient la certitude d’avoir tout compris.

La vidéoconférence

La vidéoconférence, d’un autre côté, est presque aussi bonne que la communication en personne. Elle permet de régler la plupart des problèmes que posent les autres types de communication, puisque les participants distraits peuvent être aimablement ramenés dans le rang par leurs collègues qui leur rappelleront, plus ou moins directement, qu’ils doivent prêter attention au débat. La téléconférence permet aussi le partage d’écran, ce qui peut aider pour les exposés, les exercices de planification, les rétrospectives et l’examen des projets. Le partage d’écran permet le débogage ou la programmation entre collègues, ce qui favorise donc une collaboration presque aussi bonne que celle caractéristique d’une équipe regroupée en un seul lieu.

La vidéoconférence présente cependant quelques inconvénients : elle exige un minimum d’infrastructure qui peut ne pas être accessible dans toutes les parties du monde. Là où la bande passante est limitée, la formule peut devenir très coûteuse. Par ailleurs, les rencontres peuvent ne pas être aussi spontanées que dans le cas d’une équipe coimplantée, parce qu’il faut planifier les réunions et tenir compte des fuseaux horaires.

Néanmoins, il demeure que chaque moyen de communication a ses avantages et ses inconvénients qui sont récapitulés dans le tableau ci-dessous :

Collaboration

Comment collaborer quand on ne se trouve pas à proximité les uns des autres ?

Le whiteboard (tableau blanc) est l’un des « radiateurs » d’information les plus couramment utilisés, à part le Kanban on y retrouve une multitude d’informations : graphique d'avancement, définition de « done », futures dates importantes, norme de groupe… bref, tout ce qui concerne votre projet peut s’y retrouver. Le fait qu’il soit facile d’accéder à un tel tableau interactif, par tous et en tout temps, peut s’avérer de grande valeur pour l’équipe. Les membres seront informés de la situation du moment et des autres données pertinentes. Cependant, pour qu’un tel tableau soit vraiment utile, les membres de l’équipe doivent pouvoir y accéder et le mettre à jour régulièrement.

Realtimeboard.com (RTB) est l’un des meilleurs tableaux interactifs actuellement sur le marché. On peut s’en servir pour dessiner, pour y ajouter des Post-it virtuel, y inscrire des remarques, y joindre des fichiers textes ou vidéos. Toutefois, comme il utilise flash, il n’est pas accessible sur la plupart des appareils mobiles; ce serait effectivement agréable qu’on puisse l’utiliser sur un appareil mobile et il y a fort à parier que l’entreprise y travaille. RTB se distingue de la concurrence par son interface d’utilisation particulièrement intuitive, la plupart des utilisateurs pouvant en apprendre rapidement le fonctionnement.

Exemple (réel) d’utilisation du RTB

Cet outil permet de créer facilement un Kanban, avec ses Post-it virtuels aux couleurs multiples. La difficulté, comme c’est souvent le cas, tient au fait qu’il faut discipliner les participants afin qu’ils le mettent régulièrement à jour. Il sert d’autant plus aux équipes éclatées que personne ne peut simplement aller voir un collègue pour lui poser une question.

La collaboration en cours de rencontre peut être difficile, mais si l’on combine l’utilisation du RTB avec la vidéoconférence et le partage d’écran, on peut faire en sorte que tout le monde participe. Il est également utile et invitant pour les autres de désigner, en cours de réunion, un membre de l’équipe chargé de partager son écran et de mettre à jour le tableau blanc.

Les solutions de remplacement

S’agissant de communication à proprement parler, est-il envisageable de favoriser un plus grand nombre de rencontres en personne ou du moins de réduire le nombre de communications indirectes ?

Kruchten (2011) établit un lien entre la distribution des équipes et la nécessité d’assurer une communication et une coordination plus explicites; il va jusqu’à dire que ce besoin s'applique aussi aux composantes du logiciel. On peut imaginer qu’il pensait alors au développement à base de composants (DBC), pratique où chaque équipe travaille sur un composant d’un système. Il peut être difficile de mettre en œuvre un DBC dans le contexte d’une équipe de consultants, surtout si elle travaille en contingent. La mise en production peut être lente et c’est d’ailleurs là qu’il peut être intéressant d’avoir un spécialiste du composant sur place qui soit en mesure d’apporter des réponses directes aux questions de l’équipe. Si le personnel a de l’expérience, il est plus facile de faire la transition au DBC. Après la phase initiale de transfert des connaissances, le développeur expérimenté peut prendre le rôle de mentor auprès des nouveaux. Une fois la transition de propriété du composant terminée, le besoin de communications entre le client et l'équipe est réduit. Le client n’a plus alors qu’à énoncer ses besoins à un membre de l’équipe (ou à deux) qui connaîtra alors très bien le cahier des charges. Ils pourront alors agir à titre de représentants de clients et pourront être perçus comme les propriétaires internes du produit. On pourrait ensuite leur confier la conception et l’analyse des changements nécessaires. Une fois la confiance établie, il devient possible de bâtir un partenariat à long terme avec le client.

Conclusion

Nous avons donc vu quel sont les différents types de communications et en avons évalué les forces et les faiblesses. Nous avons également constaté que ces moyens de communication ne peuvent remplacer le contact en personne, mais que si l’on mise sur tout l’éventail des outils disponibles, on peut parvenir à une communication efficace. Nous avons vu également qu’un tableau interactif peut être très intéressant pour une équipe. Nous vous en avons donné un exemple; il y en a d’autres, mais nous pensons que le RTB est actuellement l’un des meilleurs produits sur le marché. Nous avons laissé de côté les autres outils de collaboration, comme les instruments de collaboration que sont les wikis et les interfaces de suivi des enjeux ou des projets qui pourraient faire l’objet d’un autre article. Enfin, nous avons vu dans quelle mesure il était possible de régler le problème des équipes distribuées par la mise sur pied d’équipes plus réduites chargées d’un développement à base de composants. Nous avons abordé la question du DBC sous l’angle d’une équipe de consultants pour constater que, même si cette formule est moins efficace dans la phase de lancement, il y a des gains à récupérer par la suite. De plus, le DBC favorise la confiance entre les parties et permet donc de déboucher sur un meilleur partenariat.

Dans le respect de la philosophie Agile, il ne s’agit pas là d’une recette à suivre, mais simplement du fruit de nos observations, parce que l’expérience varie d’un cas à l’autre.

Références

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . . Thomas, D. Manifesto for agile software development. Retrieved 11/14, 2014, from http://agilemanifesto.org/

Kruchten, P. (2013). « Contextualizing agile software development ». Journal Of Software: Evolution & Process, 25(4), 351-361. doi:10.1002/smr.572

Simons, M. (2006). « Global software development: a hard problem requiring a host of solutions ». Communications Of The ACM, 49(10), 32-33.