Pourquoi faut-il mettre en place le "pair programming" ?

Le "pair programming" (ou programmation en binôme en français) est une méthode de travail qui consiste à faire travailler deux développeurs ensemble sur une même machine et un même écran plutôt que de les faire travailler en parallèle sur des postes de travail différents.

Cette  méthode rentre dans le cadre du développement agile comme indiqué dans le "Manifeste pour le développement logiciel agile" à la phrase :

• Les individus et leurs interactions plus que les processus et les outils

Car oui c'est une forme de collaboration bien plus étroite que ce qu'on a l'habitude de voir dans le monde du développement en général, qui pousse les participants à échanger et transmettre leurs idées et leurs solutions de manière plus récurrentes et plus fluide.

Mais malgré les avantages que cela apporte, cette pratique a encore bien du mal à rentrer dans les mœurs des éditeurs de logiciels c'est pourquoi nous allons voir les avantages que cela peut apporter, et comment faire pour que la mise en place du "pair programming" se fasse dans les meilleures conditions !

Le principe

On a bien compris que cette pratique consiste à faire travailler deux développeurs sur la même machine, mais comment se passe exactement une session de travail ?

En pair programming, on va retrouver deux rôles bien distincts pour chacun des développeurs : le driver (conducteur) et l'observer (observateur). Aucun de ses deux rôles n'est à négliger car comme dans la navigation d'un paquebot, les deux métiers sont complémentaires : l'un va observer les éventuels écueils à éviter et la meilleure route à prendre, tandis que l'autre va tourner le gouvernail pour suivre la route tout en ressentant la force du vent et en jetant un œil sur l'état des machines.

Contrairement à la conduite d'un bateau, les deux développeurs doivent échanger de rôle très fréquemment pour profiter d'une session efficace.

Voyons tout de suite à quoi correspondent ces rôles dans le développement !

Le driver

Le rôle du conducteur est majoritairement d'écrire du code, du code propre bien évidemment, et il peut travailler très efficacement grâce à l'appui de l'observateur qui va pouvoir lui servir de guide.

C'est lui qui a entre les mains le clavier et la souris, on lui attribue le côté tactique (opposé au côté stratégique) et dois pouvoir se concentrer sur l'optimisation du code, sa documentation et tout ce qui touche directement au code pur.

L'observer

Le rôle de l'observateur va être de réfléchir à la structure du projet dans son ensemble, de faire les choix stratégiques en matière de design mais surtout de faire une review continue des lignes de code au fur-et-à-mesure qu'elles sont tapées.

C'est malheureusement un rôle qui est parfois pris à la légère alors qu'il est indispensable à l'équilibre du binôme et à la qualité du logiciel produit !

Les bonnes pratiques

Voici quelques conseils afin que la mise en place du pair programming se fasse sans douleur dans votre projet (et votre entreprise).

Changer ses perspectives

La plus grosse peur qui freine la plupart des entreprises à mettre en place cette pratique reste la rentabilité jour-homme du développement du projet, qui n'est en fait qu'un problème de perspective.

Effectivement, si l'on fait travailler deux développeurs sur une même machine, on écrira potentiellement deux fois moins de code dans le même temps. Sauf que les gains de cette pratique peuvent être gigantesques si l'on sait où et quoi regarder.

Mettre en place un bon pair programming permet :

• D'écrire du code plus robuste et efficace
• De diminuer les coûts liés au support et debuggage
• D'avoir une base de code plus facilement réutilisable car mieux réfléchie
• De former ses développeurs en continu et beaucoup plus efficacement
• D'améliorer la communication et le team-building au sein des équipes
• De faire rentrer la patience et la pédagogie dans les valeurs de l'entreprise

L'introduire progressivement

Que vous soyez développeur ou chef de projet, il n'est pas nécessaire d'essayer d'imposer le pair programming comme quelque chose d'exclusif, vous pouvez très bien proposer de le mettre en place qu'un jour par semaine pour commencer.

Ensuite si cette méthode fonctionne correctement, essayez d'augmenter progressivement le nombre de jours dans la semaine jusqu'à arriver à votre point d'équilibre.

Il est aussi possible de le mettre en place ponctuellement pour certaines tâches sensibles requièrant une plus grande vigilance et qualité de code, comme des systèmes financiers par exemple !

Ne pas forcer les développeurs

Certains développeurs sont très patients et pédagogues de nature, tandis que d'autre ne le sont pas du tout. N'imposez pas le pair programming à des développeurs qui ne seraient pas à l'aise avec le concept, laissez germer l'idée, laissez-leur le temps de voir les résultats de la méthode et peut-être qu'ils changeront d'avis à la longue.

Mieux vaut pas de pair programming, qu'un pair programming qui se passe mal !

Mélanger les niveaux

L'apprentissage et la montée en compétence sont des vrais points positifs de cette méthode, et mélanger différents niveaux peut-être encore plus bénéfique.

Faire travailler un développeur expérimenté avec un développeur junior va permettre à l'un de progresser plus rapidement et d'acquérir les bons réflexes plus vite, tandis que les interrogations du développeur junior pourront permettre de remettre en questions les procédés établis depuis parfois trop longtemps et qui n'ont plus lieu d'être aujourd'hui.

Attention néanmoins à ce que le binôme fonctionne bien et que le junior ne soit pas simplement relégué au rôle d'observateur ad vitam eternam, ce qui annule tout bénéfice du pair programming !

Alterner les rôles

Comme expliqué précédemment, l'alternance des rôles est capitale et doit se faire sur des périodes relativement courtes (moins d'une demie-journée), sans être trop courte non-plus (pas moins d'un quart d'heure).

Cela permet au conducteur d'avoir le temps d'accomplir une ou plusieurs tâches et à l'observateur de garder une stimulation suffisante.

Personnellement je situerai la période optimale entre une demie-heure et une heure, mais l'idéal est que le binôme trouve lui-même son rythme de croisière pour faire une session la plus efficace, stimulante ET agréable possible.

J'espère que cet article vous aura plu, n'hésitez pas à me dire si vous avez mis le pair-programming en place dans votre entreprise et quels en son retours !