Pair Programming : un retour d’expériences
Comme beaucoup d'autres, j'ai commencé à faire du pair programming sans le savoir, en dehors même d'un cadre de méthodes agiles. J'intervenais sur un projet de développement de librairie de calculs de risque financier et le langage était le C++. J'avais la chance d'avoir avec moi une collègue à la fois compétente et sachant réellement travailler en équipe. Je me souviens que nous avons mené à plusieurs reprises des séances en binôme devant le même écran pour résoudre les problèmes les plus difficiles. Je ne me souviens plus exactement du détail des sujets que nous traitions (c'était il y a 8 ans...). En revanche, je me souviens du sentiment de satisfaction qui en avait résulté. Nous étions allés au bout du problème, et nous avions trouvé une solution qui me paraissait optimale. J'avais perçue que la solution atteinte semblait satisfaisante également pour ma collègue et cela renforçait mon sentiment de travail achevé. Ce sentiment renforçait la satisfaction qui découlait de la réussite de ces taches difficiles. Ma motivation augmentait en conséquence.
Plus récemment, j'avais l'occasion d'aider une équipe dans l'adoption des pratiques agiles. Après une courte période d'hésitation, les membres de l'équipe acceptèrent d'essayer la pratique du pair programming. Elle fut adoptée en quelques jours et ne fut plus jamais remise en cause.
L'équipe s'en servait tout d'abord pour résoudre les problèmes difficiles. Ils avaient conscience d'avoir des échéances à tenir pour créer un logiciel complexe. Pour les parties les plus difficiles, il est apparu qu'une personne seule pouvait perdre plusieurs jours, alors qu'un binôme résolvait le problème en quelques heures. Au pire, le binôme démontrait qu'il ne pouvait pas y avoir de solution satisfaisante et proposait une nouvelle direction à explorer.
Chacun des membres de l'équipe avait des compétences bien balancées entre technique, fonctionnel et méthodes. Ils avaient aussi chacun leurs " spécialité ". Par exemple, un d'entre eux était particulièrement compétent et productif avec la technologie utilisée. Il codait au moins 2 ou 3 fois plus vite que les autres. Prenant conscience de cette situation, tout le monde, y compris cette personne particulièrement efficace, décida qu'il fallait qu'il binôme d'avantage. Cela permis d'abord de transférer son savoir-faire aux autres membres de l'équipe. Plus intéressant, il eu l'occasion de s'améliorer non pas en résolvant des problèmes encore plus compliqués, mais en trouvant des solutions plus simples aux problèmes qu'il connaissait déjà parfaitement. Ces solutions plus simples, se traduisirent immédiatement par un niveau de qualité du logiciel accru.
Les membres de l'équipe sont parvenus rapidement à un niveau de maitrise de cette pratique. Ils étaient capable de dire " sur ce sujet, il faut pair programmer ", ou bien " je viens de finir ce que j'avais à faire. Qui souhaite que je binôme avec lui pour l'aider à avancer? " Tout comme pour les autres pratiques de l'eXtreme Programming, le pair programming n'a jamais été perçu comme un dogme, un passage obligé. Il ne s'agissait pas de dire " eh ! ca fait deux jours qu'on n'a pas pair programmé ! Ca craint ! " Les binômes se formait uniquement sur la base du volontariat, et le choix entre solo-programming et pair-programming se faisait de manière consciente.
Généralement, durant un standing meeting, une personne exprimait une difficulté ou un problème. Le groupe décidait qu'il fallait trouver une solution. Une autre personne proposait son aide pour une séance de pair programming et le binôme était formé, sans autre forme de protocole. A chaque fois, il y a avait au départ l'envie de s'aider mutuellement et d'accomplir le travail ensemble. Parfois, cette envie diminuait et au bout d'un moment le binôme se séparait.
Tout comme il y a 7 ans, travailler avec cette équipe fut une source de satisfaction au travers de la réalisation de taches difficiles en groupe. Le pair programming nous a permis d'atteindre un sentiment de propriété collective du code. Nous avions une conscience partagée des qualités du logiciel que nous produisions mais également de ses limites. Les axes d'améliorations étaient facilement identifiables et l'équipe était alignée sur les décisions à prendre pour mener ces améliorations, ou ne pas les mener si la priorité n'était pas là.
Le pair programming nous apporte des bénéfices multiples : partage des compétences, augmentation de la qualité du logiciel, alignement de l'équipe, augmentation de la motivation. En arrivant demain matin à votre bureau, identifiez le problème auquel fait face votre équipe, mais également celui dont la résolution serait le plus rentable. Proposez aux collègues avec qui vous avez envie de travailler de pair programmer avec vous. S'ils refusent, acceptez leur réponse et si l'un d'entre eux accepte, attendez-vous à être surpris. :-)