J'ai travaillé dans quelques magasins où la direction a transmis l'idée de la programmation en binôme à moi ou à un autre gestionnaire / développeur, et je ne peux pas du tout m'y mettre. Du point de vue du développeur, je ne peux pas trouver une raison pour laquelle le passage à ce style de codage serait bénéfique, ni en tant que gestionnaire d'une petite équipe, je n'ai vu aucun avantage.

Je comprends que cela aide sur les erreurs de syntaxe de base et peut être utile si vous avez besoin de hacher quelque chose, mais les gestionnaires qui sont hors de la boucle de programmation semblent continuer à le voir comme un moyen d'empêcher leurs concepteurs d'aller sur Facebook ou Reddit plutôt que un outil de conception.

En tant que personne proche du plancher de développement qui ne peut apparemment pas tout à fait comprendre à partir d'un livre jeté à ma façon ou d'une page wiki sur le sujet ... à partir d'un poste de gestion de haut niveau, quels sont les avantages de la programmation par paire lorsqu'il s'agit de Scrum ou Agile environnements?

Cela dépend en partie de la façon dont vous effectuez la programmation par paires. Dans certains cas, le pilote de la paire écrit du code, tandis que le deuxième membre de la paire observe et discute des détails de conception et de mise en œuvre du système. Un autre exemple de programmation par paires implique que les deux personnes écrivent du code simultanément - une personne écrit la fonctionnalité implémentée et l'autre développe et écrit activement du code de test au niveau de l'unité et de l'intégration, discutant à nouveau des détails de conception et d'implémentation du système.

Quel que soit le type de programmation par paire, il sert efficacement de révision continue du code . Vous avez les yeux de deux personnes sur le code, surveillant les erreurs avant qu'elles ne s'échappent dans un environnement de test de système / d'acceptation ultérieur ou sur le terrain. Vous avez également deux personnes qui comprennent très bien une partie particulière du système, pour servir de redondance afin de minimiser votre facteur de bus . La détection précoce des défauts et la diffusion des connaissances du système autour de l'équipe réduisent le coût de construction d'un système.

La diffusion des connaissances ne se limite pas seulement aux connaissances techniques de l'équipe. Selon qui est la paire, cela peut permettre à un membre plus ancien de l'entreprise de circuler vers un nouveau membre sur d'autres choses qui transcendent le projet - le style de codage, la culture de l'entreprise, les attentes, etc. Il peut également permettre à quelqu'un qui est plus familier avec une technologie ou un outil de partager ses connaissances sur cette technologie ou cet outil dans un environnement réel.

Comme vous l'avez mentionné, cela aide également à garder les développeurs concentrés et dynamiques . En plus du flux, de nombreuses personnes sont moins susceptibles d'interrompre plusieurs personnes travaillant sur quelque chose qu'une seule personne travaillant sur quelque chose. Si vous passez devant le bureau de quelqu'un et qu'il travaille seul, mais que vous devez lui parler, vous pourriez frapper et lui parler. Cela est moins probable si vous voyez deux personnes ou plus travailler en collaboration ou avoir une discussion - vous ne les interromprez pas. Les interruptions coûtent du temps et passer plus de temps signifie des coûts plus élevés. Il est dans le meilleur intérêt de l'entreprise de maximiser la productivité des employés.

Cependant, certains défis doivent être surmontés pour rendre la programmation par paires viable. Considérez des choses comme les affrontements de personnalité ou le choix des paires pour distribuer correctement les connaissances. Il faut également savoir exactement quand faire pivoter les paires. La programmation par paires effectuée au hasard ne sera probablement pas efficace comme prévu. Selon la composition de votre équipe, il peut ne pas être efficace du tout de jumeler des personnes.

1. Moins d'erreurs dans le code final (efficacité)
   Ne remplaçant pas complètement les revues de code mais très efficace pour bien faire les choses dès le début. Il existe des recherches qui vont dans ce sens.

2. Achèvement plus rapide (efficacité)
   Plusieurs recherches le montrent. Lorsqu'il s'agit de fonctionnalités complexes, 2 têtes sont tout simplement plus efficaces. Une expérience en jumelage est indispensable pour cela.

(Remarque: Ceci est votre argument de vente pour le gestionnaire: Financièrement une décision saine, car vous obtenez un nombre de bogues plus efficace et plus efficace et une exécution plus rapide)

1. Enseignement aux juniors
   Vous pouvez ajouter un junior directement à un programmeur plus expérimenté. Si vous avez un groupe de débutants absolus, il est facile de rester et de les laisser, par paires, comprendre les bases. Restez et donnez des conseils. Le concept est apparemment très ancien et découle de l'artisanat.

Réponse rapide: la plupart des avantages et des coûts sont publiés sur Wikipedia cependant, regardons-le sous un angle un peu différent.

Je voudrais mentionner des cas spécifiques d'avantages de programmation par paires qui s'appliquent à un environnement de développement agile / scrum, extraits d'un article de blog :

Le succès ou l'échec d'un logiciel dépend de sa qualité et la programmation par paires améliore directement la qualité de nombreuses manières. Lorsque deux développeurs travaillent ensemble, la qualité du modèle de conception s'améliore à mesure que la paire développe un code court, simple et facile à entretenir avec moins de bogues. Les bogues sont un problème de qualité majeur dans le développement de logiciels; avec deux paires d'yeux écrivant le code, plus d'erreurs sont détectées, réduisant ainsi le coût du développement. Les bogues trouvés tard dans le processus de développement sont souvent coûteux à corriger. La détection précoce des défauts logiciels empêche et aide à dissuader les problèmes difficiles sur la route. La complexité survient souvent dans la programmation, et deux esprits travaillant ensemble pour résoudre un problème peuvent voir plus d'options et tirer des conclusions plus rapidement qu'une seule.

En résumé:

• Favorise la communication d'équipe
• Favorise un transfert efficace des connaissances sur les applications
• Favorise la responsabilisation sur l'approche de conception
• Résultat: un code amélioré et facile à entretenir
• Aide à éliminer le code bogué à ses débuts
• Augmente la productivité de l'équipe, car les membres de l'équipe auront toute leur attention lors du codage
• Améliore les compétences de communication et de collaboration des membres de l'équipe
• Renforce la camaraderie au travail
• Rend le travail plus amusant

La programmation par paires présente quelques avantages:

• Les deux programmeurs peuvent collaborer ensemble sur la conception, produisant potentiellement une meilleure architecture / code - deux paires d'yeux peuvent repérer les erreurs
• Les connaissances institutionnelles sont mieux préservées - si un programmeur quitte ou n'est pas disponible, l'autre devrait pouvoir continuer le travail sans beaucoup de perte de productivité
• C'est une façon de former rapidement de nouveaux développeurs - associez-les à un membre expérimenté de l'équipe de développement et ils pourront découvrir la base de code du point de vue d'un vétéran de l'équipe
• Meilleure discipline - les programmeurs jumelés sont probablement productifs sur une plus longue période de temps, car l'un ou l'autre peut prendre le relais pour des rafales d'activité. Les tâches potentiellement fastidieuses, comme les tests unitaires, peuvent être ignorées moins fréquemment que pour les développeurs solo.

Wikipedia a également un bon résumé des coûts et des avantages de l' entrée wiki .