IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Patrick Ruiz

54PARTAGES

10  0 
Pour ou contre la programmation en binôme ?
Je suis pour
58 %
Je suis contre
35 %
Je n'ai pas d'avis
8 %
Voter
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de totozor
Membre confirmé https://www.developpez.com
Le 22/02/2022 à 12:42
Les 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.
11  1 
Avatar de Ducon Ph
Futur Membre du Club https://www.developpez.com
Le 22/02/2022 à 15:29
J'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...
6  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 23/02/2022 à 1:57
La 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 :

5  1 
Avatar de vertex.3F
Membre éclairé https://www.developpez.com
Le 25/02/2022 à 19:01
Citation Envoyé par Patrick Ruiz Voir le message

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
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 !

Citation Envoyé par Ducon Ph Voir le message
J'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...
Tout pareil ! La restitution du besoin métier dans le code source mérite souvent de s'y pencher à 2.
4  0 
Avatar de thamn
Membre actif https://www.developpez.com
Le 26/02/2022 à 8:41
Citation Envoyé par Cryptor Voir le message
sans parler des risques de désaccords...
Pour 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.
4  0 
Avatar de Cryptor
Nouveau membre du Club https://www.developpez.com
Le 22/02/2022 à 11:39
Quand 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...
5  2 
Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 23/02/2022 à 7:58
Dans 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.
3  1 
Avatar de vertex.3F
Membre éclairé https://www.developpez.com
Le 26/02/2022 à 22:39
Citation Envoyé par thamn Voir le message
Programmer en binôme peut être, je trouve, très utile en particulier dans une situation ou un autre développeur doit ponctuellement mettre le nez dans une partie du code qu'il ne connait pas bien. Dans ce cas, coder en binôme avec un programmeur qui a de l’expérience dans la partie du code a modifier permet d'aborder le problème avec toutes les connaissances requises, ça peut éviter de long aller-retour en review ou tu perds du temps a expliquer tel ou tel point chelou (ou a te faire expliquer selon le cas), voir même pire, personne ne comprends vraiment les problématiques de chacun sans vraiment s'en rendre compte, et au final la solution est bancale mais on s'en rendra compte dans 2/3 mois

Mais d’être forcé de toujours travailler en binôme me semble totalement contre productif (je crois que je détesterai ça), mais peut-être ça dépend du domaine, si mes programmes pouvait risquer des vies peut-être que ça pourrait se justifier de devenir systématique?
entierement d'accord

Citation Envoyé par thamn Voir le message
Pour 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.
j'approuve aussi : le désaccord ici est une opportunité, pas un risque

Citation Envoyé par thamn Voir le message
Je pense justement que c'est assez différent. Parce que en discutant les idées, on n'est pas vraiment confronté au réalités concrètes, genre le code est mal fichu, ça oblige a faire des concessions parfois, ou alors les besoins sont complexes et tu peux pas faire un transfert instantané de ce que ton interlocuteur sais, il va t'expliquer en gros, tu vas rater des détails qui peuvent etre crucial pour vraiment comprendre le probleme. Quand tu code ensemble, tu es confrontés au même problème que ton collègue au même moment, et je crois que c'est assez different que de parler d'un probleme a regler (meme si c'est utile aussi).
Mais clairement comme tu dis, le forcer est totalement inutile, ça doit se faire quand le besoin s'en fait sentir.
ç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

Citation Envoyé par TotoParis Voir le message
Pour résoudre un problème coriace, pourquoi pas ? Pour un débutant aussi.
Mais de là à en faire une généralité...
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

Citation Envoyé par TotoParis Voir le message
Quant à l'autonomie au fil du temps dans ce type de condition...
Et merci en période de télétravail...ahahahahah
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'autre
2  0 
Avatar de Mister Nono
Membre chevronné https://www.developpez.com
Le 04/03/2022 à 9:42
Citation Envoyé par vertex.3F Voir le message
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'autre
On peut aussi faire du pair-programming via des produits comme jetbrains où on peut partager le code source.
2  0 
Avatar de Mingolito
Membre extrêmement actif https://www.developpez.com
Le 22/02/2022 à 15:28
La 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 nuls
6  5