Discussion sur les mérites du "Pair Programming"

Un article d'InfoQ: Debating the Merits of Pair Programming rappelle que la programmation en binôme est un sujet des plus discutés parmi les pratiques que propose Extreme Programming.

La lecture de l'article et des études référencées donne de quoi se faire une idée. Mais le mieux est encore d'essayer. C'est ce que mes étudiants vont faire dans les jours qui viennent sur leurs projets. Le contexte s'y prête assez bien : début janvier chaque équipe [1] passe de 5 à 10 ou 11 personnes. Les nouveaux sont des étudiants de l'année précédente [2] qui ont moins de compétences à la fois sur le plan technique et sur le domaine fonctionnel. Travailler en binôme [3] évite à un nouvel arrivant dans l'équipe d'être bloqué avec la peur de faire une bêtise. Comme le dit Kent Beck dans l'article, c'est déjà le moyen de faire partager les pratiques de l'équipe. Cela a été expérimenté les années précédentes. Avec succès sur la plupart des projets.

Notes

[1] des étudiants de M1 travaillent sur le projet depuis début octobre

[2] L3

[3] un étudiant M1 avec un étudiant L3

Commentaires

1. Le jeudi 11 janvier 2007, 10:12 par sylvek

ok pour le pair-programming comme moyen d'apprentissage rapide des méthologies employées dans un projet. mais je reste assez perplexe à l'usage d'une telle méthode lorsque les informaticiens ont le même niveau mes des approches différentes.. celà ne casse pas la productivité au dépend d'eternelles discussions n'aboutissant qu'à une dégradation de l'ambiance de l'équipe?
je prefere une discussion en amont du/des problèmes à surmonter mais en laissant à la personne assigné au probleme la façon d'implementer la solution. Sans revenir sur le problème si pas necessaire. Pas de discussion post résolution en gros si le problème est résolu dans le scope défini.
Ainsi j'espere que cela responsabilise plus les personnes tout en prenant en compte toutes les solutions disponibles.

2. Le jeudi 11 janvier 2007, 13:28 par claude aubry

Sylvek je suis d'accord avec vous pour considérer le travail en binôme comme une pratique optionnelle qu'il ne faut pas imposer. Si on essaie, il est préférable que les participants soient tout à fait volontaires et que les conditions de travail soient aménagées pour cela.

3. Le jeudi 11 janvier 2007, 18:30 par Stéphane Boisson

Pour moi le principe du pair-programming c'est developper en binome, pas taper au clavier en binome.. Ce n'est pas vraimment dans l'esprit agile de mesurer la productivité en fonction du nombre de lignes de code tapées.
L'interet c'est évidement la discussion, qu'elle est lieu avant ou pendant qu'on tape au clavier c'est au binome de décider..

Si l'argument pour rejeter le pair programming est qu'on perd du temps à obtenir un consensus, j'ai l'impression que ca augurerai mal pour l'équipe et l'évolution du logiciel.. l'argument risque d'être aussi retenu plus généralement..
Le consensus sur l'architecture, la conception me parait important pour l'équipe (Collective Code Ownership).. Sinon on risque un peu d'avoir des personnes qui ne voudront pas toucher à des parties du logiciel conçues sans leur consentement, et on s'expose à un risque accentué de technical debt..

4. Le jeudi 11 janvier 2007, 23:31 par Oaz

Sylvek,
en ce qui me concerne, parmi les rares occasions où j'ai travaillé en paire, j'ai surtout apprécié le cas "même niveau". Si l'écart entre les 2 personnes est trop grand, j'ai toujours tendance à voir le travail en paire comme un apprentissage à trop grand vitesse pour celui qui en sait le moins. Comme quoi tout est affaire de goût et que le mieux est d'essayer...

Par ailleurs, c'est vrai qu'il est utile d'avoir des choses qui "responsabilisent plus les personnes" mais c'est quand même mieux d'avoir des choses qui responsabilisent plus l'équipe dans son ensemble, non ?