Comment démontrez-vous les performances dans des environnements de programmation par paires?

Des évaluations de performances ont été faites récemment dans mon travail et j'ai été placé dans une position intéressante. Notre équipe fait beaucoup de programmation de paires, ce qui a tendance à faire la moyenne des différences de compétences entre les membres de l'équipe (surtout si l'on considère la rotation des paires). En règle générale, lorsque vous effectuez des évaluations des performances, vous revenez sur le travail que vous avez fait, et vous démontrez ce que vous avez accompli, et comment vous avez dépassé les attentes pour tenter de négocier une augmentation ou d'autres avantages.

Comment démontrez-vous (ou même mesurez-vous) la performance individuelle dans un environnement comme celui-ci?

inclure la valeur que vous avez ajoutée à la programmation des paires dans l'évaluation des performances - avez-vous aidé l'autre programmeur à apprendre des choses utiles? (et vice-versa, avez-vous écouté ses sages conseils et bien coopéré?)

une évaluation des performances ne doit pas être une compétition, elle doit être une évaluation de coaching par rapport à vos objectifs personnels (qui sont probablement en ligne avec les objectifs de l'entreprise et mutuellement convenus au début de l'année; sinon c'est juste arbitraire)

Il serait difficile de prouver scientifiquement un avantage de performance par rapport à l'autre.

Votre hypothèse est que la programmation par paire augmente les performances du développeur et améliore la qualité. Votre test impliquera de donner à une paire un ensemble d'exigences limitées à une architecture spécifique et de les faire implémenter.

Votre contrôle dans ce cas est que vous donnez les mêmes exigences à un développeur unique de statut, de compétence et d'expérience égaux (comme jugé objectivement par ses pairs) et également contraint au sein de la même architecture.

Pour vérifier votre hypothèse de performance temporelle, les programmeurs de paires doivent terminer leur travail en moins de la moitié du temps en tant que contrôle. Pour vérifier votre hypothèse sur la qualité, vous devez faire réviser la paire d'expérience et le code de contrôle par un tiers objectif, et demander à un groupe d'AQ objectif de tester les résultats des deux groupes sans leur dire quelle équipe a produit quoi. Le groupe de programmation paire doit avoir un meilleur code et moins de bogues.

Ce n'est pas une expérience parfaite mais je serais fasciné d'entendre si quelqu'un a tenté quelque chose de similaire.

En plus de cela, je ne vois pas comment vous pouvez prouver en fait que la programmation par paires est supérieure à un seul programmeur sur une fonctionnalité donnée.

Dans vos mesures de performance, appelez séparément 1) la croissance et le développement individuels et 2) le mentorat et le soutien par les pairs. Permettez à chaque employé de s'auto-évaluer et d'intégrer les commentaires de son responsable. Si cela a du sens dans la culture de votre entreprise, envisagez des évaluations par des pairs ou des témoignages.

Si cela est fait correctement, l'employé qui tire le plus de valeur pédagogique d'un jumelage est récompensé pour sa capacité à long terme à contribuer à l'équipe, et l'employé qui aide à les mettre au courant est récompensé pour le transfert de connaissances et d'expérience. Les gens qui se trouvent quelque part au milieu (apprendre de nouveaux domaines au lieu de simplement passer du junior au senior) sont reconnus pour les deux extrémités de l'équation.

Dans la pratique, l'évaluation des performances individuelles est délicate dans le meilleur des cas. C'est assez difficile de le faire sans créer de ressentiment ou de compétition. Mais si vous évaluez la contribution individuelle à l'équipe et que vous appréciez à la fois l'apprentissage et l'enseignement, il y a une chance de le faire fonctionner avec un peu moins de friction.

Les paires changent-elles souvent? Si oui, vous pouvez utiliser des avis anonymes pour trouver une jauge. Par exemple, si la personne A dit que B a fait 60% du travail, la personne C a dit que la personne B a fait 30% du travail et que la personne D a dit que la personne B a fait 90% du travail, vous pouvez faire la moyenne de cela à la personne B faisant 60% du travail. Si le travail que la personne B a accompli dans ses paires a un facteur relatif de 100 points, alors la personne B a fait 60 points de travail!

Cependant, ce n'est (nulle part près) parfait. Les gens sont susceptibles de se donner plus de crédit qu'ils n'en accordent à l'autre personne, vous devrez donc peut-être en tenir compte dans le calcul. Cela pourrait également conduire à un environnement où les paires se méfient l'une de l'autre. Le calcul peut également être modifié par une personne qui n'aime pas la personne avec laquelle elle travaille, etc.

Je dis que si deux d'entre nous ont travaillé ensemble pour créer X, alors nous obtenons tous les deux le mérite de l'avoir terminé et déployé. Là où vous pourriez avoir un problème, c'est quand une partie d'une paire n'a pas fonctionné du tout. Dans ce cas, le gestionnaire aurait dû en être informé tout au long et devrait donc utiliser ces commentaires lors du remplissage de son commentaire à l'évaluation des performances.

Vous vous trouvez dans la situation exacte que mon professeur nous fait suivre dans notre programme de développement de jeux. Nous sommes jumelés (2, 3 ou 4 personnes selon la taille de la classe et la taille du projet) et à la fin on nous dit d'évaluer chaque membre de l'équipe et nous-mêmes par rapport au projet et quel travail a été fait ainsi que les projets des autres équipes dans leur ensemble. Une note est établie sur la base de ces évaluations.

Pendant la formation de l'équipe, l'enseignant placerait délibérément un programmeur fort et un programmeur faible ensemble en espérant qu'ils travailleraient les uns sur les autres et / ou s'aideraient, mais 99% du temps le programmeur faible passerait à côté et ferait très peu de travail à aucun aucune idée de ce qu'ils font (ce sont les cours avancés, c'est très frustrant).

Les évaluations sont censées être privées, mais disons simplement qu'il y a quelques personnes avec lesquelles tout le monde refuse de travailler.

La programmation par paires signifie qu'une personne pense quoi et comment quelque chose doit être fait, et l'autre joue un singe de codage. Puis à un moment donné, ils changent (l'un s'ennuie, se fatigue, etc.). C'est bien, car les deux ne sont pas interrompus dans leurs activités.

Certaines personnes le considèrent également comme "la révision du code des stéroïdes". Vous obtenez un code révisé, ce qui devrait signifier une meilleure qualité.

Bonne question. Ce qui est important, ce n'est pas simplement ce que vous contribuez, mais la façon dont vos pairs voient votre contribution. Demandez-leur leurs commentaires sincères car ce sont ces commentaires qui vous aident à être un meilleur «peu importe» . Sérieusement, il est important que votre pair comprenne votre contribution et qu'il ne la comprenne que lorsqu'il a acquis une bonne partie de ses connaissances lors de son jumelage avec vous. Bon codage, partage et apprentissage, ce qui se traduit par de bons gains.

L'inconvénient de la programmation par paires est que la productivité du programmeur le plus expérimenté est limitée à la productivité du programmeur le moins expérimenté, à court et moyen terme. À long terme, l'expérience et la productivité sont augmentées chez le développeur junior.