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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Pour ou contre la programmation en binôme ?

Votants
27. Vous ne pouvez pas participer à ce sondage.
  • Je suis pour

    15 55,56%
  • Je suis contre

    10 37,04%
  • Je n'ai pas d'avis

    2 7,41%
Débats sur le développement - Le Best Of Discussion :

Pour ou contre la programmation en binôme ? La question divise les acteurs de la filière


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    2 091
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 2 091
    Points : 56 503
    Points
    56 503
    Par défaut Pour ou contre la programmation en binôme ? La question divise les acteurs de la filière
    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 ?

    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

  2. #2
    Nouveau membre du Club
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2022
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2022
    Messages : 7
    Points : 37
    Points
    37
    Par défaut
    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...

  3. #3
    Expert confirmé
    Homme Profil pro
    ingénieur qualité
    Inscrit en
    Mars 2015
    Messages
    1 365
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : ingénieur qualité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mars 2015
    Messages : 1 365
    Points : 4 130
    Points
    4 130
    Par défaut
    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.

  4. #4
    Expert éminent
    Avatar de berceker united
    Profil pro
    SQL
    Inscrit en
    Février 2005
    Messages
    3 501
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : SQL
    Secteur : Finance

    Informations forums :
    Inscription : Février 2005
    Messages : 3 501
    Points : 6 086
    Points
    6 086
    Par défaut
    Je rejoins totalement ce que marque Totozor.
    Cela pose quelque problèmes. Il faut prendre en compte plusieurs paramètres.
    - L'expérience de chacun
    - Sa sensibilité de développement. Un développeur est comme un écrivain.
    - Le temps qui lui est consacré
    - L'entente entre les deux personnes.

    Ca fait trop de paramètre à prendre en compte pour que ça puisse marcher dans le temps. C'est bien quand c'est ponctuel car des fois, à avoir le nez dans le guidon on ne fait plus attention. L'autre peut y apporter sont idée d'amélioration.

    Je terminerais par; à chaque fois qu'il y a un dev au dessus de l'épaule, on a tendance à faire que de la merde. On a l'impression de découvrir le clavier

  5. #5
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    Janvier 2014
    Messages
    1 560
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 560
    Points : 5 966
    Points
    5 966
    Par défaut
    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. #6
    Futur Membre du Club
    Homme Profil pro
    ex - pensionné
    Inscrit en
    Janvier 2017
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 74
    Localisation : Belgique

    Informations professionnelles :
    Activité : ex - pensionné
    Secteur : Finance

    Informations forums :
    Inscription : Janvier 2017
    Messages : 1
    Points : 9
    Points
    9
    Par défaut
    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...

  7. #7
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Tech Lead
    Inscrit en
    Avril 2016
    Messages
    1 492
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Tech Lead

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 492
    Points : 6 202
    Points
    6 202
    Par défaut
    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 :

    Nom : a.png
Affichages : 4010
Taille : 457,6 Ko

    https://vincentdnl.com/drawings/pair-programming/

    Nom : b.png
Affichages : 3609
Taille : 304,3 Ko

    https://vincentdnl.com/drawings/pair-programming2/

    Une vidéo de Patrick Shyu qui, par contre, raille la programmation en binôme :


  8. #8
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 709
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 709
    Points : 1 453
    Points
    1 453
    Billets dans le blog
    7
    Par défaut
    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.

  9. #9
    Membre chevronné Avatar de Mister Nono
    Homme Profil pro
    Ingénieur Mathématiques et Informatique
    Inscrit en
    Septembre 2002
    Messages
    2 234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur Mathématiques et Informatique
    Secteur : Santé

    Informations forums :
    Inscription : Septembre 2002
    Messages : 2 234
    Points : 1 897
    Points
    1 897
    Par défaut
    Le pair-programming peut être très efficace pour résoudre un problème difficile mais il ne faut pas non plus en abuser.

  10. #10
    Membre actif
    Profil pro
    Inscrit en
    Octobre 2011
    Messages
    197
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : Octobre 2011
    Messages : 197
    Points : 225
    Points
    225
    Par défaut
    ça dépend de la situation, mais des fois ça fait avancer plus vite sur un code compliqué où chacun peut avoir des idées différentes, et débloquer des situations plus vite. Mais des fois, ça ne doit pas être adapté.

  11. #11
    Membre éclairé

    Homme Profil pro
    Ouvrier de l'informatique [ et quelquefois ingénieur logiciel ]
    Inscrit en
    Mars 2013
    Messages
    188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Lot et Garonne (Aquitaine)

    Informations professionnelles :
    Activité : Ouvrier de l'informatique [ et quelquefois ingénieur logiciel ]
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2013
    Messages : 188
    Points : 777
    Points
    777
    Par défaut
    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.

  12. #12
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 131
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 131
    Points : 33 074
    Points
    33 074
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par gstratege Voir le message
    ça dépend de la situation, mais des fois ça fait avancer plus vite sur un code compliqué où chacun peut avoir des idées différentes, et débloquer des situations plus vite. Mais des fois, ça ne doit pas être adapté.
    Ça s'appelle juste discuter de son problème avec quelqu'un pour échanger des idées. Tu prends quelques minutes/heures pour réfléchir sur un morceau de code ou un concept, puis tu l'implémentes avec les nouvelles informations acquises.
    Le pair-programming est stupide. Les rares fois où je l'ai vu faire c'était par des débutants, donc aucun pour pousser l'autre vers le haut et sans excuse valable hors se tourner les pouces à moitié (celui qui contrôle pas le clavier n'est qu'à moitié engagé dans le truc).
    Soit tu as l'expérience et tu fais ton truc pendant que l'autre est touriste, soit tu es le touriste et suis ce que l'experimenté te dit. Aucun intérêt en dehors de la formation d'un nouveau et donc à court terme.
    Il y a déjà les revues de code pour ça, et tu peux toujours demander de l'aide à tes collègues, inutile de forcer ce concept qui n'apporte rien de plus ou mieux.

  13. #13
    Invité
    Invité(e)
    Par défaut
    Bonsoir,

    Pour ou contre la programmation en binôme ?
    Pour

    Les acteurs de la filière du développement dispersés entre divers avis : Moyen de partage de connaissances ?
    Oui moyen de partage de connaissance. Plutôt de "truc et astuce" je dirais

    Gaspillage de ressource humaine ?
    Cela dépend comme c'est utilisé ... Partager de la connaissance et de la bonne pratique fait avancer ... Donner des ordres ou exiger qu'on pratique d'une sorte ne sert à rien.

    Ces différents aspects cadrent-ils avec la réalité dont vous êtes au fait ?
    Non je n'ai pas eu cette approche. J'ai connu le travail en "tandem".

    Dans un domaine de service financier. Mon collègue déroule de la ligne , quitte à "pisser du code". De mon côté il me donne l'algo et me demander de tester celui ci. Dès que je trouvais un élément "merdique" ou mal optimisé, je devais chercher une alternative. On se concerte une fois que j'ai une solution . La personne avec qui j'ai travaillé, étant plutôt ouverte on a pas mal partagé sur le sujet.

    Quels sont ceux qui manquent à l’appel selon vous ?
    Le travaille en tandem.

    Pour ou contre la programmation en binôme ?
    Pour. C'est comme le brainstorming . Partager du "savoir" et de la "connaissance" ne fait jamais de mal.

    Avez-vous déjà travaillé sur des projets de programmation en binôme ?
    Pas a proprement parlé.

  14. #14
    Membre averti
    Profil pro
    Développeur
    Inscrit en
    Octobre 2008
    Messages
    122
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Octobre 2008
    Messages : 122
    Points : 426
    Points
    426
    Par défaut
    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?

  15. #15
    Membre averti
    Profil pro
    Développeur
    Inscrit en
    Octobre 2008
    Messages
    122
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Octobre 2008
    Messages : 122
    Points : 426
    Points
    426
    Par défaut
    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.

  16. #16
    Membre averti
    Profil pro
    Développeur
    Inscrit en
    Octobre 2008
    Messages
    122
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Octobre 2008
    Messages : 122
    Points : 426
    Points
    426
    Par défaut
    Citation Envoyé par Bousk Voir le message
    Ça s'appelle juste discuter de son problème avec quelqu'un pour échanger des idées. Tu prends quelques minutes/heures pour réfléchir sur un morceau de code ou un concept, puis tu l'implémentes avec les nouvelles informations acquises.
    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.

  17. #17
    Membre expérimenté
    Homme Profil pro
    retraité
    Inscrit en
    Septembre 2014
    Messages
    630
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Septembre 2014
    Messages : 630
    Points : 1 499
    Points
    1 499
    Par défaut
    Pour résoudre un problème coriace, pourquoi pas ? Pour un débutant aussi.
    Mais de là à en faire une généralité...
    Et sinon, quid si le binôme démissionne, disparait, meurt subitement ? On le remplacera, c'est certain.
    Qui peut accepter de passer des mois ainsi ?
    "Ils" avaient tenté d'envisager ce type de bouffonnerie dans ma boite : c'est vite tombé à l'eau, et bien profond.
    Quant à l'autonomie au fil du temps dans ce type de condition...
    Et merci en période de télétravail...ahahahahah
    Mais franchement, il y a des diplômés d'études supérieures qui fument grave la moquette...

  18. #18
    Membre éclairé

    Homme Profil pro
    Ouvrier de l'informatique [ et quelquefois ingénieur logiciel ]
    Inscrit en
    Mars 2013
    Messages
    188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Lot et Garonne (Aquitaine)

    Informations professionnelles :
    Activité : Ouvrier de l'informatique [ et quelquefois ingénieur logiciel ]
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2013
    Messages : 188
    Points : 777
    Points
    777
    Par défaut
    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

  19. #19
    Membre averti

    Homme Profil pro
    Développeur Web
    Inscrit en
    Octobre 2013
    Messages
    189
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Pérou

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Octobre 2013
    Messages : 189
    Points : 379
    Points
    379
    Par défaut Télétravail
    Bonne idée
    C'est juste que pour moi, ce sera en télétravail
    Un volontaire pour un complément binomial au Pérou ?

  20. #20
    Membre chevronné Avatar de Mister Nono
    Homme Profil pro
    Ingénieur Mathématiques et Informatique
    Inscrit en
    Septembre 2002
    Messages
    2 234
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur Mathématiques et Informatique
    Secteur : Santé

    Informations forums :
    Inscription : Septembre 2002
    Messages : 2 234
    Points : 1 897
    Points
    1 897
    Par défaut
    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.

Discussions similaires

  1. Arguments pour et contre Access ?
    Par bottura dans le forum Sondages et Débats
    Réponses: 240
    Dernier message: 24/03/2018, 00h25
  2. Réponses: 5
    Dernier message: 17/08/2017, 19h40
  3. adapter un programme pour jouer contre la machine,
    Par l1informatique dans le forum Général Python
    Réponses: 1
    Dernier message: 28/08/2014, 12h06
  4. Réponses: 0
    Dernier message: 28/06/2009, 21h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo