Ma réponse est NON (sans surprise, comme la plupart des articles qui commencent avec une grande question fermée). Un développeur doit être autonome et décider de lui-même pour ce genre de pratiques. Il n’a pas à demander l’autorisation à un manager, ni un chef, ni un PO, ni un SM, ni même à un tech lead ou un autre développeur.

Encore moins se voir interdire (anecdote récente lors d’un entretien technique, un développeur m’a indiqué que son client lui interdisait d’écrire des tests parce que ça prenait du temps). Au contraire, il faut promouvoir et pousser ces pratiques aux développeurs et aux équipes.

Ça fait partie du job

L’écriture de tests, le TDD, le Refactoring, le Pair Programming, et j’en passe, ce sont des pratiques répandues dans l’industrie. Elles sont reconnues et proviennent de mouvements comme le Software Craftsmanship, l’eXtreme programming, ou le Domain Driven Design. Ce n’est pas le n-ième nouveau super framework à la mode.

On parle ici de pratiques qui améliorent la qualité du code et du produit, qui facilite le changement, qui permettent de mieux collaborer, de mieux retranscrire le métier. Elles font partie intégrante du métier de développeur.

Un développeur n’est pas un exécutant. Il n’est pas là juste pour pisser du code. Il a un (grand) rôle à jouer pour concevoir un produit de qualité. Il existe de nombreux ouvrages sur ces pratiques et également sur la posture de développeur. Pour en citer un, Sandro Mancuso en parle très bien dans son livre The Software Craftsman.

Just do it

Je donnerais comme conseil aux développeurs de faire, de passer à l’action, d’utiliser ces pratiques. Sans attendre une permission officielle, sans aller chercher une approbation quelconque. Faites-le, tout simplement.

Il y a un proverbe qui dit Il vaut mieux demander pardon que demander la permission. Je l’aime bien, et je trouve qu’il a du sens dans cette situation. Vous êtes développeur et vous hésitez ? Lancez-vous, essayez, montrez par l’exemple. Probablement, quelque chose de bon en sortira et on ne viendra pas vous taper sur les doigts. Ce n’est pas parfait ? Vous deviendrez meilleur en continuant d’essayer et de vous améliorer.

Rappelons que le développeur a l’expertise. Il sait comment travailler, il connaît sa boîte à outils. Mon propos n’est pas d’enfermer le développeur dans sa vision - il doit rester ouvert, comme tout le monde - mais de lui faire confiance et de lui donner de l’autonomie.

Ce qui n’empêche pas de le challenger. Et quand on touche à ses limites, à sa zone où il ne maîtrise pas, on se penchera plutôt sur comment former, comment apprendre, comment expérimenter, plutôt que d’empêcher.

Former les équipes

Ça fait partie du job, d’utiliser ces pratiques, ça fait également partie du job de se former. Elles ne tomberont pas soudainement du ciel. Avis aux développeurs qui doivent faire l’effort autant qu’aux managers qui doivent investir ;)

On se forme, on forme les équipes, on expérimente, on s’améliore en continue. Le retour sur l’investissement est positif, on ira plus vite, on délivrera mieux. On veut démarrer un cercle vertueux (on apprend, on améliore le code, on change plus facilement, on livre plus vite, on satisfait davantage l’utilisateur) plutôt que vicieux (on empêche, on n’apprend pas, le code se détériore, les évolutions deviennent difficiles, on cumule des problèmes, on met du temps à livrer à l’utilisateur).

Il y a un tas de moyens pour apprendre. Quelques idées : inviter des personnes à faire un BBL, l’intervention de coachs, faire des katas seul ou en groupe, du mob-programming sur le projet, assister à des conférences, lire des livres, etc.

Casser les idées reçues

Et s’il y a du blocage, des interdictions, des permissions à demander pour utiliser ces pratiques ? J’essaierais de comprendre pourquoi, de challenger, de rappeler que ça fait partie du job, et de casser certaines idées reçues.

En rappelant la vision, la philosophie de certaines pratiques. Le refactoring, ce n’est pas un chantier de 3 mois en tunnel. Ce sont des petites étapes, ce sont des améliorations que l’on fait au quotidien, qui facilitent le changement, qui améliorent la qualité.

L’écriture de tests et le TDD, ce n’est pas plus long. C’est une aide pour le développeur, un guide pour bien retranscrire le métier, le comportement. On obtient en plus de la sérénité quand il faut effectuer des changements. On entre dans des situations où l’on ira plus vite.

Le Pair-Programming, ce n’est pas juste deux ressources humaines qui se mettent sur un poste pour travailler sur un seul problème à la fois. C’est une collaboration poussée, c’est un feedback rapide, c’est une transmission de connaissances, d’informations, c’est de l’amélioration en continue. Là aussi on entre dans des situations où l’on ira plus vite.

On améliore la qualité, on gagne du temps, on gagne de l’argent. Trois arguments que l’on peut aligner en fonction de l’interlocuteur. On pourrait citer en touche finale Accelerate, un livre qui montre, via une étude sur plusieurs années incluant de très nombreuses entreprises, qu’il y a une corrélation entre la performance technique et la performance business.

Oui, je fais allusion au pair programming. Mais avant d’en parler, plongeons-nous dans une histoire. Une histoire que j’ai déjà vécu et que vous avez probablement aussi vécu. Je dirais même que beaucoup ont vécu, d’un côté de la revue ou de l’autre.

Cette histoire vous est-elle familière ? À quel point la vivez-vous ? Vous en êtes-vous déjà rendu compte ? La review est-elle douloureuse pour vous ou votre équipe ? Prenez le temps de vous poser des questions.

Ce que l’on peut observer

Une grande partie du travail est refait. Perceval ayant créé quelque chose qui ne convient pas, du code est jeté. C’est du temps en partie perdu. De plus, la durée de la tâche s’allonge : qui dit suppression dit ré-écriture. Perceval a dû reprendre son travail avec une autre manière de faire. Les chances d’avoir des conflits à résoudre pour merge augmentent, leurs complexités aussi.

Perceval a passé beaucoup de temps tout seul et n’a eu le premier feedback que très tardivement - une fois qu’il pensait avoir terminé, ce qui augmente le coût de re-travail. Arthur a également mis du temps à faire la revue car il y avait beaucoup de code à lire.

Les discussions sont à l’écrit, et en décalées. La revue est ouverte, plus tard des commentaires sont ajoutés, plus tard des retours sont effectués, et ainsi de suite. Le temps d’attente peut être long. La tâche met plus de temps à être terminée.

À chaque aller-retour, il y a un changement de contexte. La personne (auteur ou lecteur) doit arrêter ce qu’elle était en train de faire, doit se plonger dans la revue, puis se remettre sur son ancienne tâche avec la nécessité de se re-plonger dans ce qu’elle faisait. Ce temps n’est pas négligeable.

Et que ressent Perceval ? Quand il apprend qu’il doit tout refaire. Quand il lit les commentaires d’Arthur, sujet à interprétation, pouvant être pris personnellement.

Ce que l’on peut faire

On communique davantage. On donne du feedback tôt et régulièrement. On collabore. Perceval et Arthur peuvent échanger dès le début de la tâche, pendant, et même à la fin lors de la revue. Ils peuvent la faire ensemble sur le même poste. Et soyons fous, ils peuvent se mettre au pair programming. Ça y est, on y vient.

Qu’en pensez-vous ? Remémorez-vous la première histoire.

En travaillant de paire, le feedback est immédiat et continu. Arthur accompagne en temps réel Perceval. Il n’y a plus d’aller-retour ou d’échanges à l’écrit, ni d’attente, ni de changement de contexte. Il n’y a même plus besoin de faire de code review, chaque retour a été pris en compte sur le moment et le résultat est de meilleure qualité. Avec le pair programming, la revue de code est poussée à son extrême : le binôme en fait tout le long, à chaque instant.

Les échanges sont plus humains et plus riches. Chacun apprend, partage. Chacun challenge et améliore le code écrit. Chacun comprend le code et la fonctionnalité - la propriété est collective. Les bénéfices du pair programming sont multiples. Alors pourquoi attendre ? Une heure, une journée, une fonctionnalité de bout-en-bout, … Lancez-vous. À votre rythme, mais lancez-vous.

Testez, observez ce qui change, prenez du feedback. Apprenez à faire du pair programming, acceptez au début de ne pas savoir faire, améliorez-vous. Et appréciez :)

Post-scriptum du prêtre : toute ressemblance avec des personnes existantes ou ayant existé dans la légende arthurienne ne saurait être que fortuite. Ou pas. Je suis en manque de film Kaamelott.

C’était lors d’un beCom début octobre - un événement à benext qui regroupe toute une communauté sur l’après-midi. Les participants étaient demandeur d’approfondir un sujet, notamment avec de la pratique. On a proposé avec Cédric d’animer un Mob-Programming.

J’aime beaucoup faire du Mob-Programming. C’est un excellent moment pour partager, apprendre, et explorer avec plusieurs personnes. On s’est dit que ce serait un très bon moyen pour que le groupe puisse apprendre activement. Que les plus sachant transmettent. Que les plus néophytes découvrent et essayent. Que tout le monde se challenge à son niveau.

Cédric restait au clavier (covid oblige) pour retranscrire toutes les volontés du groupe. De mon côté, je facilitais. Nous étions aussi là en conseil pour accompagner le groupe lorsqu’il y avait besoin.

Trop de libertés, peu d’initiatives

On a démarré avec un format très libre. Tout le monde pouvait participer, proposer et faire avancer à tout instant. Résultat, de nombreux silences et non un brouhaha. Une seule personne participait activement et deux autres de manière sporadique (oui, je suis en manque de Kaamelott). Le reste du groupe était totalement passif.

Un début pas très dynamique, probablement ennuyant pour certains participants. Un début qui me demandait également beaucoup d’énergie pour la facilitation, pour insuffler de la vie, faire participer, faire questionner, etc.

Avec le recul, je me dis que l’on n’a pas assez pensé au public ciblé en amont. Un public composé majoritairement de jeunes développeurs et non habitué à des pratiques tel que le Mob-Programming. Avoir trop de liberté était contre-productif, cela freinait les participants. Et avec 10 personnes, c’était un grand groupe. Il fallait un cadre plus fort.

Des binômes et de l’action

Au bout d’une heure, j’ai proposé de faire un break pour s’aérer l’esprit. On a échangé brièvement avec Cédric et on était du même avis, c’était difficile. On a repris avec une nouvelle formule.

On a désigné deux personnes au hasard. Celles-ci héritèrent du rôle de leader : elles devaient faire des choix, réfléchir à voix haute et indiquer comment avancer à Cédric (au clavier). Toutes les dix minutes, on tournait avec les deux personnes à côté. Et ainsi de suite. Le reste du groupe pouvait bien entendu participer en même temps, mais c’est le binôme qui était responsable de faire avancer.

Rapidement, le Mob-Programming est devenu vivant. Les échanges au sein du binôme étaient intéressants, il y a avait de l’interaction entre les personnes, et le groupe avançait bien. L’ensemble du groupe s’est mis à participer. Les personnes étaient avec nous. Lors du debrief de fin de journée, les retours étaient très positif sur le passage en binômes.

J’avais également moins d’effort à fournir sur la facilitation. Inconsciemment, j’essayais de combler cette absence de cadre en première partie. Le groupe gagnait en autonomie et je pouvais me concentrer sur d’autres choses.

Assigner des rôles et les faire tourner

En assignant des rôles, on a proposé un cadre dans lequel les participants évoluaient. Ce rôle les responsabilisait. Le rôle les poussait à l’action et à la réflexion. Au sein d’un grand groupe, cela évite l’effet “quelqu’un le fera à ma place”.

Faire tourner ces rôles permet de rendre tout le monde actif à un moment. Les participants étaient davantage présents, et le fait de minuter donnait un rythme. Le groupe arrête de se reposer sur une seule personne très active, et celle-ci laisse la main.

Je repense aux sessions de Mob-Prgramming que je fais avec des personnes plus chevronés, en format assez libre : il y a aussi des moments où l’on désigne une personne qui prend le lead. Et des moments où l’on change. Ca fonctionne bien.

Tout ceci me fait dire qu’avoir des rôles tournant, ou au moins un lead tournant au sein du groupe est une composante importante du Mob-Programming. La méthode du Driver & Navigator va d’ailleurs dans ce sens.

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 ?