C'est la pratique XP qui a le moins de succès au sein de la communauté large de l'IT. On voit fleurir quantité de billet de blog pour dénigrer cette pratique, on lui préfère la revue de pair (faite par un chef, tu m'étonnes ...), on trouve cela stupide de dépenser deux fois le temps nécessaire pour faire la même chose.
Nous allons voir en quoi cette vision relève d'une incompréhension profonde de ce qu'est le pair programming et l'agile en général. Je vais essayer de briser quelques mythes et de montrer en quoi cette pratique donne toute son efficacité au TDD et à l'eXtreme programming.
BRISONS LES MYTHES
Quasiment tous les commentaires négatifs sur le pair programming (mais aussi sur le TDD) sont le fait de gens qui n'ont manifestement pas compris ni pratiqué l'eXtreme programming.
- Le pair programmming ce n'est pas être deux derrière un clavier
- Le pair programming ne fait pas dépenser deux fois plus de temps, il en fait gagner, même à court terme
- La revue de pair ne peut absolument pas remplacer le pair programming, il n'agisse pas au même niveau
- Le co-pilote n'est pas le petit nouveau qui vient d'arriver et qui ronfle sur son siège et hoche la tête de temps en temps
Le pair programming consiste à travailler en binôme, constitué de deux rôles :
- le pilote tient le clavier et tape sur les touches
- le co-pilote qui guide les développements du pilote
Le co-pilote est responsable de rythmer la séance de codage, il doit indiquer quelle est la prochaine étape (à 100m virage à droite en 4e), le prochain test à écrire.
Le co-pilote est aussi là pour insuffler du courage dans le binôme. N'ayant pas la pression de tenir le clavier, il doit prendre de la hauteur, rappeler les principes du clean code, la règle du boy-scout etc... Si à un moment donné, il faut arrêter de coder une nouvelle fonctionnalité pour refactorer une part importante du code existant, il doit pousser le pilote à le faire.
En ce sens, et à l'inverse de ce que beaucoup font quand ils essaient le pair programming, il est nécessaire que le co-pilote soit experimenté en développement et en eXtreme programming.
POURQUOI QU'ON FAIT CA ?
Une des 5 Valeurs de l'eXtreme programming, le feedback est présent à tous les niveaux des pratiques de la méthode agile.
Le pair programming est l'élément produisant du feedback à la granularité la plus fine, de l'ordre de la seconde.
La discussion, qui a lieu en permanence entre les deux membres du binôme, permet de générer un feedback constant sur ce qui est fait, pourquoi cela est fait et comment cela est fait.
Il y a bien sur d'autres apport à cette pratique mais produire du feedback en est le principal atout.
OUAIS MAIS CA ME RAPPORTE QUOI A MOI ?
La pratique du pair programming apporte des bénéfices à quantités de niveaux :
- le feedback permanent, comme expliqué plus haut
- du courage (une des valeurs de l'eXtreme programming) pour produire de la qualité, améliorer constamment l'existant, résister à la facilité
- permet un meilleur partage du code entre tous les membres de l'équipe (une autre des pratiques de l'eXtreme programming), un meilleur consensus autour des bonnes pratiques de l'équipe
- la montée en compétence des nouveaux venus ou le transfert de connaissance n'est jamais aussi efficace qu'avec la pratique du pair programming
- de manière générale la communication au sein de l'équipe, car pratique de tout instant au sein du binôme
POURQUOI TANT DE RESISTANCE ?
Le pair programming est une pratique sans concession, très exigente, où il est très difficile de faire semblant. Si nous ne supportons pas de se voir reprendre car nous n'avons pas fait parfait du premier coup, si nous n'aimons pas communiquer, partager nos manière de faire avec nos collègues, si nous ne sommes pas dans un état d'esprit permettant la production et la recherche permanente de feddback, il devient très douloureux de pratiquer le pair programming.
En ce sens, il est contre-productif de forcer un développeur à "pairer" avec ses collègues s'il n'aime pas ça. Cela met en lumière la nécessité de bien choisir ses co-équipiers si l'on souhaite mettre en place l'eXtreme programming dans son projet.
LE MYTHE DU TEMPS PERDU
Je n'arrête pas d'entendre à longueur de temps répéter la croyance que le pair programming est très couteux en temps. Je parle de croyance car il est clair pour moi que ce type de discours est tenu par des gens ne pratiquant pas sérieusement le pair programming.
Mon experience personnelle est à l'exacte contraire de cela.
J'ai en mémoire un cas précis. Sur un projet, j'avais une moyenne de 1000 lignes modifiées sur une semaine de travail (ajout, modification et suppression de ligne - statistique github).
Nous avons, avec un collègue (lui aussi convaincu de la puissance du pair programming), "pairer" sur une période d'une semaine. Nous avons en effet consommer le double de jours homme sur une même machine. Cependant, nous avons, sur cette période, modifiées plus de 6000 lignes de code !
Nous avons livrer dans les temps nos User Stories à la fin du sprint et refactorer une grande partie de l'application sur laquelle nous travaillions (règle du boy-scout oblige).
PAIR OU PEPERE
Il est aussi vrai que pour atteindre ce niveau de productivité avec le pair programming, il ne suffit pas de se mettre à deux derrière un écran d'ordinateur.
Il est nécessaire que chaque membre du binôme soit conscient du rôle qu'il occupe, que la communication soit fluide et que le consensus soit rapide à atteindre.
Pour ce faire, il faut que les deux est une bonne connaissance du Test Driven Development, qu'ils s'entendent bien et soient prêt à sacrifier temporairement leur point de vue subjectif au profit de l'harmonie du binôme.
Le TDD est la condition si ne qua non pour une pratique efficace du pair programming, c'est le lien, l'histoire, qui permet au binôme de se comprendre, de rythmer la phase de développement. Sans le TDD, cela devient vite pesant, la communication s'effiloche, le pilote n'explique plus ce qu'il fait au co-pilote qui inévitablement commence à s'endormir au bout d'un moment = le pépère programming :)
PARTAGER LE CLAVIER
Une bonne séance de pair programming doit voir régulièrement, les rôles s'échanger au sein du binôme. Cela permet de garder un rythme et une concentration poussée de la part des deux développeur.
Cependant, il n'est pas naturel pour un développeur de partager son clavier, de faire une place dans son domaine, son bureau, ou il y a divers papiers, notes, objets personnels qui traînent un peu partout. Pairer sur le bureau d'un des binômes rend souvent la session inconfortable pour les deux, l'un se sentant envahit, l'autre se sentant de trop.
Il est ainsi très recommandé, de disposer d'un bureau neutre, dit bureau de pair, avec deux écrans et deux clavier, ou chaque membre du binôme se retrouve à égalité pour prendre les commandes. C'est une des recommandation faite dans le livre sur l'extreme programming de Kent Beck : un ilôt central de bureau pour pairer et sur les bords de la pièce les bureaux personnels de chaque développeur de l'équipe, pour tous les moments où il travaille ou s'occupe seul.
JOUER AU PING-PONG
Une variante connue est le ping-pong pair programming. Cela consiste à changer les rôles dans le binôme à chaque fois qu'un test passe au vert. Le pilote écrit un test qui échoue, il écrit le code permettant de le faire passer au vert et passe le clavier au co-pilote qui devient pilote. Celui-ci peut alors refactorer, puis écrire un test qui échoue et ainsi de suite.
Cela donne un rythme très soutenu à la session de codage.
LA PAUSE S'IMPOSE
A deux, pas question de faire des pauses pour lire ses e-mails, pour faire ses courses sur internet. De plus, il faut expliquer ce qu'on fait, discuter avec son binôme en permanence de la meilleur manière de procéder.
Tout ceci est épuisant à la longue, et après 5 heures de ce traitement, tous les développeurs sont rincés.
Il est nécessaire de faire des pauses régulière entre chaque session de codage et de ne pas chercher à prolonger l'aventure plus de 5 heures par jour, au risque de voir la qualité de vie du binôme diminuer et les erreurs s'accumuler.
Beaucoup de praticiens expérimentés en pair programming sont d'ailleurs de fervent partisan de la méthode Pomodoro, permettant de rythmer une séance de travail en alternant période de travail sans perturbation extérieure et pause.
INSTAURER LA PRATIQUE DU PAIR PROGRAMMING DANS VOTRE EQUIPE
Un des meilleurs moyen pour instaurer la pratique du pair porgramming dans vos équipes est d'organiser régulièrement des conding dojo randori. Il s'agit d'un exercice chronométré consistant à résoudre un problème simple de programmation en TDD et pair programming. L'idée étant de projeter l'image de l'écran de l'ordinateur sur un mur, via un rétro-projecteur, et de permutter les rôles entre pilote et co-pilote toutes les 5 minutes. Ainsi, deux personnes vont jouer le rôle de pilote et co-pilote. Au bout de 5 minutes, le pilote quitte le binôme. Le co-pilote devient pilote et un autre membre du groupe prend la place de co-pilote et ainsi de suite.
DES OUTILS RIGOLOS POUR S'Y METTRE
Il existe différents plugin eclipse permettant de rendre ludique la pratique du pair programming. Le plus connu étant le plugin PairHero.
CONCLUSION
Après cet interminable article, il est temps de conclure.
Vous voyez déjà que le sujet est vaste. J'aurais pu encore en dire plus, tellement cette pratique d'apparence simple, recelle de richesse et d'apports précieux à la pratique du développement d'application.
Le pair programming s'inscrit au coeur de l'extreme programming. Il enrichit grandement les autres pratiques comme le TDD ou le partage collectif du code.
Il est nécessaire de le pratiquer avec des gens motivés à le faire mais pas trop longtemps car cela est épuisant.
Contrairement à la croyance répandu, le pair programming ne coute pas plus en temps, il peut même rendre l'équipe plus productive.
Sa pratique encourage le respect des bonnes pratiques de clean code, la communication dans les équipes et la responsabilisation des développeurs dans leur travail.
Il met en évidence une valeur central des méthodes agiles : le FEEDBACK. L'arme principale permettant de survivre au sein du chaos, de répondre au changement perpétuel d'un projet informatique.
Vous l'aurez compris, je suis un fervent partisan du pair programming, mutualiser mon cerveau avec un collègue m'a toujours rendu bien meilleur dans mon travail.
eXtreme programming
pair hero
Pomodoro
Le bouquin de Kent Beck sur l'eXtreme programming
Aucun commentaire:
Enregistrer un commentaire