samedi 15 février 2014

Le pair-programming - retour d'expérience


En 2010, j'ai eu la chance de vivre dans une équipe "Full Extreme Programming" pendant 15 mois. Bilan de cette expérience : des séances de développement intenses, un véritable travail d'équipe et un enrichissement technique et humain incomparable.

Je me propose dans cet article de revenir sur l'une des pratiques XP encore trop peu utilisée à mon goût : le pair-programming. 





Pair-programming et préjugés 


Le pair-programming est souvent vu d'un mauvais œil côté management : "2 développeurs par poste! Et pourquoi pas trois tant que l'on y est!". Ce sont d'ailleurs ces mêmes managers qui sont prêts à doubler la taille de leur équipe pour doubler leur productivité ... et leur bonus.

Cette "logique" mathématique n'est pourtant pas de mise dans d'autres métiers : un futur chirurgien par exemple devra apprendre les bons gestes, les bons réflexes aux côtés d'un chirurgien expérimenté pendant au moins une dizaine d'années . Est ce que le responsable d'un hôpital se pose la question de savoir si affecter 2 chirurgiens par opération divise par deux la productivité de son établissement ? Ayant été malheureusement obligé de passer de nombreuses fois sur une table d'opération, je peux vous dire que je suis plutôt rassuré d'avoir 2 spécialistes pour s'occuper de moi. Ce n'est pas leur productivité immédiate qui m'intéresse alors. Qu'importe si l'opération dure 2 ou 4 heures, du moment que la qualité de l'intervention soit au rendez-vous. Hors de question de devoir revenir pour me faire opérer à nouveau ou encore que l'opération soit un demi succès ...

Pair-programming et qualité


Il ne faut pas s'arrêter à cette impression visuelle de gâchis de compétences ou de non-optimisation du temps de travail des développeurs. Le pair-programming joue un rôle important dans la dynamique d'une équipe. Voici listées toutes les conséquences positives de l'adoption de cette pratique :

Diffusion des bonnes pratiques

La revue de code est un moyen de garantir que les bonnes pratiques se propagent petit à petit dans l'équipe. Le pair-programming est encore plus radical : le feedback est instantané ; nul besoin de modifier son code après coup : les conseils sont pris en compte en direct.

Augmentation de la qualité du code

Combien d'applications sont devenues de véritables "poubelles" de code après quelques années ? Pour les managers non techniques, voici un exemple de la vie réelle : Considérez cette baie électronique. Votre responsable vous demande de modifier ou d'ajouter une connexion sans bien évidemment faire de régressions. Quel est votre degré de confort pour intervenir dans un tel environnement ? Je vous pose cette question car c'est ce que vous demandez de faire chaque jour à de très nombreux développeurs alors que vous n'êtes pas conscient de l'état de votre application.

Le pair-programming permet d'éviter cette situation. La confrontation des idées et une prise de décision partagée permet d'aboutir à un code plus simple - et non simpliste - lisible et donc maintenable. Du coup, l'équipe continue à délivrer de nouvelles fonctionnalités de manière constante au cours du temps et ne se retrouve pas dans une situation de productivité quasi-nulle quelques mois ou années plus tard. 

Partage de la connaissance

Les développeurs intégrant une nouvelle équipe sont très souvent livrés à eux-mêmes, sans véritable formation. Du coup leur montée en compétence est lente et fastidieuse. Le pair-programming est une des meilleures réponses pour éviter cette situation. Dans mon ancienne équipe, nous avons intégré des stagiaires de la sorte. Dès le premier jour, ces derniers codaient et donnaient leur avis sur le code de l'application. Leur apport est immédiat : tout code compliqué est détecté et donc remanié aussitôt. Au bout de 6 mois de vie dans l'équipe, les stagiaires avaient le niveau d'un développeur plutôt expérimenté. 

La formation et le partage de connaissance via le pair-programming permet d'éviter le code propriétaire. Toute partie du code est connue par au moins 3 développeurs. Ainsi, toute absence d'un développeur ou tout départ en vacances ne met plus en risque l'équipe entière.

Pair-programming et pré-requis


La mise en place du pair-programming requiert cependant quelques éléments de base :

Un espace de travail qui n'entrave pas le déplacement

Un membre de l'équipe doit pouvoir circuler dans l'open-space sans gêner ses équipiers. Réfléchissez à l'agencement, la forme et la taille des bureaux ainsi qu'à l'environnement immédiat.

Une atmosphère de respect dans l'équipe

Le pair-programming a des implications sociales. Les relations entre individus, l'égo des personnes sont mis en lumière. Il est donc très important d'instaurer une ambiance de confiance, de respect afin que la parole de chacun soit écoutée. 

Une organisation non parasitée par les mails

Le pair-programming demande une grande concentration des personnes. Il et souhaitable que ces dernières soient préservées au maximum de tout parasitage extérieur. Impossible de lire une centaine de mails par jour comme cela est désormais légion dans beaucoup d'entreprises.

Pair-programming et dangers


Mise en place dans une équipe

Si une équipe est en cours de création, indiquer clairement aux postulants que le pair-programming est une des pratiques de l'équipe. Cela évitera d'embaucher des profils qui quitteront le navire avant même le premier mois de développement.

Si une équipe est déjà en place, forcer tous ses membres à pair-programmer peut être contre-productive. De nombreux développeurs ne souhaitent en effet pas pair-programmer : les personnes qui doutent d'elles-mêmes et les personnes non communicantes peuvent appréhender ces interactions forcées. Les faux experts, quant à eux, verront leur supercherie être rapidement démasquée.

Limitez plutôt dans un premier temps le pair-programming aux tâches complexes et/ou impactantes et  laissez l'équipe se faire un avis sur les expériences réalisées.

Rythme soutenable

Le pair-programming est une expérience véritablement énergivore. Les sessions doivent ainsi être limitées à 6 heures par jour pour que le rythme soit soutenable ... n'en déplaise à ceux qui ne valorisent que le temps de présence au travail et non le travail réellement effectué. Mais 6 heures de haute concentration sont plus productives que 10 heures à switcher entre son environnement de développement, les mails, internet et la messagerie  interne.

De même, laisser les développeurs travailler seul ou se former seul au moins une demi journée par semaine. Cet espace temporel permet l'émergence d'idées pertinentes pour améliorer le code ou les pratiques de l'équipe ou encore de réaliser des mini-projets de tests de frameworks, de nouveaux outils, de design ou autres.

Enfin, même si le pair-programming est de mise dans votre équipe, chaque développeur doit conserver son propre PC. Il est important que chacun puisse garder un espace personnel.

Le mot de la fin


Les problèmes d'une équipe de développement sont principalement des problèmes humains. Favoriser la collaboration, la communication et les interactions est bien souvent déjà un grand pas vers une solution. Alors qu'attendez vous pour expérimentez cette pratique sur vos projets ?