Vous utilisez des résultats de construction continus dans le cadre de mesures d'évaluation des performances? [fermé]

Mon patron prévoit d'utiliser les métriques de notre build continu (construit et exécute des tests sur chaque commit) dans le cadre de nos évaluations de performances (dans notre métrique «qualité»). Cela me semble VRAIMENT une mauvaise idée, mais j'aimerais savoir si quelqu'un a étudié ou vu cela avant.

Je pense que nos développeurs ne feront pas autant de tests qu'ils le feraient autrement, de peur que les tests échouent. Je pense qu'il transforme un précieux outil de développement en un bâton pour battre les développeurs.

Le contre-argument évident est qu'il encouragera les gens à être plus prudents avant de s'engager, et donc à améliorer la qualité.

Suis-je hors de la base ici? Veuillez laisser de côté la question de savoir si nous devrions ou non procéder à des évaluations du rendement - cela a été répondu ailleurs.

continuous-integration

— Michael Kohne
source

Tout système pouvant être joué est une entrée horrible pour une évaluation de performance.

— Steve Jackson

Tout le monde a la possibilité de ne pas tester?

— JeffO

@Steve, Et les "systèmes" qui ne peuvent pas être joués vous donnent une toute petite vue étroite de l'image plus grande. Pour suivre avec précision les performances, il faudrait travailler les jambes.

— maple_shaft

Notez que certaines choses fonctionnent bien sur les machines des développeurs, mais échouent sur le serveur de build (une dépendance accidentelle sur un pot externe, une mauvaise façon d'utiliser / et \ sur les boîtes Linux, etc.). La principale raison du serveur de build est d' attraper ces choses, de ne harceler personne pour ne pas les avoir testées en premier. En d'autres termes, c'est une mauvaise idée.

Suivi: Après avoir commencé à le faire, j'ai constaté que le plus gros problème n'avait rien à voir avec les autres ingénieurs et la volonté d'écrire les tests appropriés, mais plutôt avec le fait que nos tests existants étaient VRAIMENT instables, donc chaque commit avait une chance assez grande de briser sans faute de la personne qui commet. Ce facteur a atténué l'enthousiasme de chacun pour les tests bien plus que les effets de l'évaluation des performances.

— Michael Kohne

Réponses:

Les évaluations de performances sont correctes, mais qu'en est-il des mesures utiles telles que:

Pourcentage de couverture des tests unitaires sur les fonctionnalités
Capacité à respecter les délais
Documentation claire et concise
Suivez les conventions de codage appropriées
Communique bien avec les autres
Capacité à transformer les exigences et les user stories en tâches

Ce sont tous de bons moyens de mesurer les performances, mais les problèmes que la direction semble avoir avec eux sont qu'ils nécessitent en fait ... ummm .. eh bien vous savez ... DU TRAVAIL RÉEL de leur part.

Malheureusement, la plupart des dirigeants ont l’attitude suivante: «Au diable, je veux juger mes employés sur des mesures qui ne me demandent pas réellement de suivre ce qu’ils font.»

— maple_shaft
source

+1 pour fournir de bons choix de ce que les mesures sont utiles.

— David Ruttka

Jouer le système ici est très probable, à mon avis, et votre patron doit trouver des moyens d'empêcher que cela ne devienne la réalité. L'autre cas que vous n'avez pas mentionné est celui où les développeurs s'engagent des tonnes de fois pour qu'il y ait ce flot de check-ins où le nombre de modifications est relativement faible comme s'il y avait une partie de la revue où le nombre de builds était utilisé. c'est là que cela devient un nouvel outil qui pourrait être mal utilisé assez facilement. Je pense aux check-ins où quelque chose est renommé ou l'espace blanc est changé est un check-in et compte comme une certaine forme de productivité serait la vue pédante.

— JB King
source