Pas si simple de pair programmer

Le pair programming est la pratique du "craft" que j’ai le plus de mal à utiliser, et sur laquelle j’ai le plus de réserves. Ma lecture en cours du livre "Software Craft - TDD, Clean code et autres pratiques essentielles" m’a fourni un peu plus matière à réflexion, et a amené quelques échanges intéressants avec mes collègues (Note : je viens de passer trois jours en compagnie mes collègues de Mee6 en Finlande pour notre "Get together" annuel.).

Mon expérience personnelle du pair programming est pour le moins mitigée. Je ne l’ai jamais vraiment pratiqué régulièrement selon les règles de l’art. En fonction des équipes avec lesquelles j’ai travaillé ces dernières années, je l’ai pratiqué, selon les cas, d’occasionnellement à pas du tout, dans des formes dérivées.

Les limites (ou difficultés) que j’ai rencontrées personnellement sont de plusieurs ordres.

Tout d’abord, la pratique est assez épuisante pour moi. Du fait de mon profil, et bien que je l’apprécie dans certaines circonstances et à petite dose, elle me prend énormément d’énergie et s’accompagne généralement d’un peu de frustration.

La pratique nécessite, par définition, beaucoup de synchronicités. Pour des équipes distribuées, habituées à travailler en asynchrone à haute dose, cela peut être difficile à mettre en place. La perte d’asynchronicité notamment peut être ressentie comme une forme de gaspillage.

Les problèmes d’alignement, sur le niveau d’expérience, l’utilisation de pratiques comme TDD par exemple, peuvent également rendre l’exercice difficile, voire très frustrant. Par ailleurs, la pratique nécessite un niveau de sécurité psychologique important entre les binômes, ce qui n’est pas si évident à trouver.

Dans les échanges que j’ai eus, ce sont souvent ces mêmes problèmes qui reviennent, et qui amènent des réticences à essayer d’utiliser la pratique pour régulièrement et de façon structurée.

Pour autant, je reconnais les apports de la pratique, et je pense en comprendre l’objectif de fond : optimiser le flux de l’équipe plutôt qu’optimiser individuellement, ce qui ne conduit pas nécessairement à un optimum local. Le fait qu’elle soit si souvent poussée éveille ma curiosité. Est-ce que je rate quelque chose, ou est-ce que simplement, c’est une pratique complexe à mettre en œuvre ?

Je reste assez sceptique lorsque je vois des assertions prescriptrices sur le sujet (j’ai notamment le souvenir du livre eXtreme Programming de Kent Beck dans ce style). Je peux admettre l'idée que en théorie, une équipe délivrera mieux si elle peut pair programmer (voir mob programmer) en permanence. Mais en pratique, vous devez faire avec la réalité des équipes, des profils psychologiques, des besoins des uns et des autres.

Comme souvent, il faut probablement rester très contextuel et pragmatique pour utiliser cet outil. Construire un contexte favorable, expérimenter, tenir compte des besoins de tous les membres de l’équipe, former, changer nos habitudes progressivement.

Le chapitre consacré au pair et au mob programming dans "Software Craft - TDD, Clean code et autres pratiques essentielles" est d’ailleurs très intéressant de ce point de vue. L’approche des auteurs semble très pragmatique, indique les apports de ces approches, mais aussi les difficultés. De nombreux conseils sont donnés pour conserver une approche bienveillante et tenant compte des besoins de chacun dans l’équipe.