Le programmation en binôme dans l'Agile nécessite que nous doublions le salaire versé à un programmeur individuel. Bien sûr, avec une telle approche, la qualité du code est bien meilleure, les bugs sont trouvés beaucoup plus tôt, etc., mais est-ce encore valable d'investir autant d'argent? Peut-être devrions-nous payer le salaire du 2ème développeur aux quelques testeurs (ces derniers sont généralement beaucoup moins chers que le programmeur qualifié)? Est-ce que quelqu'un a une expérience avec une telle comparaison?
Réponses
Trop de publicités?Comment savez-vous que vos programmeurs non appariés sont plus efficaces ? Je pense parfois que le solo/pairé est comparable à la vieille fable du lièvre et de la tortue.
L'appariement ne dérive pas vers des jours de travail contre-productif. Je ne sais pas combien de fois j'ai vu des développeurs passer des semaines à travailler sur des choses qui se révèlent plus tard être remplacées par quelque chose de beaucoup plus simple. Le programmeur seul "dans la zone" fait souvent des choses stupides. Il est juste trop facile de produire trop de code, quand ce que vous voulez c'est plus d'impact avec moins de code.
Et à la postérité, quand la poussière retombe, vous trouvez des centaines, voire des milliers de lignes de code qui auraient pu ne pas être écrites parce que quelqu'un ne connaissait pas la bibliothèque X ou la technique Y. L'appariement améliore ce problème, mais ne le supprime pas. Cela encourage à la fois les individus et le duo à faire plus de recherche avant de plonger dans une euphorie de code sans réflexion.
J'aimerais pouvoir faire plus d'appariement....
Nous utilisons cette approche dans notre entreprise, mais seulement pour les tâches difficiles ou lorsque vous n'êtes pas sûr de quelque chose sur lequel quelqu'un d'autre a déjà travaillé, ce qui, selon moi, fonctionne très bien. Cela évite de rester coincé dans une routine et permet de partager des idées avec d'autres personnes si nécessaire tout en étant capable de travailler de manière indépendante pour la plupart des tâches simples.
Je crois également que c'est plus bénéfique qu'une revue de code, qui est une autre pratique que nous faisons là où je travaille. Il est souvent difficile de comprendre pleinement ce qui se passe lors d'une revue de code sans fournir un contexte significatif, moment où vous n'avez pas toujours le temps de réfléchir à tous les détails. La programmation en binôme vous donne ce contexte dès le départ et vous permet de passer plus de temps à réfléchir aux cas particuliers qui peuvent poser problème ou non.
Bien que je sois d'accord avec la plupart des réponses jusqu'à présent sur le fait que la programmation en binôme est une bonne chose, je vais jouer le rôle de l'avocat du diable et soutenir que cela n'a pas toujours de sens.
Quand vous travaillez en binôme, vous n'obtenez pas un programmeur qui a deux fois plus de cerveau. Vous obtenez un programmeur qui est l'union de vos deux cerveaux. Donc, fondamentalement, chaque fois que je fais une erreur et que mon partenaire la corrige ou trouve une meilleure solution, c'est un avantage. Cependant, chaque fois que j'écris le bon code seul, c'est une perte d'argent car mon partenaire n'était pas nécessaire.
En gros, vous devez évaluer le code sur lequel vous travaillez. Les tâches simples ne valent généralement pas l'argent dépensé pour payer quelqu'un juste pour vérifier si vous avez bien écrit votre boucle for. Cependant, à un certain seuil, les tâches sont suffisamment compliquées pour rendre le retour sur investissement de la programmation en binôme justifiable.
Cela ne signifie pas doubler le coût si cela prend moins de la moitié du temps qu'il aurait fallu avec un seul développeur. Je pense que sur des tâches difficiles ou de bas niveau, cela serait utile. Je trouve que cela en vaut la peine car vous avez quelqu'un pour dire "non, ne fais pas ÇA !" bien avant que cela se retrouve dans le code de production où cela vous coûtera VRAIMENT du temps et de l'argent.
J'ai écrit des systèmes d'exploitation et des choses de cette nature où il était inestimable qu'il y ait quelqu'un assis à côté de moi pour vérifier ma logique.