Discussion :

[Arsene Newman]

Est-ce que la programmation en binôme convient à tous les développeurs ?
analyse d’un développeur senior

David Green est un développeur senior avec plus de 20 ans d’expérience, il est entre autres cofondateur de la London Software Craftsmanship Community, aujourd’hui il revient sur les attraits de la programmation en binôme et surtout sur une question fondamentale : Est-ce que la programmation en binôme est adéquate à tous les développeurs ?

Pour Green, « la programmation en binôme est un formidable moyen de partage de connaissance, cela permet aussi de normaliser le savoir d’une équipe, améliorer son niveau moyen et faire face à la dissipation et la dilution des connaissances.

Cela induit aussi un autre élément intéressant : la discipline, en effet il est très difficile pour un développeur de faire comme bon lui semble, alors que son coéquipier agit littéralement comme sa conscience.

Mais le principal problème avec la programmation en binôme demeure sans conteste un problème de communication : la coordination, en effet « les tâches d’une équipe de développeurs sont difficiles. Idéalement, chaque développeur sait tout ce qui se passe au sein de son équipe et de son programme, mais ce n’est clairement pas le cas. Au lieu de cela, l’équipe peut tracer des frontières pour rendre plus facile la perception d’un programme dans son ensemble, sans avoir à connaitre l’ensemble au même niveau de détail ». Ces frontières tendent à se dissiper au fur et à mesure des rotations entre les deux développeurs, jusqu’à ce que l’ensemble du programme n’apparaisse plus comme une boite noire.

« Toutefois, il faut avouer que toutes les personnes ne sont pas faites pour pareille chose, une bonne séance de travail s’apparente très vite à une interaction sociale alors que l’équipe peut sembler très bruyante ». De plus, s’habituer à travailler en duo est l’une des choses les plus difficiles : « on passe toute la journée à discuter et à argumenter puis on se pose la question : c’est quand qu’on commence à coder ? ».

D’un autre côté, « la programmation tend à attirer les personnes les moins sociables » et les développeurs s’habituent à dialoguer avec la machine sur la base d’une logique de 0 et de 1, ce qui explique la tournure que peuvent prendre certaines discussions entre coéquipiers et l’échec de la programmation en binôme dans certains cas.

En effet, certains développeurs sont introvertis et d’autres sont extraverties, cette différence de traits de caractère peut jouer un rôle crucial dans la réussite ou l’échec d’un duo, sans oublier que « les bénéfices sont intangibles, alors les plus introvertis des développeurs auront tendance à trouver cette méthode de travail moins amusante et efficace que de travailler en solo».

Alors qu’elle serait la solution idéale ? Délaisser la programmation en binôme ou bien exiger son application coute que coute. Il semblerait qu’il n’y ait pas une solution, mais plusieurs, cela peut passer par forcer les développeurs à l’adopter, exiger que toute personne membre de l’équipe soit adepte ou bien songer à la solution du juste milieu, en permettant à chacun de travailler selon ces préférences : en solo ou en duo, mais cela aura pour conséquence de gérer le code des uns et des autres, ceux développer en solo et ceux bénéficiant des avantages et des inconvénients de la programmation en binôme.

Source : Is Pair Programming For Everybody?

Et vous ?
Qu’en pensez-vous ?

[Haseo86]

Ce genre de gars n'a rien d'autre à faire que pondre des pseudos-réflexions sur des évidences ?

Si vous voulez, je peux vous épargner la rédaction d'un certain nombre de news futures : "Est-ce que telle méthode de travail/tel mode de vie/telle approche de la programmation/telle je-ne-sais-quoi convient à tous les développeurs/salariés/humains/vertébrés/poissons rouges ? : NON ! Prenez deux secondes et votre bon sens vous le dira."

De rien ^^

[Invité]

hmmmm

Sujet:

Est-ce que la programmation en binôme convient à tous les développeurs ?

Conclusion:

Il semblerait qu’il n’y ait pas une solution...[blablalba]...

Une autre idée de sujet dans le même style:
"Vaut-il mieux programmer les codes complexe le matin ou l'apres-midi?"

[babs-dieng]

Je pense que le problème mérite d’être poser.Est ce plus efficace de l'appliqué ou non ? parce que perso en tant débutant (2 ans dans le monde de la programmation) j'arrive toujours pas à travailler en binôme.

[Haseo86]

Je pense que le problème mérite d’être poser.Est ce plus efficace de l'appliqué ou non ? parce que perso en tant débutant (2 ans dans le monde de la programmation) j'arrive toujours pas à travailler en binôme.

Il faut faire la distinction entre deux choses :
- "Dans une équipe, est-ce que ça peut valoir le coût de réfléchir à cette méthode de travail, et peut-elle apporter quelque chose ?" Comme tu le dis, la question mérite certainement d'être posée, la méthode testée et des conclusions tirées, pour l'équipe.
- "Est-ce que cette méthode peut-être universellement appliquée et bénéfique pour tous ?". Bien sûr que non, il est absolument évident que n'importe quelle approche ne peut en aucun cas être universelle et s'appliquer à tous de manière uniforme en produisant les mêmes résultats, et il semble vraiment peu pertinent et intelligent de se poser ce genre de question.

Donc le problème ici c'est qu'on présente la seconde question, ce qui n'a pas le moindre intérêt. Pour ma part je suis affligé que des gens se posent encore des questions de cette façon, et je suis déçu que le rédacteur de cette news la présente comme "fondamentale". D'ailleurs le résumé donné ici est assez succin, en parcourant l'article original je ne suis pas sûr que ce condensé soit toujours justement traduit, mais surtout il manque l'essentiel de l'original : d'une part l'appel aux retours d'expériences, d'autre part l'auteur indiquant que la réponse à la question est évidemment "non". Du coup je mets un bémol sur mon premier commentaire : ce n'est pas l'auteur original qui est stupide de poser ce genre de questions, mais le résumé qui est fait ici de son article qui donne cette fausse impression, en passant à côté de l'essentiel de l'article.

Maintenant si je peux participer au débat en donnant ma propre expérience : dans mon équipe on a plutôt tendance à coder seul, sauf en cas de blocage, dans ce cas on n'hésite pas à passer la journée à deux devant une machine, parfois juste à discuter, et un seul code après coup. Mais la réflexion et la conception avant le codage se font majoritairement en équipe, avec de nombreuses réunions plus ou moins formelle pour confronter les points de vues, et qui se terminent souvent pas un "duel" entre les deux qui maîtrisent le mieux le problème en cours (je mets duel entre guillemets parce qu'il ne s'agit généralement pas de savoir qui a raison, mais d'arriver à une compréhension commune du problème et de la solution)

Par contre pour ce qui est de coder à proprement parler, à deux, personnellement je déteste ça: avoir quelqu'un qui scrute tout ce que je fais à l'écran, ou regarder quelqu'un d'autre coder d'une façon différente de ce que j'aurai fait. Rien que le fait d'avoir un environnement qui n'est pas le sien peut être dérangeant. Coder à deux fonctionnait très bien à l'Université, parce qu'aucun des deux membres du binôme n'est "chez l'autre" sur la machine, en dehors de ce contexte précis je n'y crois pas.

[moldavi]

Bonjour.

Je ne connais rien du développement en binôme, mais je vais donner mon avis en prenant un cas extrême.

Prenons deux développeurs expérimentés, comme Linus Torvalds et Linus Torvalds...

Seront-ils plus performant en travaillant en solo ou en binôme. Je pense qu'en binôme, ils perdront leur temp,s et qu'en solo ça ira presque deux fois plus vite.

La méthode binôme, cela ressemble à une méthode pour compenser la médiocrité des développeurs, ou pour satisfaire des entreprises qui veulent des résultats en 2 jours alors que ce n'est pas possible, même avec les meilleurs développeurs du monde.

En ce qui concerne le formidable moyen de partage de connaissance (selon l'auteur), cela existe sans faire du binôme. Il suffit de parler avec un développeur pour apprendre des choses extraordinaires...

Bref cas de figure :

Deux développeurs débutants en binôme : problème pour le futur du projet (sans remettre en cause qu'un débutant deviendra certainement Pro...).
Un développeur compétent et un développeur débutant ; c'est certain, le développeur débutant va apprendre des choses (sans remettre en cause qu'un débutant a aussi des connaissances à partager).
Deux développeurs compétents : cf Linus Torvalds.
Autre cas : à définir...

Bref est-ce que la méthode binôme envisage toutes ces situations ?

[Orwel]

Il y a un problème avec l'URL de la source.

"Vaut-il mieux programmer les codes complexe le matin ou l'apres-midi?"

Le matin on n'est pas correctement réveillé/éveillé et l'après midi c'est la digestion. Ni l'un ni l'autre mon capitaine.


J'ai l'impression que l'auteur se limite à la sociabilité du sujet. Pourtant il pointe la plus grosse qualité d'un duo :

People who had no problem explaining their thought process and no ego to get bruised when you point out the fatal flaw in their idea.

C'est la différence entre "Tu t'es trompé!" et "J'ai un doute" pour annoncer une potentielle erreur.

Je ne suis pas d'accord avec l'article, un asocial peut aimer le développement en binôme, mais avec un autre asocial. Puis deux introverties seront plus productifs que deux extraverties, surtout le lundi

Je rejoins l'avis de Haseo86. En cas de difficulté, deux têtes values plus qu'une, mais pour les trucs anecdotiques je préféres être en solo

Par contre, je me demande si la programmation en binôme lors de l'intégration d'un membre à une équipe faciliterait son apprentissage sur les méthodes de l'équipe? Un retour sur cette pratique?

[qadassi]

Certains débats futiles ont le mérite de développer l'argumentation, mais celui là est futile et vide de style.

Le manque de style est qu'il est du genre dialectique (débat pour/contre pour ceux qui ne s'y connaissent pas en littérature) sans nuance supplémentaire capable de mettre en valeur la subtilité de l'auteur.
Quant à sa futilité, la programmation en binôme voire en multinôme existe, et c'est le forking existant dans l'open source! Pour revenir à la remarque sur Linus, loin d'avoir été en solo, c'est l'inventeur de la programmation multinômial! Sauf qu'en entreprise, aucune ne paie des employés pour les envoyer coder sur les même fonctions d'un logiciel (rattraper moi si je me trompe), même pas RedHat.

Quant aux problèmes de communications soulevés, le pire c'est quelles ne sont pas les plus graves, et le plus important dans le forking open-source ou le travail en binôme dans une entreprise serait surtout sur l'objectif des discussions qui peut être, critique, validations, suggestions ou créativité, et comment les réaliser (genre thématique en littérature) et ainsi le débat sera limité à ses 4 issues (qui suivent un modèle analogue au CRUD et au quatre éléments de Platon, donc le modèle n'est pas le sujet du débat) mais il serait plutôt centré sur la manière de les réaliser peut importe la prédisposition introvertion/extraversion ou les problèmes d'égo.

Quelques exemples, et c'est dans cet ordre que ce ferait le débat.
Pour la créativité: ce serait le moment de l'écoute active ou chacun essayerait de s'émerveiller de la solution de l'autre en essayant de montrer qu'il a bien compris ce qu'il avait entendu, sans lui suggérer davantage pour laisser à l'autre la paternité de son idée, ni valider pour ne pas l'interrompre ni le casser pour ne pas le vexer.
Pour la suggestion: ce serait le moment du consensus utopique, l'un propose et l'autre suggère une amélioration, sans critique donc on ne casse pas mais on essaie de construire et d'enrichir l'idée de l'autre sans valider pour toujours repousser le plus loin possible les éventualités, ni proposer sa propre méthode quant l'un à la parole puis de s'échanger les rôles pour proposer son alternative.

Après les suggestions, on passerait à la modélisation ou au codage ou à la livraison, puis de nouveau, le contact serait repris.

Pour la critique: ce serait le moment des tests des scénarios et des tests unitaires, jouer le jeu de rôle attaquant/défenseur mais de manière séparer, le défenseur ne contre attaque pas et l'attaquant se lance à fond sans crainte de se tromper. L'un doit tester les fonctions de l'autres sont les validés avec la plus mauvaise foi ni d'apporter de suggestions avec le plus de retenus ni créer une solution plus efficace dans le plus grand désintérêts, puis d'intervertir les rôles.
Pour la validation: ce serait le moment de récapitulatifs des résultats de tests avec la plus objective et la plus réaliste des démarches sans débats ni suggestions ni propositions, juste de reporter les résultats des tests par le défenseur et l'attaquant individuellement, puis de noter l'écart des résultats et retenir les avis communs, puis de recommencer les tests sur les avis divergents dans la limite du temps et de recourir à un arbitre pour trancher au final.

Ainsi, un bon débat serait de la durer et du nombre de fonctions à évoquer, aux parties communes, aux parties individuelles, ou aux parties partagées à hierarchiser, qui riquerait d'être encore plus compliquer à choisir qu'à réaliser, ceci étant donc l'ouverture de la question " Est-ce que la programmation en binôme convient à tous les développeurs ?".

Bref, ce que j'ai évoqué relève du bon sens de chacun, et n'ai pas sensé être LA BONNE ou encore moins refléter LA REALITE ou pire LA SEULE façon d'aborder le sujet.

Bravo si vous avez lu jusqu'à la fin, et merci d'avance pour les critiques, accords, suggestions ou alternative.

[Haseo86]

Certains débats futiles ont le mérite de développer l'argumentation, mais celui là est futile et vide de style.

Le manque de style est qu'il est du genre dialectique (débat pour/contre pour ceux qui ne s'y connaissent pas en littérature) sans nuance supplémentaire capable de mettre en valeur la subtilité de l'auteur.
Quant à sa futilité, la programmation en binôme voire en multinôme existe, et c'est le forking existant dans l'open source! Pour revenir à la remarque sur Linus, loin d'avoir été en solo, c'est l'inventeur de la programmation multinômial! Sauf qu'en entreprise, aucune ne paie des employés pour les envoyer coder sur les même fonctions d'un logiciel (rattraper moi si je me trompe), même pas RedHat.

Quant aux problèmes de communications soulevés, le pire c'est quelles ne sont pas les plus graves, et le plus important dans le forking open-source ou le travail en binôme dans une entreprise serait surtout sur l'objectif des discussions qui peut être, critique, validations, suggestions ou créativité, et comment les réaliser (genre thématique en littérature) et ainsi le débat sera limité à ses 4 issues (qui suivent un modèle analogue au CRUD et au quatre éléments de Platon, donc le modèle n'est pas le sujet du débat) mais il serait plutôt centré sur la manière de les réaliser peut importe la prédisposition introvertion/extraversion ou les problèmes d'égo.

Quelques exemples, et c'est dans cet ordre que ce ferait le débat.
Pour la créativité: ce serait le moment de l'écoute active ou chacun essayerait de s'émerveiller de la solution de l'autre en essayant de montrer qu'il a bien compris ce qu'il avait entendu, sans lui suggérer davantage pour laisser à l'autre la paternité de son idée, ni valider pour ne pas l'interrompre ni le casser pour ne pas le vexer.
Pour la suggestion: ce serait le moment du consensus utopique, l'un propose et l'autre suggère une amélioration, sans critique donc on ne casse pas mais on essaie de construire et d'enrichir l'idée de l'autre sans valider pour toujours repousser le plus loin possible les éventualités, ni proposer sa propre méthode quant l'un à la parole puis de s'échanger les rôles pour proposer son alternative.

Après les suggestions, on passerait à la modélisation ou au codage ou à la livraison, puis de nouveau, le contact serait repris.

Pour la critique: ce serait le moment des tests des scénarios et des tests unitaires, jouer le jeu de rôle attaquant/défenseur mais de manière séparer, le défenseur ne contre attaque pas et l'attaquant se lance à fond sans crainte de se tromper. L'un doit tester les fonctions de l'autres sont les validés avec la plus mauvaise foi ni d'apporter de suggestions avec le plus de retenus ni créer une solution plus efficace dans le plus grand désintérêts, puis d'intervertir les rôles.
Pour la validation: ce serait le moment de récapitulatifs des résultats de tests avec la plus objective et la plus réaliste des démarches sans débats ni suggestions ni propositions, juste de reporter les résultats des tests par le défenseur et l'attaquant individuellement, puis de noter l'écart des résultats et retenir les avis communs, puis de recommencer les tests sur les avis divergents dans la limite du temps et de recourir à un arbitre pour trancher au final.

Ainsi, un bon débat serait de la durer et du nombre de fonctions à évoquer, aux parties communes, aux parties individuelles, ou aux parties partagées à hierarchiser, qui riquerait d'être encore plus compliquer à choisir qu'à réaliser, ceci étant donc l'ouverture de la question " Est-ce que la programmation en binôme convient à tous les développeurs ?".

Bref, ce que j'ai évoqué relève du bon sens de chacun, et n'ai pas sensé être LA BONNE ou encore moins refléter LA REALITE ou pire LA SEULE façon d'aborder le sujet.

Bravo si vous avez lu jusqu'à la fin, et merci d'avance pour les critiques, accords, suggestions ou alternative.

Pour ma part je suis surpris de te voir critiquer aussi sèchement le style de l'article, et être aussi prompt à étaler ton instruction, dans un texte comportant autant de fautes de français, et des phrases si alambiquées qu'elles demandent plusieurs lectures.

Après je ne crois pas que tenter un découpage généraliste du travail en binôme ne soit ni une bonne approche de la question, ni pertinent. Car de la même façon que chercher à savoir si le travail en binôme peut s'appliquer de manière universelle n'a aucun sens, chercher à en donner un "mode d'emploi" universel ne donnera rien, puisque l'application et les résultats de la méthode sont je pense totalement et profondément liés à chaque binôme.

Je persiste à penser que le seul échange qui peut se faire sur le sujet est un retour d'expérience, sinon c'est un dialogue de sourds ou une énonciation d'évidences.

[michaelvd]

Je pense que mettre un binôme sur une partie précise du programme n'est pas idéale. Par contre un individu qui travaillerai sur la db et ses classes et l'autre sur le modèle peuvent facilement travailler ensemble. Un binôme sain pour ma part ne peut pas interférer dans le code de l'autre. Par contre un binôme peut relire le code de son collègue afin de faire une critique positive, négative, ou des suggestions. Certains managers peu connaisseurs de la réalité de la programmation vont souvent penser que mettre un binôme sur un même code c'est doubler la productivité. C'est le cas uniquement quand c'est du code "administratif" c'est à dire extrêmement répétitif et faible en algorithmique.
Un binôme correct pour moi est un collègue travaillant sur son projet où sa partie d'un projet commun prêt à m'accompagner en cas de difficulté, et à donner une autre vision sur mes techniques et performances.
Bonne semaine à tous!

[Saverok]

D'après mon expérience, en dehors du cursus scolaire, le développement en binôme est une perte de temps (même à la fac, je n'aimais pas ça car j'ai en horreur d'avoir quelqu'un qui scrute mon écran par dessus mon épaule et qui se racle la gorge à chacune de mes fautes de frappes)
Au final, on consomme 2X plus de ressources pour une même fonctionnalité

Tjrs d'après mon expérience, le dev en binôme n'est pas bénéfique plus pour des raisons de personnalité plus que de compétence :
Soit on a 2 fortes têtes et c'est un bordel qui fait chier tout l'open space
Soit on a 2 introvertis et le travail n'avance pas
Soit y en un qui domine l'autre et qui développe pendant que l'autre ne fait rien (la passivité diminuant l'attention)
Je caricature pas mal mais l'idée est là

Je suis totalement pour le travail collaboratif mais mettre 2 développeurs sur une seule machine est à mon sens contre productif

Lors de la conception, on se met d'accord sur les interfaces et on reste en vision macro : chaque développeur est maître de l'implémentation micro
En cas de problème, on discute le plus souvent devant un tableau et on écrit conjointement l'algo en pseudo code : le développeur en charge de la fonctionnalité effectue la réa concrète
Si c'est un problème technique, c'est une intervention ponctuelle très courte mais on est plus dans du cours magistral que du binôme dans ces cas là

Lors de l'intégration d'un nouveau développeur dans une équipe, une présentation commentée de l'architecture de l'application est effectuée mais on ne développe pas
Avec un développeur expérimentée, cette étape peut parfois être zappée car la lecture du code peut suffire et l'expérience permet de déduire
Avec un junior, la présentation est plus longue
Personnellement, j'attribue une demande simple au junior et j'effectue une relecture du code commentée avec lui et je lui explique en détail les points forts et faibles et je le laisse corriger sa copie jusqu'à satisfaction. Puis, dès qu'il a fait ses preuves, j'effectue tout de même une relecture silencieuse de son code pour finir par lui faire confiance.

Pour revenir à l'article
Bien évidement, aucune méthode de travail n'est universelle
Il faut tjrs s'adapter au projet, au client et aux développeurs (compétences et personnalités)

J'aimerai plus avoir qui a eu de bonnes expériences de dev en binôme et pourquoi ? (car les miennes ont tjrs été des échecs)

[Luckyluke34]

A la base du pair programming (ce que l'article ne mentionne absolument pas), il y a le driver (pilote) qui dirige le développement et le navigator (co-pilote) qui le guide, fait des remarques et des suggestions, remet les choses en perspective par rapport au contexte global quand on a fini une sous-tâche...

Les rôles sont bien définis et doivent alterner régulièrement, donc normalement un développeur ne doit pas prendre l'ascendant sur l'autre.

Personnellement, quand le binomage se passe bien, j'ai noté les effets suivants, qui ne se seraient pas produits si chacun était resté dans son coin :

• Montée en compétence plus rapide d'un novice (sur le projet ou en général) qui paire avec un développeur expérimenté
• 2 développeurs ont moins de chances de pondre du code mal nommé ou une implémentation sortie de l'espace, qu'un seul développeur qui sera totalement dans son trip.
• Moins d'erreurs d'étourderie : quand un développeur relâche son attention, l'autre agit come "garde-fou"
• Innovations et gain de qualité nés de la confrontation d'idées
• On ose moins regarder son gmail/facebook/twitter toutes les 10 s : davantage de concentration sur la tâche en cours
• Propagation rapide des règles de codage de l'équipe, + d'appropriation collective du code puisqu'on a décidé les choses ensemble

Bien sûr, le pair programming n'est pas pour tout le monde : ça n'est pas fait pour 2 développeurs qui ne peuvent pas s'encadrer, ni pour ceux qui ne peuvent encadrer personne. A part ça, je recommande au moins d'essayer en mettant son ego de côté. De toute façon, les désaccords qui surviennent pendant les sessions de pair programming seraient apparus de la même manière lors d'une code review ou plus tard quand on tombe sur le code de l'autre : autant les régler en amont, dès l'écriture du code.

[Logan Mauzaize]

Plutôt d'accord avec les deux derniers messages.

Ce qui me chagrine dans toutes les interventions c'est de juger les personnes selon l'expérience ou le niveau d'une seule compétence. J'ai fait très rarement du pair-programming mais beaucoup de coaching. Ce que j'en retiens c'est que tout le monde a quelque chose à apprendre de l'autre et que chacun a ses façons de penser/travailler/aborder un problème/etc.
Il m'arrive parfois de buter sur un problème parce que je le pose pas sous la bonne forme. C'est souvent là que le travail à deux fait le plus grand bien.

En revanche, travailler à deux consomment beaucoup de temps. Chacun doit détailler le contenu de son cerveau à l'oral puis à l'écrit, et à chaque fois l'autre ne produit rien (ou si peu). On passe tout de même beaucoup de temps à pisser du code et/ou à régler des problèmes triviaux.

Ensuite cela tue parfois la créativité/exploration. Quand on est à deux sur un même PC, il y en a qu'un qui pilote le clavier et la souris, l'autre se contente de "réajuster" (il ne peut pas reprendre le contrôle). Travailler à deux réclament déjà plus de temps alors on a moins envie d'en perdre. Alors que tout seul il n'est pas rare que je passe une demi-journée à tester 4 librairies différentes.

[petogo]

Si c'est pour que l'un regarde l'écran de l'autre pour et commente ce qu'il code, je pense qu'il y a une perte de productivité, on peut le constater en cursus scolaire.

Si c'est pour travailler à deux sur le même segment, avec l'un qui teste le code de l'autre et qui fait des revue de code, on y gagne peut être pas en temps mais en qualité.
Le code sera bien mieux présenté si on sait qu'il sera relu.

[Luckyluke34]

Si c'est pour que l'un regarde l'écran de l'autre pour et commente ce qu'il code, je pense qu'il y a une perte de productivité, on peut le constater en cursus scolaire.

Le contexte scolaire est très différent : il n'y a probablement pas de "culture d'équipe" à construire autour d'une base de code. Un bug qui arrive jusqu'en production ne te fera probablement pas perdre des clients ou des dizaines de milliers d'euros. Le code de ton exercice ou projet d'études ne sera vraisemblablement pas réouvert dans un an pour y apporter des modifs cruciales pour le projet. Si tu pars dans une implémentation complètement délirante et défiant toutes les bonnes pratiques existantes, il n'y aura pas de coéquipiers pour s'arracher les cheveux plus tard...

Quand on regarde seulement le temps passé, le pair programming est bien évidemment un gaspillage. Mais il faut aller au-delà de cette réaction instinctive pour le tester et pouvoir décider où on met le curseur entre "productivité pure" et "qualité/diffusion du savoir" (le choix le plus pertinent peut bien sûr varier selon le boulot à faire et les individus).

[bruneltouopi]

J'ai travaillé avec un binôme qui lui était débutant.La difficulté fut de corriger ,de normaliser son code.
Ensuite lorsqu'il fut apte à coder correctement,la difficulté fut de l'empêcher de modifier mon code car il croyait l'optimiser.
Bref le travail en binôme est assez difficile lorsque vous travaillez dans les mêmes modules d'une application ou lorsque l'un n'est pas au niveau de l'autre.
Il n'y a donc pas véritablement échanges de connaissances.

Par contre j'ai 2 autres développeurs qui sont productifs en travaillant en binomes car ils ont mis chacun les limites,les méthodologies et chacun a ses modules.Tout les deux sont compétents et s'entre aident dans les recherches des solutions.
La communication est primordiale.

[Luckyluke34]

Un binôme sain pour ma part ne peut pas interférer dans le code de l'autre.

Bref le travail en binôme est assez difficile lorsque vous travaillez dans les mêmes modules d'une application ou lorsque l'un n'est pas au niveau de l'autre.
[...]
Par contre j'ai 2 autres développeurs qui sont productifs en travaillant en binomes car ils ont mis chacun les limites,les méthodologies et chacun a ses modules.

Dans l'article d'origine, il s'agit bien de binôme au sens de pair programming, donc de travailler à deux en live devant le même écran, et de facto sur le même code.

Il se peut que ça ne se prête pas à tous les environnements. Par exemple, une équipe de deux développeurs chacun hyper spécialisé dans un domaine très pointu n'a pas forcément de raison de binômer.

Mais dans une équipe de 5-6+ où tout le monde collabore étroitement, la notion de code qui appartient à untel parait moins pertinente, voire dangereuse. Ca me semble être du bon sens que chacun sache se débrouiller pour modifier n'importe quelle partie de l'application, ne serait-ce qu'en cas d'absence ou de démission d'un collègue. On parle de plus en plus de développeur full stack aujourd'hui ; ce terme est sans doute employé à tort et à travers, mais une entreprise ne peut se permettre de perdre des pans entiers de sa connaissance et de ses compétences du jour au lendemain si un employé se fait renverser par un bus.

[bruneltouopi]

On parle de plus en plus de développeur full stack aujourd'hui ; ce terme est sans doute employé à tort et à travers, mais une entreprise ne peut se permettre de perdre des pans entiers de sa connaissance et de ses compétences du jour au lendemain si un employé se fait renverser par un bus.

Normal je connais une boite qui a fini par stopper des projets car c'est un développeur qui avait tout codé puis a démissionné.Désormais c'est aussi une garanti pour les entreprises de faire travailler en Binome.Mais j'ai toujours des doutes en fonction de l'ambiance entre les deux.

[dtrosset]

Évidemment que la réponse est non.

Par contre, une autre pratique peut convenir à tous, (si, si, ou alors presque) c'est les revues de code obligatoires avant publication. Mises en place depuis 5 ans, cette pratique est devenue un habitude simple. Je la considère souvent comme un compromis idéal entre rien et la programmation en binôme. Les revues sont très simples parce que facilitées avec l'outil ReviewBoard qui s'intègre très bien au cycle de développement. Et c'est bénéfique sur de nombreux plans, à la fois pour les programmeurs expérimentés qui peuvent contrôler les publications, se motiver mutuellement, et pour les débutants qui apprennent autant de cette manière qu'avec la programmation en binôme. La qualité du code s'en est ressentie, ainsi que sa cohérence. Les compétences des plus jeunes ont explosé.

J'instaurerais les revues de code obligatoires ailleurs si je devais bouger, sans aucune hésitation.

[Logan Mauzaize]

Le code review et le pair programming sont des techniques proches mais différentes par un point important dans ton cas, le travail à chaud et le travail à froid.
Puisqu'on évoque le côté sociologique (voir sociopathique ), j'ai tendance à remarquer que des remarques à chaud sont souvent mieux prises que la même remarque à froid. Parce qu'on a changé de sujet et que cela suffit à nous contrarier.
Ensuite, la relecture de code n'invite pas à la discussion je trouve. On fait quelques échanges superficielles sur le fond et la forme. Et la méthode de travail, l'approche du problème, etc. ne sont pas discutés. On discute que du résultat pas de la démarche, ce qui est un point crucial du pair programming.

Autre point la revue de code est parfois "bâclée" ; que ce soit parce qu'on n'a pas le temps ou que se taper du code à lire/analyzer c'est relativement chiant, on finit par passer à côté de certains éléments. Par exemple, le fait qu'on aurait pu utiliser une librairie plutôt qu'une autre, etc. De plus, on a tendance à se dire : "C'est aussi pas mal comme ça". Et on laisse "comme ça", alors que si la discussion avait été lancé, chacun aurait fait son argumentaire et on aurait finit par choisir la "meilleure" solution (moyennant le pouvoir de persuasion, l'argumentaire, l'expérience, etc.).

Peut-être la solution serait de travailler sur deux postes, un même sujet mais côté-à-côté (voir coude-à-coude). La discussion se fait d'abord sur l'approche du problème et ensuite sur les quelques détails de l'implémentation qui permettent de partager la façon de concevoir un algorithme et la connaissance de la base de code existante. Par exemple, utiliser telle classe utilitaire déjà mise au point pour réaliser telle ou telle tâche. Et faire ensuite le pissage de code chacun de son côté ; quitte à jeter un petit coup d’œil au travail du voisin.
Et enfin faire des "points de synchro" régulièrement (à la fin de chaque méthode ?, toutes les xx minutes, etc.) afin de faire une petite relecture de code, réorienter le travail, etc.
Est-ce une bonne idée d'après vous ?