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

Le , par Arsene Newman, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Haseo86 Haseo86 - Membre éclairé https://www.developpez.com
le 30/08/2014 à 10:09
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 ^^
Avatar de VBrice VBrice - Membre habitué https://www.developpez.com
le 30/08/2014 à 10:21
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?"
Avatar de babs-dieng babs-dieng - Candidat au Club https://www.developpez.com
le 30/08/2014 à 23:36
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.
Avatar de Haseo86 Haseo86 - Membre éclairé https://www.developpez.com
le 31/08/2014 à 0:13
Citation Envoyé par babs-dieng  Voir le message
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.
Avatar de moldavi moldavi - Membre émérite https://www.developpez.com
le 31/08/2014 à 3:21
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 ?
Avatar de Orwel Orwel - Membre du Club https://www.developpez.com
le 31/08/2014 à 10:08
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?
Avatar de qadassi qadassi - Membre à l'essai https://www.developpez.com
le 31/08/2014 à 20:35
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.
Avatar de Haseo86 Haseo86 - Membre éclairé https://www.developpez.com
le 31/08/2014 à 21:14
Citation Envoyé par qadassi  Voir le message
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.
Avatar de michaelvd michaelvd - Membre à l'essai https://www.developpez.com
le 01/09/2014 à 10:53
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!
Avatar de Saverok Saverok - Expert éminent https://www.developpez.com
le 01/09/2014 à 10:56
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)
Offres d'emploi IT
Ingénieur Etudes et Développement PHP (H/F)
SMILE - Rhône Alpes - Grenoble (38000)
Développeur Java H/F
SMILE - Rhône Alpes - Lyon (69000)
Ingénieur études et développement PHP (H/F)
SMILE - Rhône Alpes - Lyon (69000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil