Pair Programming ritualisé

Au printemps, alors que les arbres commençaient à fleurir, j’ai eu l’idée de ritualiser un créneau de pair programming. J’aime beaucoup cette pratique. À mon sens, le pair programming apporte beaucoup de bonnes choses. Peu importe le niveau des personnes, ou même leur écart de niveau, ce qui en émerge est très intéressant. Les discussions, le code collectif, l’exploration, l’apprentissage, etc.

C’est quelque chose que j’utilise régulièrement avec mon binôme. Sur la demande de l’un ou de l’autre. Je m’en sers beaucoup pour accompagner, partager mes connaissances, donner du feedback. On a des cas concrets pour échanger, confronter des idées et résoudre des problèmes.

Et puis un jour je me suis dit, tiens, et si on se fixait un moment dédié et régulier pour faire du pair programming ? En conservant toujours la possibilité de le faire spontanément si besoin. L’un n’empêche pas l’autre. Je l’ai proposé à mon collègue et on s’est lancé. On a essayé une fois par semaine, un créneau récurrent inscrit dans l’agenda. On a tenu chaque séance depuis le début. Aujourd’hui, j’ai eu envie de revenir sur cette expérimentation et sur ce que ça nous a apporté.

Pourquoi cette envie de ritualiser ?

Printemps 2020 rime, malheureusement, avec la pandémie de Covid-19. Lorsque l’on a été confiné, mon équipe est passée de quelques rares jours de télétravail par mois à du full remote. Je voulais garder un lien fort de partage avec mon binôme. Sur notre lieu de travail, nous étions côte à côte. Il était aisé de tourner l’écran de manière spontanée et de dire « Hey, qu’est-ce que tu en penses ? » ou « Je suis bloqué ici, tu peux regarder avec moi ? ».

À distance, j’avais peur que l’on perde ça. On ose peut-être moins. Ça demande plus d’effort. Plus de synchro. Il faut demander et appeler. Je pense qu’il peut y avoir une peur de déranger, on ne sait pas ce que l’autre fait à ce moment, on ne le voit pas. La raison première était donc de garder un lien. En ritualisant, je savais que l’on avait un créneau réservé sur nos agendas pour le faire.

Ce que j’en attendais également, c’était de partager encore plus. En faisant régulièrement du pair programming, au moins une fois dans la semaine, je voulais accentuer mon accompagnement. Avoir plus de moments où je pouvais transmettre et échanger.

Qu’est-ce que j’ai observé ?

Beaucoup de bonnes choses. J’ai même envie de dire que des bonnes choses. J’ai été agréablement surpris par chacune de nos séances. On a, à plusieurs reprises, dépassé notre créneau et continué naturellement, parce que c’était utile, parce que ça apportait de la valeur. On s’est beaucoup entraidé avec nos différentes connaissances du métier et du code. La confrontation régulière des idées a permis d’avancer plus vite sur des sujets parfois complexes.

J’ai remarqué un effet canard en plastique. Expliquer son problème à quelqu’un d’autres aide à mieux le comprendre et à trouver une solution. Donc le faire régulièrement (avec plus de pair programming) aide à trouver plus souvent et plus rapidement des solutions. C’est très bénéfique.

Une de mes craintes au départ était « est-ce qu’on aura à chaque fois des sujets adapté au pair programming ? ». En fait, oui. Ce n’est pas du tout un problème. Un jour, j’étais sur une correction de bug assez mystique. Je n’étais pas très avancé dessus et je n’avais pas de pistes intéressantes. Je pensais que ce ne serait pas très intéressant pour le créneau de pair programming qui allait démarrer.

Mais je me trompais. Ce fut l’une des sessions les plus utiles. Avec nos deux cerveaux et nos échanges, on a avancé extrêmement vite sur ce sujet. On a fait du pair programming l’après-midi entière et on a pu corriger ce bug. On a été très productif. Beaucoup plus que si j’étais resté seul.

En plus du gain de productivité et de la résolution de problèmes, j’ai pu beaucoup plus transmettre et accompagner mon binôme avec ces séances de pair programming régulières. Je trouve que c’est un excellent moyen d’apprendre les uns des autres, de guider, d’expliquer, d’essayer. On fait des choses concrètes, ensemble. On code et on échange en direct.

Enfin, une autre conséquence que j’ai observée avec l’augmentation de pair programming est la réduction du temps passé à faire du code review. Elles sont moins nombreuses et plus rapides. Plus on écrit du code ensemble, moins il y a besoin d’un processus où on le relit. Et c’est une bonne chose je trouve. Je préfère faire davantage de pair programming que de code review. Et si on arrêtait les revues de code ?

Le pair programming nous fait collaborer. On partage la propriété du code (collective code ownership), on est capable de comprendre chaque partie. C’est interactif. C’est en direct. Les code reviews sont asynchrones. On échange à l’écrit. On donne du feedback bien après l’écriture du code.

Et maintenant ?

Je compte bien conserver ce rituel et continuer à avoir un créneau dédié au pair programming. Même si le confinement est terminé et que l’on retourne partiellement au bureau, j’aime beaucoup tout ce que le pair programming nous apporte. Le fait de le ritualiser permet d’en faire plus régulièrement. Ca nous apporte un cadre.

Je songe à augmenter notre « temps minimum » de pair programming par semaine. Soit en augmentant la durée du créneau, soit en ayant deux créneaux dans la semaine. Je réfléchis aussi à une variante. Au début d’un sprint, choisir une story et décider de la faire entièrement en pair programming. Du début à la fin.

Une autre idée qui me semble intéressante serait de faire du pair programming avec une autre spécialité de temps en temps (on est organisé en feature team, il y a des développeurs Android, iOS et backend dans l’équipe). De cette manière, on obtiendrait plus de compréhension sur les autres plateformes. On irait également plus loin dans la pluridisciplinarité. J’ai pu le faire à deux reprises au début de l’année avec un développeur Android pour comprendre un problème commun, ce fut très utile.

Bref

L’expérimentation de ritualiser le pair programming s’est révélée très positive. Nous en avons tiré beaucoup de bonnes choses. Du partage, de l’accompagnement, de la collaboration, collective code ownership, etc. Tout ça régulièrement. Nous étions très productifs dans ces moments-là. Les discussions autour de l’écriture du code ont apporté des idées, des résolutions de problèmes, de l’apprentissage.

Je recommande vivement de faire davantage de pair programming. Avoir un créneau dédié peut être un moyen d’y parvenir. Essayez. C’est simple à mettre en place et très efficace. Si vous n’en faites pas du tout, lancez-vous. Si vous en fait de temps en temps, tentez de fixer un créneau. Vous pouvez commencer petit, avec une heure par semaine par exemple. Décidez d’un moment, officialisez-le dans l’agenda, et tenez le.

Et vous, à quel point faites-vous du Pair Programming ? Et comment ?