La programmation par paire signifie un coût double par développeur. Est-ce que ça vaut cet argent?

La programmation par paires en Agile nous oblige à doubler le salaire versé à un seul programmeur. Bien sûr, avec une telle approche, la qualité du code est bien meilleure, les bogues sont trouvés beaucoup plus tôt, mais est-ce que cela vaut toujours cet argent? Peut-être devrions-nous payer le salaire du deuxième développeur aux quelques testeurs (ces derniers sont généralement beaucoup moins chers que le programmeur qualifié)? Quelqu’un at-il une expérience avec une telle comparaison?

Comment savez-vous que vos programmeurs non associés sont plus efficaces? Je pense parfois que le single / la paire est comparable au vieux conte de fée du lapin et de la tortue.

Le jumelage ne se déroule pas en jours de travail contre-productif. Je n’ai aucune idée de la fréquence à laquelle les développeurs ont passé des semaines à travailler sur des choses qui se révèlent plus tard remplacées par quelque chose de beaucoup plus simple. Le seul programmeur “dans la zone” fait souvent des choses stupides. Il est trop facile de produire trop de code, alors que vous voulez plus de punch avec moins de code.

Et dans la postérité, lorsque la poussière retombe, vous trouvez des centaines, voire des milliers de lignes de code qui n’auraient pas pu être écrites parce que quelqu’un ne connaissait pas la bibliothèque X ou la technique Y. Le couplage améliore ce problème mais ne le supprime pas. Il encourage les individus et les deux à faire plus de recherches avant de plonger dans l’euphorie du code stupide.

J’aurais aimé pouvoir jumeler plus ….

Nous utilisons cette approche dans notre entreprise, mais uniquement pour les tâches difficiles ou lorsque vous n’êtes pas sûr de ce sur quoi quelqu’un d’autre a déjà travaillé et qui, selon moi, fonctionne très bien. Cela vous évite de restr coincé dans une ornière et de pouvoir échanger des idées avec des personnes si nécessaire, tout en étant capable de travailler de manière autonome pour la plupart des tâches simples.

Je crois aussi que c’est plus bénéfique qu’une revue de code, qui est quelque chose d’autre que nous faisons là où je travaille. Il est souvent difficile de savoir exactement ce qui se passe lorsque vous faites une revue de code sans fournir un contexte significatif. À ce stade, vous n’avez pas toujours le temps de réfléchir à tous les éléments. La programmation par paires vous donne ce contexte dès le départ et vous permet de passer plus de temps à réfléchir aux cas extrêmes qui peuvent ou non causer des problèmes.

Bien que je sois d’accord avec la majeure partie de la réponse jusqu’à présent sur le fait que la programmation en binôme soit une bonne chose, je vais jouer l’avocat du diable et argumenter que cela n’a pas toujours de sens.

Lorsque vous vous jumelez, vous n’obtenez pas un programmeur qui a le double des cerveaux. Vous obtenez un programmeur qui est l’ union de vos deux cerveaux. Donc, fondamentalement, chaque fois que je bousille et que mon partenaire attrape ou trouve quelque chose de mieux, c’est un plus. Cependant, chaque fois que j’écris moi-même le code correct est une perte de temps puisque mon partenaire n’était pas nécessaire.

Fondamentalement, vous devez évaluer le code sur lequel vous travaillez. Des tâches simples ne valent généralement pas l’argent pour payer une personne qui s’assoit par-dessus son épaule et s’assurer que vous avez bien écrit votre boucle. Cependant, à un certain seuil, les tâches sont suffisamment compliquées pour justifier le choix de la programmation par paires.

Avec la programmation par paire, vous combinez:

  • Code de qualité supérieure
  • Meilleure dissortingbution de la connaissance interne
  • Plus d’esprit d’équipe

Vous n’obtiendrez pas autant de retour sur investissement que cela.

Là encore, vous ne devriez pas l’utiliser pour toutes les tâches.

Cela ne signifie pas le double du coût si cela prend moins de la moitié du temps que cela aurait pris avec un dev. Je pense que sur des tâches difficiles ou de bas niveau, cela serait utile. Je trouve que ça vaut le coup parce que tu as quelqu’un à dire “non, ne fais pas ça!” bien avant que cela ne finisse dans le code de production où cela vous coûtera VRAIMENT temps et argent.

J’ai écrit des systèmes d’exploitation et des choses de cette nature où il était inestimable que quelqu’un soit assis à côté de moi pour vérifier ma logique.

Au travail, nous utilisons la programmation en paires tout le temps. L’astuce consiste à savoir quelles tâches doivent être effectuées en paire et quelles seraient les “pertes de temps” si elles étaient effectuées par deux développeurs. La règle de base est que les tâches qui sont davantage axées sur la recherche (par exemple, les POC et les pics) doivent être effectuées par paires, de même que le développement de nouvelles fonctionnalités (pour que la connaissance existe dans plusieurs esprits). Les tâches plus simples telles que l’installation du serveur CI ou le remplacement des icons d’addons sont effectuées par un seul développeur. Un autre facteur est la disponibilité actuelle des membres de l’équipe et les tâches en cours à effectuer lors de cette itération.

Non, vous ne le faites pas Chaque programmeur reçoit exactement un salaire.

Pensez-vous que vos programmeurs ne se parleront pas si vous ne l’appelez pas “programmation par paires”? Pensez-vous que la programmation est parfaitement parallélisable?

C’est difficile à dire – j’ai passé beaucoup de temps à travailler dans un environnement à paire de forces et dans un environnement optionnel de couplage. Le code de qualité le plus élevé que j’ai vu n’est pas dans l’environnement apparié. Cela a probablement plus à voir avec le calibre et la discipline des développeurs individuels. Parfois, vous aurez de l’argent à jumeler, en particulier lorsque certains codeurs ne sont pas de premier rang. Mais si tous les codeurs sont des codeurs expérimentés et bien disciplinés, vous ne faites que gaspiller votre argent s’ils sont jumelés tout le temps.

Un type d’expérience que j’ai eu plusieurs fois a eu un impact énorme sur ma discipline de codage et la qualité du produit que je produis: porter un téléavertisseur. Lorsque je dois prendre en charge un système pour lequel je code, cela modifie mon code. C’est-à-dire que je code de manière à empêcher ce téléavertisseur de se déclencher. Le résultat est un produit de meilleure qualité, et généralement une meilleure qualité de code. Les codeurs que j’ai vus qui n’ont jamais transporté de téléavertisseur produisent un code plus fragile. Ce n’est pas quelque chose qu’ils peuvent même comprendre et améliorer jusqu’à ce qu’ils soient sur support.

La programmation par paires peut être incroyablement efficace, mais vous ne devriez pas engager de programmeurs par paires. Vous ne pouvez pas forcer les développeurs à associer le programme. Cela ne fonctionne que lorsque deux développeurs cliquent et décident qu’ils peuvent apprendre les uns des autres et créer quelque chose de génial ensemble. Mon conseil est d’embaucher autant de développeurs intelligents que vous pouvez trouver et de les placer dans un environnement propice à la programmation de paires à temps partiel. Les développeurs doivent pouvoir coder seuls, mais ils peuvent également en parler aux autres membres de l’équipe.

Trouver le bon mélange qui fonctionne pour vous et votre entreprise sera plus art que science, et certainement pas quelque chose que vous pouvez faire en suivant aveuglément les exigences de certaines méthodes publiées.

Cela dit, plus vous écrasez de bogues avant qu’ils ne soient enregistrés, plus vous économisez sur le long terme. Avoir un autre développeur regardant comme architecte sera toujours plus efficace que d’avoir un boitier testeur par la suite. J’appellerais ça de l’argent bien dépensé.

Plus un bug / défaut est détecté tôt, moins il est coûteux à réparer, donc utiliser de l’argent pour embaucher plus de gens par rapport à d’autres développeurs va vous coûter plus de temps et d’argent en raison du nombre de voyages de DEV à QA.

Cela dit, la programmation par paires ne fonctionne pas avec tout le monde, certains développeurs ne font pas bon ménage, ils se distraient, passent tout leur temps à se battre, etc.

Si vous avez des développeurs qui peuvent associer des programmes, cela peut être plus bénéfique à long terme lorsque vous ajoutez du code plus maintenable, moins de défauts, donc moins de temps en QA et surtout si l’un des développeurs est touché par un bus. Vous n’avez pas à attendre que quelqu’un se mette au travail sur un projet avant de pouvoir continuer à travailler.

Si vos développeurs ne peuvent pas associer le programme, ne les forcez pas, tout ce que vous allez faire est de perdre du temps et de l’argent.

La première hypothèse de la programmation par paires est qu’une carte récit coûte deux fois plus cher à développer. L’hypothèse est erronée. Voici pourquoi?

  • Qualité améliorée : une paire de programmeurs actifs travaillant sur la même carte récit complètera la carte avec moins de défauts
  • Productivité améliorée : une paire est moins susceptible d’être ralentie si elle n’est pas totalement bloquée lors de la résolution d’un problème. En outre, il est plus difficile de prendre un courrier électronique ou de passer des vacances sur Internet lorsque vous travaillez avec un partenaire … vous ne voulez pas laisser tomber le partenaire. Vous allez résoudre le problème avec un design plus propre et moins de lignes de code lorsque vous travaillez en paire
  • Éliminez les silos de connaissances : avec les paires tournantes, vous apprendrez les connaissances métier des applications et des domaines au sein de l’équipe. L’équipe est moins susceptible d’être bloquée parce que Sue en vacances et personne d’autre ne connaît son code.
  • Transfert de connaissances: les paires rotatives enseignent de nouvelles compétences (ingénierie et domaine) lorsqu’elles travaillent ensemble. Le niveau de l’équipe augmentera pour tout le monde et les connaissances se propagent à travers l’équipe.
  • Auto-sélection de l’ équipe : L’équipe apprend les compétences d’une autre et élimine rapidement quelqu’un qui ne fonctionne pas.

L’expérience nous a permis de constater une baisse significative des défauts. De nouveaux membres de l’équipe peuvent être ajoutés sans ralentir l’équipe (essayez cela avec une équipe non jumelée). Pour un essai, une équipe a estimé le travail pour un ensemble de cartes récit comme si six développeurs pouvaient compléter le code individuellement. Les six développeurs ont ensuite été invités à se jumeler. Ils ont terminé le travail à temps avec une qualité élevée. Si vous ne faites pas la paire, vous passez beaucoup de temps à fournir peu de qualité, vous n’avez aucun moyen de faire évoluer votre entreprise et vous possédez trop de silos d’expertise.

Dans un deuxième exemple, nous avons estimé que nous devions terminer le travail dans le temps demandé, nous devions prendre une équipe de 4 à 7 paires. Nous nous sums donnés 1 mois à bord des nouvelles paires. Nous avons associé un nouveau développeur à un développeur expérimenté et avons fait pivoter les paires sur des cartes récit. L’équipe a atteint tous les livrables avec la qualité dans le temps prévu. Sans appariement, on n’aurait pas pu append 6 développeurs à une équipe de 8 développeurs et atteindre la barre!

En bout de ligne, vous économiserez de l’argent avec le jumelage. Vous prendrez à peu près le même temps, la livraison avec une qualité supérieure, améliorerez la performance des équipes, les compétences et les connaissances et éliminerez le bois mort. Vos économies s’accompagneront d’un rythme soutenu et de moins de défauts sur le plan de la réduction de l’équipe.

Le principe est que votre productivité fait plus que doubler. Une partie du gain est réalisée immédiatement (par exemple, avant que le code ne soit enregistré) et une partie est réalisée plus loin, lorsque le nombre de bogues et de pannes diminue.

Lorsque j’enseigne à des étudiants ayant une expérience de deux semestres, pour la plupart des couples, leur productivité dépasse le double car ils se posent des questions et apprennent et terminent plus rapidement. Mais ce n’est pas universellement vrai. une paire mal appariée peut prendre plus de temps et faire pire que la moitié plus qualifiée.

L’expérience de gestion de la qualité de nombreuses autres indussortinges nous apprend que la prévention des défauts est moins coûteuse à long terme que la détection de défauts (également appelée assurance qualité) et la fixation ultérieure.

Ils ont également appris que le long terme se situe dans la plupart des cas entre 1 et 2 ans, ce qui signifie que votre investissement sera rentable par la suite. Considérant que les investissements de cette envergure sont généralement attendus après 4 ans, c’est plutôt bien!

Le problème est qu’il a fallu plusieurs décennies aux autres indussortinges pour accumuler suffisamment de données pour pouvoir prouver que c’est le cas pour elles. Vous pouvez facilement trouver des données pour prendre en charge leur conclusion et tirer une conclusion pour les logiciels par analogie, mais à ce jour, il n’ya aucune preuve pour l’entreprise du logiciel.

Cela étant dit, je crois que la conclusion analogue est valable: deux développeurs et un testeur sont plus productifs qu’un développeur et deux testeurs.

Si vous rencontrez des problèmes pour justifier deux développeurs coûteux assis devant un ordinateur sur la gestion, il y a beaucoup d’autres choses qui consortingbuent à la prévention des défauts, mais qui ne sont pas aussi visibles (et donc irritantes) pour la direction.

Quand je programme sur le bateau de mon ami, nous n’avons pas toujours le temps, car l’un de nous navigue pendant que l’autre code. Cependant, lorsque nous sums ancrés ou en eaux calmes, nous pouvons faire la programmation en paires et cela fonctionne très bien.

La programmation par paires ne double pas le coût – elle réduit de moitié la quantité de frappe. La saisie n’est pas une programmation. Compléter la fonctionnalité du logiciel est la programmation. C’est la résolution de problèmes. Vous ne pouvez pas simplement le mesurer en lignes de code tapées. Certains programmeurs utiliseront un meilleur algorithme pour qu’ils finissent par taper moins.

Comment définiriez-vous l’optimisation des ressources? Peut-être le temps total écoulé entre le début du codage et l’achèvement, la fonctionnalité de travail en direct?

Le coût de l’absence de couplage n’est pas souvent pris en compte correctement: le problème est que la plupart des gens ne mesurent pas le nombre de défauts ou le temps supplémentaire nécessaire pour réparer un travail qui n’a pas été effectué correctement. le temps pris pour “jeter le travail sur la clôture” en premier lieu.

Il y a quelques tentatives pour mesurer la productivité lors de l’parsing, mais malheureusement, il est un peu lié au “nombre de lignes de code fournies”, ce qui est une erreur.

Vous pourriez trouver cette étude pertinente: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

Pas question, mec! dans l’entreprise je travaille beaucoup de programmation en binôme! ça marche très vite et très efficacement! juste essayer! vous le valoriserez plus tard!

Le professeur Laurie Williams, de NC State, est la principale autorité du monde universitaire en ce qui concerne l’efficacité de la programmation par paires. Elle a réalisé de nombreuses études à ce sujet.

Si vous voulez le “mot officiel”, visitez sa liste de publication .

Son article: “Renforcer les arguments en matière de programmation par paires” est extrêmement célèbre.

Cela dépend des développeurs. Malheureusement, vous ne pouvez pas combiner deux développeurs et attendre des résultats rapides et de grande qualité. Tout le monde n’est pas à la recherche d’une programmation appariée ou même découpée pour travailler dans un environnement de développement agile. Je pense que deux choses à propos de la programmation appariée en valent la peine: (1) formation croisée entre développeurs; et (2) évaluations par les pairs en temps réel. La formation croisée aidera à renforcer les compétences de l’équipe dans son ensemble et les évaluations par les pairs en temps réel peuvent éliminer le besoin d’évaluations formelles par les pairs. Au fil des ans, j’ai appris plus de mes pairs que jamais au cours d’une formation technique.

Si vous n’êtes pas une très petite boutique, vous payez probablement déjà les salaires de deux programmeurs. La programmation par paires est juste un moyen (théorique) d’obtenir plus de logiciels de débogage et de travail sur ces deux en même temps.

Ce n’est pas une chose en noir et blanc ou une solution miracle, le concept de programmation par paires.

La programmation en binôme est généralement extrêmement efficace pour diverses raisons, mais bien faite, c’est aussi très fatiguant (à mon avis, de toute façon), ce qui signifie qu’une bonne paire peut combiner quelques heures par jour au maximum. Cela devrait être encouragé, bien sûr, mais pas obligatoire et surtout pas obligatoire à 100% parce que cela semble difficile à gérer (avec une efficacité soutenue et aucune bière de toute façon).

La programmation par paires n’est donc qu’une façon d’aborder un problème, et j’ai du mal à l’examiner du sharepoint vue de la question. Ce n’est pas comme si vous deviez embaucher deux fois plus de développeurs pour cela. C’est comme se demander s’il vaut la peine d’engager un message garçon / fille pour que deux employés du même département se parlent… alors que la solution évidente est de les faire parler directement sans un messager supplémentaire.

Je n’ai pas fait les statistiques – et je soupçonne que vous auriez du mal à faire une étude statistiquement valable – mais gardez à l’esprit l’objective ostensible de produire un code fonctionnel et sans erreur, pas seulement une quantité de code. Une bonne paire devrait être capable de créer au moins autant de code correct que deux programmeurs travaillant séparément.