Rien ne vaut un retour d’experience reel, et non pas un pre-suppose a la lecture de docs …
http://www.design-up.com/methodes/XP/retourexperience.html

justement, ca marche pas. je suis devenue si malheureuse.. Je n’avais plus envie d’aller au travail..

C’est vrai que le “pair programming” est une technique particulière qui n’est pas évidente (voir “Will Pair Programming Really Improve Your Project?” http://www.methodsandtools.com/archive/archive.php?id=10) mais mon opinion est qu’il ne faut pas rejeter (ni adopter) les approches agiles “en bloc". Tout dépend du contexte, des participants au projet, etc. Il y a des techniques de bases (tests unitaires, discussions des priorités avec les utilisateurs, point de situation fréquents) communes aux approches agiles qui ne sont pas forcément généralisées (;0[)et qui peuvent améliorer les résultats d’un projet.

Ma première approche m’a aussi conforté dans l’idée que les binômes doivent être homogènes. Associer des personnes d’un niveau technique très différent peut dégrader l’ambiance du binôme et donner l’impression au “plus expérimenté” qu’il est le seul à travailler.

Ben moi faute de temps on ne fait plus de pair programming et ca me manque.

Contrairement à ce que je lis, non on était pas homogène du tout par contre on savait accepter la remarque.

on “pair-progammait” mais on pair-concevait aussi.

On pair programmait pour créer les lib
parfois un duo s’arretait un soir et c’était un autre qui reprenait le lendemain.

Ca force plein de truc.
Commenter le code, comprendre les habitude des autres, dès le départ ne pas générer du code très/trop personnel, …

Par contre le code pour “utiliser” les lib on code en solo mais on se tape des délire et débats sur les interface. Quand on a une “idée géniale” on la dit tout de suite pour être sure qu’elle se fasse démonter et attaquer sur toutes ses failles et limites pour pouvoir repartir sur une nouvelle version de l’idée.

Quand enfin elle ne semble plus avoir d’idées dans son concept, soit on la code seul avec les lib qu’on a déjà soit avec du code “de travail” qui sera à refactoriser.

Le tout c’est d’arriver à coder pour le code, pour l’outil, avec un but le contentement de l’utilisateur, pas celui du codeur. (ca n’empèche d’être heureux du travail réalisé :)