Lorsque l'on gère une nouvelle équipe en
eXtreme Programming, ils existent des aspects auquels les développeurs - qui proviennent du développement classique - vont devoir se confronter.
En général, les développeurs travaillent suivant un concept relativement simple: chacun dans son coin et on centralise à interval régulier (si cela est le cas) l'ensemble du travail (à l'aide d'un repository par exemple)
Dans la méthodologie XP, beaucoup de points divergent entre méthode classique et eXtreme Programming;
Dans l'ensemble, la plupart des nouveaux aspects - traités en XP - sont relativement simples à mettre en oeuvre pour une équipe fraichement déabarquée: la publication rapide des travaux, les tests unitaires, la conception simplifiée, le refactoring sont des points qui - après un petit temps d'adaptation - deviennent naturels chez les néo-développeurs XP convertis;
Il existe cependant un point qui (peut) se révèler des plus trouble pour pas mal d'entre eux: Le pair programming (ou programmation à deux).
Pour faire simple, je prendrais la définition provenant de Wikipedia :
"Pair Programming" ou "Programmation en binôme"
La programmation se fait par deux. Le premier, appelé driver, a le clavier.
C'est lui qui va travailler sur la portion de code à écrire.
Le second, appelé partner, est là pour l'aider, en suggérant de nouvelles
possibilités ou en décelant d'éventuels problèmes.
Les développeurs changent fréquemment de partenaires, ce qui permet
d'améliorer la connaissance collective de l'application et
d'améliorer la communication au sein de l'équipe.
Extreme Programming / Wikipedia
L'aspect semble relativement simple au premier regard;
Chaque développeur travaille avec un autre programmeur.
Simple non ?
Pas forcément;
Il existe un élément qui a été écarté : L'aspect psychologique de la chose: celui de la proxémie et du concept » d'espace vitale »
Le concept de l'espace vital se présente sous cette notation :
Chaque personne dispose d'un espace vital virtuel.
Si un inconnu rentre dans ce périmètre, l'autre peut l'interpréter
comme une attaque.
On peut estimer ce périmètre à une longueur de bras.
Le regard qui se situe dans cet espace vital prend donc beaucoup d'importance.
Le périmètre public se situe environ à deux mètres de l'autre personne.
Texte de ciao.ch
Il se peux que je me trompe [1], cependant je n'ai pas remarqué une allusion dans les analyses que j'ai pu lire ou entrendre (publications ou rencontre avec des experts XP).
Devant un écran, il est (très) souvent difficile d'être parfaitement concentré lorsqu'il existe une présence derrière ou à coté de soit.
Que ce ne soit par des accès fréquents derrière son dos (une porte, un couloir fréquenté, ...), ou bien un collègue venant regarder votre écran.
( Avouez que vous vous êtes déjà retrouvé dans une situation pareil et que cela vous rendez nerveux 
La méthode XP impose cette restriction: celui d'avoir un pair qui valide le code avec vous.
Si les programmeurs s'entendent et se respectent, la "fusion" peut très bien se passer;
Cependant, Quid lorsque deux développeurs ne peuvent s'entendre ?
Il existe de nombreux cas qui peuvent s'accorder avec cette problématique :
- Un développeur qui n'aime pas un collègue bien particulier
- Un développeur trop orgeilleux
- ...
La méthode classique consiste à placer les deux développeurs devant un même écran et un même clavier;
Cependant, une autre approche permettrait de démarrer progressivement le pair programming sans braquer le ou les développeurs.
Elle consisterait à séparer les unités de contrôle et de vision: l'écran et le clavier.
Rendre indépendant ces deux périphériques mais connecté toujours sur un seul et même ordinateur (unité centrale ou portable)
De plus en plus (voire la majorité maintenant) de machine - même portable - propose aux moins deux ports USB;
Il suffit de brancher deux claviers pour que les deux développeurs puissent ne pas ressentir de frein ou la sensation de ne pas maitriser le développement en cours.
Concernant les écrans, ils existent des cartes gérant le DualHead, qui permettent, soit de créer une copie parfaite de l'un des écrans virtuels (TwinView, Clone, etc...), soit d'avoir un écran virtuel indépendant (TwinView).
Les deux développeurs peuvent avoir une légère séparation entre eux: Allant de quelques centaines de centimètres, voire être l'un en face de l'autre de la table.
Le développement en Pair Programming n'est pas bouleversé par ce changement car l'écart se révèle être très minime pour la communication entre les deux protagonistes;
Les deux ayants la même perception du développement et pouvant interargir directement sur la construction du code sans subir une
quelconque pression de
leur(s) environnement(s): les deux développeurs qui ne pourraient travailler en pair programming peuvent le faire sans être restreint.
Cela ne constitue pas une fin en soit, mais testé sur une équipe de développeurs, les résultats ont été plutôt positifs
EDIT: Il existe une autre méthode, la méthode vnc:
Lancez un vncserveur sur le poste "serveur" (
x11vnc [
1] est très bien)
Puis un vncviewer depuis le ou les postes clients
A une certaine époque, je m'occupais d'un 
.
