Le “pair programming”, ou programmation en équipe laisse rarement indifférents ceux qui connaissent cette méthode de travail : efficace et flexible, elle peut néanmoins rapidement paraître épuisante et parfois frustrante si les différents membres de l’équipe s’en tiennent à leur opinion. Les processus itératifs sont monnaie courante dans la création de logiciels. D’un côté, il y a les développeurs qui définissent différentes fonctions, généralement seuls, et de l’autre, ceux qui vérifient le code et formulent des propositions de modifications qui sont ensuite transmises aux développeurs concernés. Ce qui fait la spécificité du pair programming cependant, c’est la simultanéité : deux développeurs travaillent sur la même tâche devant un même ordinateur, avec deux écrans. Ils programment donc simultanément mais aussi, et surtout, ensemble. Lors de la programmation, ils peuvent parler, critiquer, discuter et intégrer en permanence de nouvelles options.

Mais en quoi le pair programming est-il plus efficace ?

Le fait que la vérification et le refactoring du code se fasse pendant le processus de développement permet d’éviter les cycles de révision chronophages et lourds en charge de travail lors des projets de développement classiques. Cela permet également de gagner du temps : les développeurs n’ont pas à attendre que l’autre ait terminé sa partie, et grâce à leur travail conjoint ils ont deux fois plus d’idées et font deux fois moins d’erreurs. Cette étroite collaboration favorise le brainstorming spontané, les informations sont échangées de manière directe. Il est parfois utile de faire travailler ensemble, non pas deux développeurs spécialisés, mais un développeur et un concepteur ou un responsable produits. Ces derniers ont une autre vision du produit et apportent ainsi leur contribution à un stade précoce.

Dans le cadre du pair programming, il est aussi particulièrement important de définir au préalable les objectifs et les attentes du projet et de la collaboration. Il est également nécessaire de s’interroger sur la façon la plus efficace d’évoluer ensemble : s’agit-il d’échanger des connaissances ou plutôt d’apporter de nouvelles techniques ? S’agit-il de la collaboration de deux développeurs expérimentés ou d’autres connaissances spécialisées doivent-elles être ajoutées ? Ce travail préalable permet d’éviter les malentendus et les détours.

Une structure fixe pour les développeurs en binôme

Pour certaines équipes, la collaboration est plus facile lorsqu’elle se déroule selon un modèle défini. Cela signifie que chaque partenaire possède plus ou moins un rôle. Les équipes composées d’un navigateur et d’un conducteur fonctionnent ainsi très bien dans la pratique. Le conducteur est celui qui convertit et code les idées et les propositions du navigateur. Le navigateur ne donne aucun ordre direct, il oriente plutôt dans la direction souhaitée. La collaboration est ainsi basée sur les impulsions données par l’un et la conversion pratique de l’autre, ce qui est parfait pour vérifier l’adaptabilité et la faisabilité des idées. Les rôles doivent être inversés à intervalles réguliers et courts.

Il peut également être utile de se renvoyer constamment la balle comme dans le cadre d’un match de tennis de table. Quelque chose qui fonctionne bien dans le domaine des développements basés sur des tests (TDD) : un développeur rédige un test erroné et le remet à son partenaire. Celui-ci met en application le minimum nécessaire pour réaliser le test. Il complète ensuite le code de son côté, de manière à ce que le premier partenaire puisse effectuer le test. Certaines équipes sont les plus efficaces lorsqu’elles travaillent de manière non structurée, surtout quand les deux membres se connaissent déjà et estiment les capacités de l’autre.

Ils doivent également examiner ensemble les propositions d’améliorations et apprendre l’un de l’autre. Il est nécessaire de laisser sa sensibilité de côté et de savoir accepter les critiques. L’empathie, la confiance et la serviabilité aident les équipes à s’améliorer et à renforcer leur efficacité.

Le Digital Lab de Volkswagen est la preuve que le travail de pair programming fonctionne. Ainsi, VW a lancé en 2015 son laboratoire informatique à Berlin, en collaboration avec Pivotal. Aujourd’hui, le laboratoire emploie 60 employés de plus de 25 pays qui collaborent à des solutions logicielles. Le concept autour des méthodes de travail agiles et du pair programming s’est tellement bien établi au cours des quatre dernières années que six autres digital factories ont été créés au sein du groupe.

Le pair programming n’est pas une méthode qui permet aux développeurs de travailler huit heures par jour sur un projet. Cette façon de travailler serait en effet trop épuisante et n’offrirait pas suffisamment de temps pour approfondir les éléments. Le pair programming est cependant une extension utile : il est possible d’intégrer plusieurs regards simultanés au travail et de créer un meilleur code grâce à une communication ouverte.