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 !

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

Le , par Arsene Newman

127PARTAGES

0  2 
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 ?

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

Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 01/09/2014 à 13:01
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.
7  0 
Avatar de 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?"
7  1 
Avatar de 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.
6  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 16/10/2014 à 15:12
les "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.
5  0 
Avatar de 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 ^^
7  4 
Avatar de 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 ?
5  2 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 05/09/2014 à 12:53
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 ?
3  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 15/10/2014 à 17:21
Citation Envoyé par PeterQTV Voir le message
A mon avis le mieux est que le senior explique la tâche au junior, avec les bonnes pratiques et les potentiels pitfalls puis lui laisser le temps pour travailler, tout en restant disponible pour répondre aux questions. A la fin (une, deux heures ou bien une matinée), les deux feront un code review.
Je pense que cela est plus productif pour les deux.
Pour 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.
3  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 16/10/2014 à 12:11
Citation Envoyé par PeterQTV Voir le message
Bien que je ne l'ai pas vraiment pratiqué, mais je ne vois pas bcq d'utilité !
Relis ce qui a été dit précédemment ;-)

Citation Envoyé par PeterQTV Voir le message
La théorie dit que le dév le moins experimenté prendra le clavier et plus expérimenté l'assiste![...]
Et si l'inverse est appliqué, le dev junior sera rapidement déconnecter.
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.

Citation Envoyé par PeterQTV Voir le message
En soit c'est frustrant pour un expert de s'assoir à côté et donner de consignes, c'est très démotivant.
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

Citation Envoyé par PeterQTV Voir le message
A mon avis le mieux est que le senior explique la tâche au junior, avec les bonnes pratiques et les potentiels pitfalls puis lui laisser le temps pour travailler, tout en restant disponible pour répondre aux questions. A la fin (une, deux heures ou bien une matinée), les deux feront un code review.
Je pense que cela est plus productif pour les deux.
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.
3  0 
Avatar de MarieKisSlaJoue
Membre expert https://www.developpez.com
Le 05/09/2014 à 16:52
Quelqu'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 pull
2  0