Pair programming ou comment partager

A travers les yeux d’un nouveau développeur, découvrir comment le pair programming permet de créer un binôme plus performant que la somme des deux individus qui le compose.

La genèse

J’ai fait mes premiers pas en informatique dans le rôle de chef de projet. Pour apprendre ce métier j’ai pu avoir des cours théoriques à l’université, en intégrant les bases du cycle en V. Puis en entreprise quelques jours de formation pour avoir des notions d’agilité via Scrum. Ensuite on m’a mis seul sur des petits projets où je pouvais me confronter à la pratique. J’avais pour unique repère le droit à une check-list sur Excel adaptée à mon contexte d’entreprise. Elle détaillait les étapes à suivre et les livrables à remplir pour mener à bien ma mission. J’appliquais sans toujours comprendre pourquoi, avec un amas de documents et finalement peu d’échanges sur leur substance. Cependant, petit à petit, j’ai pu les maîtriser et progresser en étant assigné à des projets de plus en plus importants. J’avais une recette pour apprendre qui semblait fonctionner : la théorie acquise via des cours et formations, la pratique que l’on se transmet par des procédures.

Fier de ces premières années dans le monde professionnel et cherchant de nouveaux challenges, j’ai alors décidé de soulever le capot en devenant développeur. Ayant eu la possibilité de toucher à quelques lignes de codes à la fac, je voyais un peu l’ampleur de la tâche qui m’attendait. A l’occasion de ma première mission, j’ai passé un test technique pour avoir une idée de mon niveau. Je me suis bien préparé pour cet examen fatidique : seul, en quelques semaines avec des exercices sur internet. Résultat : 2/150. Il y avait du travail ! Heureusement, le directeur de mission a misé sur un accompagnement avec des développeurs expérimentés. En plus de construire une application, ils devaient m’accompagner dans ma montée en compétence. Sacré projet.

Padawan

J’ai commencé par recevoir une formation sur la plateforme de développement. Cela a duré trois semaines durant lesquelles je me suis retrouvé totalement perdu. Le format était très académique, malgré quelques exercices pratiques où je me contentais de recopier des lignes de code sans en comprendre la teneur. Résultat : peu de progrès et beaucoup de frustration. La montagne grossissait à mesure que je la grimpais.

A l’issue de la formation, nous avons pu commencer le projet. Pendant le kick-off, alors que nous discutions méthodes et rituels l’un des développeurs lança le sujet du pair programming.

L’idée est de se mettre à deux sur un seul PC pour travailler. Le clavier ? On se l’échange ! Pour cela plusieurs rythmes peuvent être mis en place : à fréquence régulière par exemple. Et pendant que l’un a le clavier, l’autre ne reste pas passif. Il réfléchit sur le code, challenge, peut driver, et surtout communique. La réflexion se fait à deux, elle est au coeur du pair programming.

Dans ma position, je trouvais ça très réconfortant. Étant bien conscient que ma capacité de production était proche du néant, je pouvais me raccrocher au talent des autres. Je me disais bien que je risquais de ralentir mon binôme, mais cette idée fut vite effacée. Nous avons donc commencé à lire la user story et à nous lancer sur un de nos ordinateurs.

Le plus expérimenté de nous deux prit le clavier et lance le chronomètre. Sans doute pour rythmer les pauses me dis-je. Il prend son temps pour m’expliquer les tenants et aboutissants de ce qu’il fait. En commençant par les tests, puis l’implémentation. Doucement. Ce qui me permet, même sans avoir trop de recul, de comprendre un minimum ce qu’il se passe. Puis le chronomètre sonne. “A ton tour !” me dit-il.

Là, j’ai peur. Mes mains sont incapables de taper quoi que ce soit car mon cerveau est figé. En fait, je n’avais pas compris certains concepts et lui le remarque et prend alors le temps de les creuser avec moi. Revenant à certaines bases, il fait une sorte de cours particulier, s’assurant bien que je maîtrise ce que nous sommes en train de construire à deux. Le chronomètre sonne, il reprend le clavier tout en expliquant sa logique. J’ai le sentiment de comprendre, d’avoir une vision plus concrète, quand revient ensuite mon tour de coder. Moins de peur, je sais quoi taper pour commencer, c’est gratifiant ! Tour après tour, le rythme s’accélère.

Durant un mois, nous avons continué à développer comme ça, en pair. Les victoires étaient petites pour moi, mais constantes, et jamais je n’ai été laissé seul face au gouffre. Exit alors le sentiment de frustration.

Quant à la vélocité du projet qu’on pourrait penser ralentie, elle a finalement augmenté. Le deuxième mois de projet m’a vu faire mes premiers tickets avec plus d’autonomie. Sans challenger le statu quo, je me sentais valorisé car j’arrivais à produire de la valeur. Cette motivation m’a permise de maintenir mon implication et ainsi, de continuer efficacement ma progression. Dès que nous approchions de concepts nouveaux ou que j’avais l’impression de stagner, le pair me permettait de rebondir et d’apprendre sans blocage. Pour plusieurs raisons : je me sentais écouté, accompagné. Durant six mois j’ai rarement pu apprendre autant, progresser et me voir évoluer. Car quand on fait tourner le clavier, on est au même niveau : sur un pied d’égalité. L’idée n’est pas de coder en autonomie mais de partager des choix et de les discuter.

J’appréciais de plus en plus cette méthode qui me permettait d’apprendre continuellement. Alors la voix de chef de projet s’interroge : quel gain pour l’équipe ? Faut-il des formateurs pour tout le monde ? C’est alors qu’on se rend compte, au bout d’un moment, que les rôles évoluent.

L'équilibre

Un jour, sans qu’on s’en aperçoive, la discussion change. On remarque une interrogation dans les yeux de notre binôme. Cette question je me la pose aussi : aucun de nous deux n’a la solution parfaite à ce problème qui nous fait face. Il verbalise, demande mon avis, je réponds et renchéris sur une autre interrogation. Nous nous levons et allons faire des schémas au tableau. Une idée est en train d’émerger et, lorsqu’elle arrive à maturation, nous repartons face au clavier. Toujours en train d’avancer.

Le lendemain, pas de binômage. Je me lance seul et confiant sur une user story. Mon expérience grandissante m’aide à mieux voir comment avancer et à mieux identifier les obstacles qui se dressent sur ma route. Lorsqu’arrive un point que je n’arrive pas à résoudre, ma fierté fait que j’insiste pour essayer de trouver la solution. Un jour, deux jours passent et je stagne. Je tente et reviens en arrière. Voyant ma frustration, un des membres de l’équipe vient me voir et nous discutons du problème. Il n’amène pas de solution, mais me permet de prendre du recul. Au bout d’un moment, ça se débloque et je résous le problème. La solution technique est venue de moi, mais ce sont les échanges qui l’ont rendu possible. Échange qui aurait pu arriver plus tôt, si je ne m’étais pas entêté.

A ce moment, j’ai le déclic. Le fait de pair programmer, au-delà d’être un vecteur d’enseignement, est aussi vecteur de partage. Partager et communiquer c’est en permanence garder un recul et oublier ses a priori. Expliquer son problème à quelqu’un nous force à le présenter de façon différente. Le pair oblige à expliquer ses choix et donc à maintenir en permanence une cohérence. Le binôme devient alors plus performant que la somme des individus qui le compose.

En regardant en arrière, nombreux sont les moments où j’ai pu bloquer sur certains points, D’autres fois j’ai pu prendre des décisions trop rapides qui ont rendu complexes des évolutions. Cela pour plusieurs raisons : parce que fatigué, parce que sous pression ou parce qu’ayant honte de mes questions. Or, à deux, on se rend compte que nos questions ne sont pas isolées, qu’elles valent la peine d’être posées. Il n’y a pas qu’une seule bonne réponse à un problème donné.

Épilogue

En venant d’un monde ou l’apprentissage se faisait de manière académique, par des échanges à sens unique, j’ai été bluffé par les apports d’une méthode telle que le pair programming. Tout le monde est à égalité, l’expert comme le junior. Les frustrations sont évitées car on les élimine ou réduit à la source. La progression est rapide et permet à une équipe de se connaître et de se mettre à niveau.

Aujourd’hui, je le pratique de manière quasi systématique sur mes projets: que ça soit pour intégrer de nouvelles personnes, prendre des décisions techniques ou tout simplement pour assurer la qualité de ce qu’on livre. Car travailler en pair programming, c’est faire émerger des méthodes communes et des standards. En trouvant et en implémentant des solutions discutées et partagées, on arrive à créer un langage commun dans l’équipe. Ce même langage assure la cohérence d’un projet et lui permet d’avoir un niveau uniforme dans sa qualité.

Au-delà de l’informatique, binômer est une méthode de collaboration de proximité qui permet d’éviter les frustrations, d’assurer les échanges et de construire des équipes. On peut alors imaginer l'appliquer dans d'autres contextes, car dès lors qu'il y a des problèmes à résoudre, on pourra compter sur la synergie crée par les échanges entres deux personnes.