Pour ou contre la programmation en binôme ? Les acteurs de la filière du développement dispersés entre divers avis :
Moyen de partage de connaissances ? gaspillage de ressource humaine ?
Le 2022-02-22 11:03:59, par Patrick Ruiz, Chroniqueur Actualités
Programmer en binôme c’est se retrouver assis devant un écran d’ordinateur à deux et passer la journée à résoudre en tandem des problèmes en lien avec des projets informatiques. La pratique divise dans l’univers du développement de logiciels. Certains managers sont d’avis que leurs entreprises ont à gagner du partage de connaissances entre développeurs en duo. D’autres leur opposent le fait que l’approche implique un gaspillage de ressources humaines. La liste des points de contradiction est plus large et se décline en potentiels avantages et inconvénients à mettre en perspective avec une expérience personnelle.
Programmation en binôme : quels possibles avantages ?
Le partage de connaissances est l'avantage le plus évident à sortir du lot. Le fait que deux personnes travaillent sur un morceau de code permet à l'équipe de diffuser des connaissances sur la technologie et le domaine au quotidien et d'éviter les silos de connaissances. De plus, lorsque deux esprits comprennent et discutent d'un problème, nous augmentons les chances de trouver une bonne solution. Des expériences et des perspectives différentes conduiront à l'examen d'un plus grand nombre d'alternatives.
La programmation en binôme oblige les intervenants à discuter des approches et des solutions, au lieu d'y réfléchir uniquement dans leur tête. Dire et expliquer les choses à haute voix nous pousse à nous poser la question de savoir si nous avons vraiment la bonne compréhension, ou si nous avons vraiment une bonne solution. Cela ne s'applique pas seulement au code et à la conception technique, mais aussi à l'histoire de l'utilisateur et à la valeur qu'elle apporte.
Le fait d'être est susceptible de plus imposer une démarche structurée. En effet, chacun doit communiquer de facon explicite sur le pourquoi de chaque acte et sur la direction prise. En solo, l'on peut se laisser distraire beaucoup plus facilement, par exemple en essayant rapidement une approche différente sans y réfléchir, pour ensuite ressortir du terrier des heures plus tard. Le binôme peut empêcher cela d'arriver et aider à rester concentré sur ce qui est important pour terminer une tâche.
En binôme, 4 yeux veillent sur les petits et les grands détails au fur et à mesure. Ainsi, plus d'erreurs sont susceptibles de passer au détecteur en chemin plutôt qu'après avoir terminé. Il pourrait être plus aisé d'améliorer ou de procéder à des modifications du code avec quelqu'un à ses côtés, car ce peut être l'occasion de discuter à nouveau des approches.
La programmation en binôme peut permettre de s'assurer que chaque ligne de code a été touchée ou vue par au moins deux personnes. Cela augmente les chances que n'importe quel membre de l'équipe se sente à l'aise pour modifier le code presque partout. Cela rend également la base de code plus cohérente qu'elle ne le serait avec un seul codeur.
Quid des possibles inconvénients ?
Lorsque l'on travaille en solo, il est possible de faire des pauses quand on le souhaite et l'esprit peut aller vadrouiller un peu quand il en a besoin. Le travail en binôme par contre oblige à rester concentré pendant des périodes potentiellement plus longues et à trouver un terrain d'entente avec le rythme et la façon de penser de l'autre personne. Cette concentration accrue est l'un des avantages du jumelage, mais elle peut aussi le rendre assez intense et épuisant.
La programmation en binôme impose de communiquer constamment et cela exige de l'empathie et des compétences interpersonnelles. Les intervenants peuvent exhiber des différences de techniques, de connaissances, de compétences, d'extraversion, de personnalités ou d'approches de la résolution de problèmes. Certaines combinaisons de ces éléments peuvent ne pas s'accorder et vous donner un départ difficile.
La multiplication des réunions est l’un des facteurs que les acteurs de la filière du développement pointent du doigt comme une pierre d’achoppement dans l’exercice de leur métier. Lorsqu'une équipe pratique la programmation en binôme, l'effet d'un trop grand nombre de réunions peut encore s'aggraver. Si chacune des personnes travaillant en binôme a des réunions à des moments différents, les interruptions sont multipliées.
Lorsque deux personnes ayant des niveaux d'expertise différents travaillent en binôme sur un sujet, cela peut conduire à une absence de contribution d’une des parties voire même à un désengagement total. Résultat : pas de montée en compétence du tiers qui fait profil bas face à l’aura de son vis-à-vis.
Et vous ?
Ces différents aspects cadrent-ils avec la réalité dont vous êtes au fait ? Quels sont ceux qui manquent à l’appel selon vous ?
Pour ou contre la programmation en binôme ?
Quel est votre regard sur l’approche en tant que manager ?
Avez-vous déjà travaillé sur des projets de programmation en binôme ? Partagez votre expérience
Programmation en binôme : quels possibles avantages ?
Le partage de connaissances est l'avantage le plus évident à sortir du lot. Le fait que deux personnes travaillent sur un morceau de code permet à l'équipe de diffuser des connaissances sur la technologie et le domaine au quotidien et d'éviter les silos de connaissances. De plus, lorsque deux esprits comprennent et discutent d'un problème, nous augmentons les chances de trouver une bonne solution. Des expériences et des perspectives différentes conduiront à l'examen d'un plus grand nombre d'alternatives.
La programmation en binôme oblige les intervenants à discuter des approches et des solutions, au lieu d'y réfléchir uniquement dans leur tête. Dire et expliquer les choses à haute voix nous pousse à nous poser la question de savoir si nous avons vraiment la bonne compréhension, ou si nous avons vraiment une bonne solution. Cela ne s'applique pas seulement au code et à la conception technique, mais aussi à l'histoire de l'utilisateur et à la valeur qu'elle apporte.
Le fait d'être est susceptible de plus imposer une démarche structurée. En effet, chacun doit communiquer de facon explicite sur le pourquoi de chaque acte et sur la direction prise. En solo, l'on peut se laisser distraire beaucoup plus facilement, par exemple en essayant rapidement une approche différente sans y réfléchir, pour ensuite ressortir du terrier des heures plus tard. Le binôme peut empêcher cela d'arriver et aider à rester concentré sur ce qui est important pour terminer une tâche.
En binôme, 4 yeux veillent sur les petits et les grands détails au fur et à mesure. Ainsi, plus d'erreurs sont susceptibles de passer au détecteur en chemin plutôt qu'après avoir terminé. Il pourrait être plus aisé d'améliorer ou de procéder à des modifications du code avec quelqu'un à ses côtés, car ce peut être l'occasion de discuter à nouveau des approches.
La programmation en binôme peut permettre de s'assurer que chaque ligne de code a été touchée ou vue par au moins deux personnes. Cela augmente les chances que n'importe quel membre de l'équipe se sente à l'aise pour modifier le code presque partout. Cela rend également la base de code plus cohérente qu'elle ne le serait avec un seul codeur.
Quid des possibles inconvénients ?
Lorsque l'on travaille en solo, il est possible de faire des pauses quand on le souhaite et l'esprit peut aller vadrouiller un peu quand il en a besoin. Le travail en binôme par contre oblige à rester concentré pendant des périodes potentiellement plus longues et à trouver un terrain d'entente avec le rythme et la façon de penser de l'autre personne. Cette concentration accrue est l'un des avantages du jumelage, mais elle peut aussi le rendre assez intense et épuisant.
La programmation en binôme impose de communiquer constamment et cela exige de l'empathie et des compétences interpersonnelles. Les intervenants peuvent exhiber des différences de techniques, de connaissances, de compétences, d'extraversion, de personnalités ou d'approches de la résolution de problèmes. Certaines combinaisons de ces éléments peuvent ne pas s'accorder et vous donner un départ difficile.
La multiplication des réunions est l’un des facteurs que les acteurs de la filière du développement pointent du doigt comme une pierre d’achoppement dans l’exercice de leur métier. Lorsqu'une équipe pratique la programmation en binôme, l'effet d'un trop grand nombre de réunions peut encore s'aggraver. Si chacune des personnes travaillant en binôme a des réunions à des moments différents, les interruptions sont multipliées.
Lorsque deux personnes ayant des niveaux d'expertise différents travaillent en binôme sur un sujet, cela peut conduire à une absence de contribution d’une des parties voire même à un désengagement total. Résultat : pas de montée en compétence du tiers qui fait profil bas face à l’aura de son vis-à-vis.
Et vous ?
-
totozorMembre expertLes inventeurs de la programmation en binôme c'est la DDE, non?
Pour moi la réponse est simple : 2 personnes devant l'ordinateur, 1 devant le clavier, 1 qui... juge/aurait pas fait comme ça/au café/s'endors
J'ai vécu quelques situation de travail de "programmation" (je ne suis pas programmeur) en binôme:
_ Le binôme collaboratif : La pire de toutes. Celui derrière le clavier à l'impression d'être constamment surveiller, l'autre s'emmerde donc passe son temps à corriger. Ca devait durer 1 mois, à la fin de la journée nous avons tous les deux demandé d'arrêter.
_ Le binôme formateur/apprenant : Ca peut bien fonctionner si l'apprenant est derrière le clavier et si chacun accepte que la productivité n'est pas l'objectif.
_ Le binôme pluridisciplinaire : Je l'ai fait il y a un mois avec un collègue qui n'a pas le même profil que moi sur une tache qui a besoin d'un peu des deux. On avait du mal à avancer donc on s'est fait une journée en binôme. Ca a été super efficace mais compliqué au début mais quand on a compris qu'il fallait laisser le temps à l'autre de voir ses erreurs et de les corriger.
Je n'ai aucune bonne expérience de binôme collaboratif.
J'ai eu des très bonne, des bonnes, des mauvaises et des très mauvaises expériences de binôme formateur/apprenant.
je n'ai qu'une expérience pluridisciplinaire, elle a bien fonctionner sur une action coup de poing. Ca n'aurait pas fonctionner sur du plus long terme.le 22/02/2022 à 12:42 -
Ducon PhFutur Membre du ClubJ'ai pratiqué la programmation en binôme pendant des années... à ma grande satisfaction!
Une seule condition.
Deux profils différents.
Dans mon cas, un excellent programmeur en duo avec un bon programmeur qui avait une bonne connaissance du business cible.
Il nous est même arrivé dans des cas d'urgence de sortir du code sans cahier de charge!
Donc oui, mais...le 22/02/2022 à 15:29 -
PyramidevExpert éminentLa productivité de la programmation en binôme, c'est du cas par cas : ça dépend à la fois du binôme et de la tâche en cours.
Petits partages humoristiques :
Deux images de Vincent Déniel qui critiquent les gestionnaires qui s'opposent idéologiquement à la programmation en binôme :
https://vincentdnl.com/drawings/pair-programming/
https://vincentdnl.com/drawings/pair-programming2/
Une vidéo de Patrick Shyu qui, par contre, raille la programmation en binôme :le 23/02/2022 à 1:57 -
vertex.3FMembre éclairéPratiquement tous les aspects sont couverts par l'article.
Je suis "pour".
Et je peux comprendre qu'un manager fermé ou n'ayant jamais pratiqué cela ne soit pas en mesure d'en évaluer le bénéfice (on n'est pas forcément manager parce qu'on sait manager).
Je pratique le pair-programming depuis plusieurs mois en télétravail avec un junior qui en redemande... et moi aussi ! Nous codons à tour de rôle. Tantôt c'est lui qui tient le clavier et je le guide, ce qui me permet de réfléchir. Tantôt c'est moi qui code, et c'est à mon tour d'être le nez sur le guidon et à lui de prendre de la hauteur sur les fonctionnalités et me guider. Pire (ou mieux) : par ses questions le junior me fait analyser mes choix et habitudes et me fait prendre du recul, et cette remise en question me pousse à progresser moi-même plus vite. C'est génial : nous progressons ensemble.
Lorsque je lis des personnes évoquer les difficultés du travail en équipe et les possibilités de désaccord j'aurais tendance à répondre que le pair-programming demande de placer son égo au bon endroit et être capable de se remettre en question !
Tout pareil ! La restitution du besoin métier dans le code source mérite souvent de s'y pencher à 2.le 25/02/2022 à 19:01 -
thamnMembre avertiPour ma part, on a toujours des risques de désaccords qui peuvent arriver pendant les processus de revues de code, on n'envoie jamais de nouveau code sans faire de revue de code, je sais pas comment tu bosse mais ça me parait le grand minimum pour tout projet sérieux. Et je trouve ça extrêmement sain d'avoir des désaccords, parce que au mieux le point soulevé est a propos, au pire, tu dois expliquer les justifications.le 26/02/2022 à 8:41
-
CryptorNouveau membre du ClubQuand je vois les problèmes causés par deja du simple travaille d'équipe, c'est pas gagné
C'est intéressant dans le cadre d'intégration de juniors je pense, mais à terme quand on planche sur un projet on doit pouvoir suivre notre rythme, et surtout être dans notre bulle, pas être sollicité/devoir parler et écouter toute la journée: c'est épuisant pour pas grand chose, sans parler des risques de désaccords...le 22/02/2022 à 11:39 -
MadmacMembre extrêmement actifDans certains cas de figure précis ce peut être bon. Mais en général, les chargés de projets sont trop nuls pour créer des combinaisons gagnantes par exemple un expert en optimisation avec quelqu'un qui est au courant du programme existant.le 23/02/2022 à 7:58
-
vertex.3FMembre éclairéentierement d'accord
j'approuve aussi : le désaccord ici est une opportunité, pas un risque
ça me parait très juste, il est facile de conseiller mais bien souvent ce n'est qu'une fois le "nez" dans le code qu'on peut capter toutes les dimensions du probleme
Et evidemment, forcer le pair programming me parait difficile, le consentement doit etre mutuel
je ne pense pas qu'on veuille faire de cet outil une "généralité" : comme tous les outils on choisit le pair programming en fonction du contexte
justement, le pair programming peut accélérer la prise d'autonomie (junior, formation d'un binone, etc)
pratiqué en télétravail durant des semaines je confirme que c'est encore plus simple, chacun est chez soi bien en face de son écran, et à tour de rôle chacun partage son écran (via TEAMS ou analogue) et code sous le "controle" de son coequipier : ce dernier a l'esprit libre des contraintes pratiques (du clavier, de l'IDE, du compilateur, etc.) et il peut prendre de la hauteur pour mieux guider l'autrele 26/02/2022 à 22:39 -
Mister NonoMembre chevronnéOn peut aussi faire du pair-programming via des produits comme jetbrains où on peut partager le code source.le 04/03/2022 à 9:42
-
MingolitoMembre extrêmement actifLa technique de la programmation en binôme c'est la misère, car deux programmeurs trop nuls pour programmer tout seuls ne remplacerons jamais un bon développeur apte à programmer très vite et facilement n'importe quoi, grâce entre autre à sa créativité.
Le problème c'est que les bons développeurs sont rares, donc les entreprises doivent inventer n'importe quoi même pour avoir quelques misérables lignes de code merdiques faites à 2.
Coté des ESN c'est le jackpot, au lieu de facturer un bon développeur impossible à trouver, on recrute n'importe quels loosers inaptes et on en facture deux pour le coup au lieu d'un, et la mission dure bien plus longtemps tellement ils sont nulsle 22/02/2022 à 15:28