Est-ce que la programmation en binôme convient à tous les développeurs ?
Analyse d'un développeur senior
Le 2014-08-30 01:44:42, 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 ?
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 ?
-
Luckyluke34Membre émériteA 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.le 01/09/2014 à 13:01 -
hmmmm
Sujet:
Est-ce que la programmation en binôme convient à tous les développeurs ?
Il semblerait qu’il n’y ait pas une solution...[blablalba]...
"Vaut-il mieux programmer les codes complexe le matin ou l'apres-midi?"le 30/08/2014 à 10:21 -
Haseo86Membre éclairé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.le 31/08/2014 à 21:14 -
el_slapperExpert éminent séniorles "je crois, je pense, mon experience dit que, j'ai probablement raison", c'est bien gentil, mais une vraie étude solide, c'est quand même plus fiable.
Ca tombe bien, Alistair Cockburn en avait fait une il y a quelques années.
Conclusions :
(1)Là ou un type seul consomme 1000 heures, un binôme va consommer 1150 heures(soit 575 heures pour chaque membre du binôme) - en réalisation seule.
(2)Le binôme fait en moyenne 15% moins de bugs. La correction de bugs et leur impact support coutant plus cher que la réalisation initiale, ce simple fait suffit à rendre le pair programming rentable.
(3)Il y a tout plein de qualités additionnelles plus subjectives : satisfaction, qualité de l'architecture, revue continue, transfert de connaissance induit.
(4)J'aimerais bien avoir l'occasion d'essayer.le 16/10/2014 à 15:12 -
Haseo86Membre éclairé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 ^^le 30/08/2014 à 10:09 -
moldaviInactifBonjour.
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 ?le 31/08/2014 à 3:21 -
Logan MauzaizeRédacteur/ModérateurLe 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 ?le 05/09/2014 à 12:53 -
Luckyluke34Membre éméritePour avoir pratiqué les deux, je trouve au contraire que le pair programming est plus productif.
Avec une code review a posteriori, soit on a tendance à beaucoup moins retoucher ce code déjà existant, soit au contraire on "refait le match" ce qui est une perte de temps par rapport à un mode où les 2 développeurs auraient avancé ensemble en temps réel. On est obligé d'appliquer plus de techniques de refactoring puisque le code pondu entretemps par le junior est quelque part du code legacy, et ça prend du temps. D'un autre côté si le senior se rend vraiment "disponible pour répondre aux questions", ça revient un peu à du pair programming sauf que le senior est interrompu fréquemment, et on sait ce que vaut le task switching en termes de productivité...
Toujours par rapport à mon expérience, plus la différence de niveau entre les deux devs est faible, moins la code review finale va être bien acceptée. Avec le pair programming, on fait tourner souvent le clavier et on discute au fil de l'eau, ce qui donne en général une solution plus collégiale et validée par les 2.le 15/10/2014 à 17:21 -
Logan MauzaizeRédacteur/ModérateurRelis ce qui a été dit précédemment ;-)
Non, la théorie dit qu'il faut permuter régulièrement. Ca évite justement la déconnexion.
Il ne faut pas oublier qu'on a tous à apprendre des autres. Un projet c'est énormément de choses : le dev dans éventuellement plusieurs langages et paradigmes, le tooling (ex: IDE), les tests, la traçabilité, build, déploiement, etc.
Personnellement, je le vois pas du tout comme ça. Je trouve ça très gratifiant de partager son savoir et d'inculquer les bonnes pratiques. Ou alors je n'accepterai pas que le plus expérimenté vienne ensuite râlé sur les mauvaises pratiques de ces collègues.
Ceci dit je suis très pédant
Le soucis c'est qu'on ne pense pas à tout. Et des fois c'est dans les petits détails qu'on a beaucoup à apprendre. Ensuite on peut également rectifier la méthode de travail, la façon de refactorer, utiliser les outils. Tout ce qui se perd avec le côté "à froid" de la revue de code, cette dernière ne s'intéresse qu'au résultat et non pas à tout ce qui y a conduit.
Voir mes remarques précédentes sur le côté "à froid" de la revue de code.le 16/10/2014 à 12:11 -
MarieKisSlaJoueMembre expertQuelqu'un as-t-il déjà essayer de travailler avec un IDE en ligne collaboratif ? Je me demande bien ce que ça peux donner en pair programming justement. de pouvoir travailler sur le même code en live sans passer par des push et pullle 05/09/2014 à 16:52