Quelle est la fréquence de la programmation par paires sur le lieu de travail?

J'ai toujours été intrigué par la programmation en binôme, mais en 12 ans de développement, je n'ai jamais travaillé dans un endroit où ils ont utilisé cette pratique, donc j'ai toujours été sceptique quant à la façon dont les gens le voient.

Je me demande si c'est à cause de l'argent / du temps (un patron aux cheveux pointus repérant deux personnes sur un ordinateur travaillant sur le même code !!!! comment osent-elles!) Ou pour d'autres raisons?

J'ai eu le même concert pendant 15 ans et nous avons récemment (12-18 derniers mois) commencé à adopter des techniques Agiles. Lorsque la programmation par paire est utilisée, le scénario / la fonctionnalité de résultat a été mis en œuvre à temps avec moins de défauts. Je ne pense toujours pas qu'il ait été employé assez souvent.

Avant notre adoption Agile, un autre développeur et moi avons rarement partagé le clavier au fil des ans (peut-être une fois tous les 3-4 mois). Notre équipe de direction semblait réticente mais était toujours satisfaite de notre association informelle, car elle accomplissait généralement quelques-unes des actions suivantes:

• silos réduits sur l'équipe (énorme victoire lorsque l'équipe compte 6-8 devs)
• code produit avec moins de défauts
• chaque développeur a généralement acquis des compétences

Je dirais que la direction est réticente, mais si vous pouvez faire de petits pas et démontrer que la fonctionnalité est meilleure par la suite (économies de coûts) et / ou que chaque (ou un) développeur a acquis certaines compétences (en le payant à l'avance), vous pouvez acquérir de la vapeur si vous trouvez que c'est une pratique qui vous convient, vous ou votre équipe.

Je suppose qu'il y aurait probablement beaucoup de résistances de la part des développeurs. Vous souvenez-vous d'avoir été forcé de travailler avec des gens qui n'étaient peut-être pas les personnes les plus motivées au monde au collège ou même au lycée? Ces gens existent toujours. Sauf si vous avez une équipe composée de toutes les personnes "de premier ordre", ce type de configuration provoquera une certaine animosité dans le groupe.

Je ne l'ai pas fait officiellement, mais chaque fois que je serai coincé, j'appellerai un développeur et nous travaillerons ensemble sur une solution. C'est un excellent moyen de faire rebondir des idées, de laisser une personne réfléchir pendant que l'autre met en œuvre, de sorte que vous ne perdiez pas votre fil de la pensée parce que vous la tapez.

Je souhaite que cela soit fait plus.

Je m'en fous:

1 - J'aime écouter ma musique pendant le codage. Tout le monde ne veut pas entendre Slayer exploser dans leurs oreilles.

2 - J'ai été élevé en considérant que regarder par-dessus les épaules des gens était très grossier et très inconfortable quand les gens le faisaient.

3 - Je pense très vite et quand je suis sur un fil de solution, quand je commence à trouver une réponse, être interrompu est la toute dernière chose dont j'ai besoin.

4 - Je ne peux pas prendre de pauses occasionnelles pour parcourir les forums et les groupes de discussion. Certains pourraient penser que c'est inapproprié de toute façon, mais je trouve cela très important pour mon amélioration continue. Parfois, je serai trop distrait, mais généralement l'avantage de mes connaissances accrues l'emporte sur tout impact sur ma productivité.

Je suppose que cela pourrait être différent sur d'autres équipes, mais les rares fois où je suis réellement perplexe par quelque chose et BESOIN d'aide, je suis presque toujours celui qui finit par trouver la solution de toute façon. Je suis vraiment bon dans ce que je fais mais je pense qu'il pourrait y avoir plus de choses en cours ... je ne suis pas sûr, en tout cas, je trouve que je suis mieux à résoudre les problèmes difficiles et généralement mieux à le faire seul. Cela peut sembler arrogant, mais cela ne le rend pas faux.

J'ai considéré que cela pourrait en fait aider les autres à choisir certaines de mes techniques, mais, en tenant compte de la question n ° 3, ils seraient à peine en mesure de poser des questions sans briser ma pensée de toute façon.

Cela dit, je l'ai essayé de temps en temps. Parfois, cela a des avantages mineurs, mais je ne peux certainement pas le voir comme une chose cohérente. Le système du loup solitaire fonctionne pour moi et il semble fonctionner pour l'équipe.

La programmation par paires est un excellent moyen de commencer ou de faire quelque chose de non trivial et difficile. Des tâches plus routinières et simples sont mieux effectuées seules.

J'ai participé à un certain nombre de sessions de programmation en binôme, tant dans des startups / garages que dans de grandes entreprises. Cela n'arrivait invariablement que lorsque quelque chose de nouveau et de difficile était accepté, c'est-à-dire deux fois par an au mieux, pendant quelques semaines. À quelle fréquence cela se produit-il dans votre entreprise?

Nous ne l'avons jamais appelé ainsi, mais à l'époque, c'est ainsi que nous avons toujours attaqué de nouveaux problèmes. Nous nous associons pour commencer une solution, mais nous nous séparons généralement pour terminer / nettoyer les détails individuellement. Plus tellement. Semble devenir de plus en plus rare.

Pas très courant. Dans tous les magasins où je suis allé depuis plus de 10 ans, je l'ai vu une fois. Dans le magasin le plus lent et le moins efficace. Il semble créer un environnement bruyant et stressant. Une personne finit par conduire et parle constamment, empêchant l'autre de penser.

Rassemblez l'équipe pour des révisions de code, que ce soit en groupe ou en binôme, et donnez aux développeurs leur propre espace. Ce sera mieux à long terme que de courir après la dernière mode agile.