L'idée générale qui est adoptée par la plupart des théoriciens Agile / XP semble être que les paires devraient s'échanger régulièrement. Par exemple, chaque programmeur doit échanger des paires une fois par jour; la moitié des personnes échangent en début de journée, la moitié des personnes échangent après le déjeuner: en raison de facteurs externes tels que les réunions, les vacances, etc. assez uniformément à travers l'équipe.
L'une des raisons qui expliquent les échanges fréquents est que les connaissances se répartissent rapidement et uniformément au sein de l'équipe, plutôt que d'avoir des compétences et des connaissances spécifiques concentrées sur des individus particuliers - ce qui implique que le travail peut se poursuivre en douceur si des personnes sont absentes ou quittent l'entreprise. Une autre justification, qui est une sorte de corollaire au dogme entourant la programmation de paires elle-même, est que chaque fois que quelqu'un vous échange, vous obtenez une nouvelle révision de code par une nouvelle paire d'yeux, donc cela ne peut qu'améliorer la qualité du code.
Les deux affirmations semblent raisonnables; Du point de vue de la gestion, il semble que vous obtenez une augmentation à la fois de la stabilité et de la qualité, et en tant que tel, les échanges fréquents sont à peu près la théorie standard dans la plupart des livres Agile / XP que j'ai examinés.
Donc, une fois mis en pratique, que pensent les gens du changement de paire
- Le point de vue d'un programmeur?
- Le point de vue d'un manager?
Et
- Qu'est-ce qui devrait déterminer quand quelqu'un change de / vers une paire?
Réponses:
La programmation par paire est difficile.
C'est difficile car cela fonctionne mieux lorsque les 2 personnes impliquées sont proches du niveau de compétence et cela peut être difficile dans certains environnements de travail. Cela peut être plus difficile lorsque vous échangez, car vous devez trouver quelqu'un d'autre avec le niveau de compétence approprié, puis le mettre au courant du problème actuel. L'avantage est que plus de personnes sont exposées à un morceau de code donné qui a été couplé. Cela devrait conduire à moins de fois où le code ne peut pas être corrigé car personne n'en sait suffisamment. Il devrait également propager la propriété du groupe et la possibilité pour quiconque de reprendre n'importe quel travail.
J'ai constaté que même dans les environnements où l'appariement est effectué, l'échange de paires ne vaut pas le coût. Cependant, cela peut être dû au fait que nos tâches ne prennent jamais plus de ~ 1,5 jour. Nous avons constaté que la répartition des tâches ne représente pas plus de 1,5 jour de travail. L'échange de paires peut avoir plus de sens dans le contexte de tâches plus longues.
la source
Je suis à la fois programmeur et manager. Voici mon point de vue:
L'échange régulier est super. Je préfère échanger 2 à 4 fois par jour, ce qui est à peu près aussi rapide que je pense que vous pouvez y aller. Pour nous, cela arrive à des points de rupture naturels: généralement le déjeuner et le milieu de l'après-midi. Changer tous les jours ou deux est probablement bien, mais je m'inquiéterais d'aller beaucoup plus longtemps que cela. (J'ai entendu parler d'un échange de lieu aussi rarement que toutes les six semaines, ce qui, je pense, est fou; après tant de temps ensemble, vous seriez prêt à poignarder un saint.)
En tant que programmeur, j'adore ça parce que j'obtiens de nouvelles perspectives, que je peux découvrir d'autres domaines du code et que je peux m'en tenir à ou passer à quelque chose comme je préfère. Je suis récemment passé du codage solo au jumelage, et je suis ravi: j'apprends plus, je m'amuse plus et j'en fais plus.
En tant que manager, je pense que c'est génial car cela résout beaucoup de problèmes de facteurs de camions et de goulots d'étranglement. Par exemple, ce week-end, je prends un long week-end pour le mariage d'un ami, et je ne suis pas du tout inquiet: tout ce sur quoi j'ai travaillé a également été travaillé par d'autres personnes. Je pense également que cela aide vraiment les membres de l'équipe à apprécier les forces et les faiblesses des autres et à encourager la propriété collective du code.
Quant à savoir qui reste dans le travail en cours, j'ai l'impression que c'est principalement aux personnes impliquées. Parfois, vous voulez voir quelque chose à travers, et parfois vous êtes prêt pour un changement. Nous échangeons aussi parfois pour apporter de l'expertise, ou alors quelqu'un peut apprendre quelque chose qui l'intéresse. Nous essayons de garder nos unités de travail assez petites (0,5-2,0 paires-jours), donc ce n'est pas un gros problème, mais l'échange va .
la source
Okie, voici la réponse d'un programmeur agile / xp pragmatique autoproclamé. Je programme des paires depuis plus de deux ans maintenant. Si la programmation des paires est bonne, permuter les paires fréquemment (idéalement toutes les deux heures, sinon toutes les demi-journées). Dans notre bureau, nous nous efforçons d'échanger des paires tous les jours (généralement) ou tous les deux jours (dans le pire des cas). Faire cela en soi pourrait nous donner beaucoup de confiance dans la qualité du code que nous commettons et des apprentissages ou des enseignements que nous avons à chaque rotation de paire (nous savons que la révision du code est bonne, plus elle est meilleure et plus tôt est agréable). C'est ce que permet la «programmation de paires, y compris la pratique de l'échange de paires» ).
Pourquoi ne change-t-on pas de paires toutes les deux / quatre heures? Eh bien, en fait, j'ai fait partie d'équipes qui pratiquent cela aussi. C'est certainement beaucoup plus frais et plus productif. Mais voici l'affaire, l'intervalle de temps de permutation de paires ne devrait pas être une règle, cela devrait se faire tout seul; c'est seulement alors que le gestionnaire ou l'entreprise peut voir ses avantages.
J'en ai été témoin et expérimenté. Je suis maintenant son évangéliste. Ce n'est pas une théorie. Plutôt son tout à fait pragmatique :) Bonne paire de ping-pong et paires d'échange.
la source