Échange de paires: quels sont les avantages et les inconvénients?

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?

Qu'est-ce qui devrait déterminer quand quelqu'un change de / vers une paire?

agile pair-programming

Est-ce la même chose que "Programmation par paires?"

— Robert Harvey

@Robert Harvey - Eh bien, c'est un aspect de la programmation par paires. Une fois qu'une équipe décide de programmer deux par deux (pour une partie de sa journée de travail), elle doit alors décider comment organiser les programmeurs en paires, c'est-à-dire quand un programmeur doit quitter une paire (un autre doit se joindre en même temps) ). C'est "Pair Swapping".

+1 pour la grande question. Malheureusement, je pense qu'il est assez difficile de trouver un magasin qui effectue régulièrement l'appairage, et encore moins d'avoir des données sur l'échange de paires. J'espère que je me trompe et que vous obtenez de bonnes réponses, je suis très intéressé à en entendre.

— Jesse McCulloch

Personnellement, je trouverais l'échange de paires très distrayant. Essayer de traiter avec autant de personnalités et de niveaux de compétence différents dans des milieux aussi proches produirait trop de dissonance cognitive.

— Robert Harvey

@Jesse McCulloch - Je travaille dans un endroit qui ne fait que jumeler des programmes et des échanges à peu près comme les livres disent qu'une équipe devrait le faire. J'ai également travaillé dans un environnement solo pur et j'ai donc une assez bonne perspective sur le contraste. Cependant, j'aimerais entendre les opinions des autres car je voudrais voir si elles correspondent aux miennes sans trop les influencer.

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.

— Dietbuddha
source

Personnellement, j'aime m'associer avec des gens de tous niveaux. Parfois j'apprends, parfois j'enseigne, et parfois nous faisons simplement avancer les choses. Mais l'apprentissage et l'enseignement renforcent la capacité de l'équipe à long terme, ce qui, je pense, est tout aussi important que de cocher les fonctionnalités.

— William Pietri

vous pouvez le penser, mais le chef de projet qui voit son délai s'évaporer à mesure que votre expertise s'habitue à former les gens à son heure plutôt que de produire du code aussi rapidement que vous ne pouvez pas être d'accord. Et c'est ainsi que la plupart des projets fonctionnent, il n'y a tout simplement pas de temps pour former les gens à avoir les compétences nécessaires pour faire le travail, de sorte que les juniors se balancent, bon seulement pour prendre le blâme pour les dépassements de budget.

— jwenting

@William Pietri: D'après mon expérience, le jumelage n'est pas un bon format pour l'enseignement. Je n'ai aucun problème à prendre quelqu'un et à le guider dans le code pour lui expliquer ce qui se passe. Cependant, ce n'est pas une programmation par paires.

— dietbuddha

@jwenting: Si vous dites que la programmation par paires ne fonctionnera pas bien dans les magasins qui se concentrent sur les délais de conneries sur la qualité et la durabilité, je ne contesterais pas. Mon conseil: travaillez dans un endroit qui n'est pas fou.

— William Pietri

@dietbuddha: Fonctionne pour moi! Le moyen le plus rapide pour moi d'apprendre un nouveau langage, un nouveau framework ou une nouvelle bibliothèque est de faire équipe avec des gens qui le connaissent bien. Et je ne connais pas de meilleur moyen de mettre un noob à niveau que le jumelage. Par exemple, cette version de l'expérience: slesinsky.org/brian/code/starting_xp.html

— William Pietri

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 .

— William Pietri
source

Pour moi, je dois dire que l'échange n'est bon que lorsque a) je n'aime pas coder avec le gars avec qui je code, b) je n'aime pas l'histoire sur laquelle je travaille (comme réparer une corde ancien bogue de mémoire). Sinon, je veux rester du début à la fin. Personnellement, je pense que l'échange de paires réduit la qualité du code car un bon code doit avoir une seule vision claire, plus il y a de gens qui travaillent sur une seule partie, plus cette vision devient encombrée. Quant au partage des connaissances, je dirais que la plupart des gens ont une idée de ce qui se passe, mais personne ne comprend vraiment vraiment quoi que ce soit.

@B Tyler - Je pense qu'une base de code est un travail intellectuel conjoint, vous devez donc avoir une vision claire qui est aussi une vision commune. C'est en partie pourquoi je pense qu'il est important d'échanger: il faut beaucoup d'interaction et de discussion pour développer une solide approche partagée.

— William Pietri

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.

— karthiks
source

Hélas, je suis maintenant totalement converti à l'idée que la programmation par paires est en général une mauvaise idée; l'échange de paires fréquent dans la programmation de paires ne fait qu'empirer les choses. J'ai entendu toute la théorie et je l'ai beaucoup essayée dans la pratique et je pense simplement que c'est incroyablement inefficace, beaucoup plus ennuyeux et frustrant que la programmation solo et entraîne un code de qualité inférieure.