Raisons de la programmation en binôme

13

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?

Jeff Langemeier
la source
2
Je pense que c'est utile dans des situations très spécifiques. Mais en tant que modèle de développement général, c'est un peu inutile.
Ryan Kinal
4
Cela peut dépendre du logiciel, ce qui pourrait colorer votre vue. Si vous avez beaucoup de petits widgets et travaillez chaque jour sur différents petits logiciels personnalisés, ce n'est probablement pas utile. Cela devient extrêmement utile lorsque vous traitez avec un système de grande entreprise où les développeurs doivent tenir compte de la cascade à travers le système créée par les fonctionnalités qu'ils implémentent. L'écriture d'une classe qui affecte les données utilisées dans plus de 30 endroits distincts peut généralement être mieux raisonnée par 2 personnes qui auront des processus mentaux différents pour cela. C'est comme une méthode de monte carlo pour la recherche de pré-défauts.
Jimmy Hoffa
@JimmyHoffa Donc, le principal processus de réflexion est que si nous trouvons les bogues avant même qu'ils ne parviennent aux tests d'acceptation, nous pouvons réduire considérablement le temps perdu sur les révisions / tests de code sur la ligne?
Jeff Langemeier
3
@JeffLangemeier C'est en fait plus que cela; Si vous voyez les défauts dans la conception de la section A1 du sous-système A avant même que A1 ne soit écrit à cause du discours naturel qui se produit entre deux développeurs au cours de la mise en œuvre du sous-système A, vous ne faites pas seulement gagner du temps à consacrer à la correction de la section A1, et les sections A5 et A7 qui dépendent de A1 (ou trouver des bogues dans ces sections dépendantes en raison de la cascade de la correction de A1), vous gagnez du temps en n'écrivant pas complètement cette mauvaise section. Cela réduit le temps de test oui, mais cela réduit encore le temps de développement de cette façon.
Jimmy Hoffa
@MartinWickman Ce n'est pas un doublon. Dans votre lien, ils recherchaient vraiment des inconvénients, même si le titre demandait des avantages et des inconvénients. En outre, une réponse plus approfondie des pros a été donnée dans celui-ci; au point qu'il est avantageux pour la communauté d'avoir celle-ci même si elle est proche de l'autre.
Jeff Langemeier

Réponses:

25

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.

Thomas Owens
la source
+1 pour la bonne réponse. Je n'aime toujours pas beaucoup l'idée, mais vous présentez bien ses avantages.
J'aime la coupe de votre foc monsieur, cette explication fait que cela semble viable.
Jeff Langemeier
9
Je préfère un modèle hybride où les appariements sont plus ad hoc selon les besoins actuels. De plus, il y a des moments où travailler seul est plus efficace et d'autres quand travailler avec un partenaire est meilleur. Être forcé en paires permanentes me semble arbitraire et inflexible.
jfrankcarr
Très bonne réponse. Je suis également programmeur dans une équipe agile et nous faisons beaucoup de jumelage. Au début, nous étions également sceptiques, nous pensions que travailler seul était la meilleure solution. Ensuite, à un moment donné de l'évolution de l'équipe, nous avons imposé la programmation par paires. AUCUN code de production n'a été validé si aucune paire n'a été programmée. C'était une application artificielle du concept d'appariement, mais cela a beaucoup aidé l'équipe. Enfin, après que nous nous soyons tous habitués à la technique et que nous nous sommes mutuellement changés, nous avons fait équipe de manière ponctuelle et surtout lorsque la mise en œuvre est plus complexe ou sujette aux erreurs.
Patkos Csaba
@jfrankcarr, personne n'a même suggéré de paires permanentes; Je ne sais pas d'où vous est venue cette idée. (Notez que cette réponse mentionnait spécifiquement «quand faire pivoter les paires».) Notre équipe a trouvé que c'était vraiment une mauvaise idée de garder les mêmes deux personnes en train de se coupler pendant plus d'un jour ou deux; vous commencez à entrer dans une ornière. Certaines équipes tournent toutes les heures et demie (lien PDF).
Joe White
3
  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.
Sebs
la source
3

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
Yusubov
la source
When two developers work together design pattern quality improves-> cette phrase n'a aucun sens. Du moins pas plus de sens que When two bakers work together wheat quality improvesou When two race drivers work together asphalt quality improves.
phresnel
C'est une citation du blog que vous pouvez consulter. Cependant, mon intention était de mettre davantage l'accent sur la conception technique et la qualité du code, avec un certain type de responsabilité en place, car chaque développeur s'efforce d'être fier du code créé.
Yusubov
2

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 .

JW8
la source