Déchirer avec le Pair Programming

Cela fait maintenant deux ans que nous travaillons en Pair Programming, et la probabilité de repartir en mode un par projet est d’environ 0%. Pourquoi? qu’est ce que ça nous apporte? Est ce que tout est positif? C’est ce que nous allons voir.

Ce que le pair programming apporte

Le Pair Programming permet d’avoir le point de vue d’une autre personne sur son développement. Ce point de vue devient continu et omniprésent, mais ne doit pas être oppressant 🙂 (fera peut être l’objet d’un autre article sur comment bien pair programmer).

Gagner du temps sur plusieurs étapes du cycle de développement

Le Pair Programming apporte de la qualité aux développements produits qui font gagner du temps sur plusieurs étapes du cycle de développement. En pratique, mon expérience montre que la Code Review est moins touffue en retours et de ce fait, peut se concentrer sur des éléments d’une plus grande valeur. Moins de déchets également sur les tests unitaires qui fonctionnaient avant le développement.

Et qui dit moins de tests à corriger, moins de retours à reprendre… dit plus de fonctionnalités développées au cours du sprint 😉

Autre chose, il est intéressant de changer régulièrement de partenaire de Pair Programming afin de se confronter à de nouvelles idées, des raisonnements différents, un apprentissage qui se renouvelle. A noter que comme indiqué dans l’article Wikipedia traitant de l’eXtreme Programming (Programmation en binôme), cela accroît aussi la connaissance collective du code.

Alone programming

Alone programming is boring

Est ce que tout est positif?

Il peut être difficile au départ de trouver ses marques, et si l’on n’est pas patient un minimum, on pourrait croire que le pair programming fait perdre du temps. Il faut un bon dosage de « présence » entre celui qui code et celui, plus en background, qui, je dirais, réfléchit plus globalement au développement en cours. Ainsi en pratique, je préfère n’intervenir avec le codeur que, lorsque je suis sûr de ma remarque et de son gain, plutôt que de penser tout haut… ce qui peut vite devenir contre-productif 🙂

Je n’ai pas d’autre chose à rajouter qui pourrait faire hésiter à utiliser cette pratique. Comme expliqué au début de l’article, le principal frein pour un manager peut être l’intuition de perdre du temps alors qu’on pourrait paralléliser les tâches. Là encore, pour être un peu plus précis, cette pratique chez nous montre que l’on gagne un peu plus de 25% de temps sur le développement d’une fonctionnalité (Ces calculs prennent en compte le temps de correction des anomalies suite à retour client, sachant que chez un éditeur logiciel, on ne gagne pas d’argent en corrigeant des bugs 😀 )

Advertisements

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s