Travailler en Pair Programming permet d'améliorer la qualité d'un logiciel et la collaboration des membres d'une équipe. Cela a de nombreux bénéfices, mais est-ce si simple à mettre en place ?
Marcos Brizeno, développeur chez ThoughtWorks au Brésil, partage son point de vue sur les difficultés d'adoption du Pair Programming dans un récent article de blog.
Marcos mentionne les challenges suivants :
- L'Infrastructure : une équipe devrait avoir des postes de travail similaires, même éditeur, même système d'exploitation, ....etc.
- La Fatigue : une meilleure concentration ne vient pas sans peine, se concentrer sur le problème, partager ses idées et écouter les autres demande beaucoup d'énergie.
- L'Ego : il faut savoir rester humble et écouter l'autre plutôt qu'argumenter.
David Green, développeur logiciel chez TIM Group pense que le Pair Programming n'est pas fait pour tout le monde. Il partage sa vision dans un récent article :
N'importe quelle équipe finit par contenir une variété de caractères. Les extravertis auront tendance à apprécier le Pair Programming, tandis que les introvertis vont avoir plus de mal et vont chercher à l'éviter. Ce n'est pas qu'une question d'éducation ou de persuasion, les bénéfices sont moins perceptibles et les plus introvertis apprécieront moins l'exercice que de travailler seuls.
Joe Barnes, producteur de caractères ASCII, mentionne le plagiat comme facteur poussant les équipes à arrêter le Pair Programming.
Je pense avoir compris le plus grand facteur de réduction de notre collaboration en paires. C'est le résultat indirect d'une vieille peur, celle du plagiat.
Marcos explique un exercice de rétrospective appelé "Cette personne et cette personne" pour conclure sur une liste de bonnes pratiques de Pair Programming. C'est à l'origine une activité de rétrospective postée par Paulo Caroli, coach Agile chez ThoughtWorks et Taina TC Caetano, développeur consultant chez ThoughtWorks.
Divisez un mur en deux sections, "Ne soyez pas cette personne" et "Cette personne déchire !" : dans la première, les membres de l'équipe écrivent un exemple de comportement qu'ils n'ont pas aimé, dans la seconde des exemples de ce qu'ils ont vraiment aimé.
Laissez ensuite l'équipe discuter de chaque exemple. La conversation devrait tourner autour du ressenti de l'équipe concernant certains comportements, les membres sont-ils d'accord que c'est une bonne chose à faire ? Dans certains cas, le comportement peut être apparent. Mais dans d'autres cas, cela peut mériter plus amples discussions.
Je vois cette activité comme une bonne façon de booster le moral de l'équipe. Avoir cette conversation mène généralement les gens vers une plus grande ouverture vers les autres, ce qui mène à plus de conversations. Une bonne manière de prendre la température d'une équipe est d'observer à quel point les membres communiquent. Une équipe silencieuse est souvent synonyme de déconnexion et d'un manque de partage d'informations.