Une sorte de reconnaissance de groupe des efforts d'un membre de l'équipe peut être un facteur de motivation précieux, mais dans ce cas, il semble qu'il soit mal appliqué. Vous déclarez que le MVP est choisi par vote, mais il y a beaucoup de mentions de nombres de bugs corrigés par sprint. Il semble que votre temps ait une définition amusante de MVP - je suppose que la personne qui mérite le titre de "la plus précieuse" est la personne qui a ajouté le plus de valeur au logiciel dans ce sprint. Si un membre de l'équipe sélectionne des bogues qui peuvent être corrigés rapidement, les traverse le plus rapidement possible et provoque des bogues de régression et d'autres problèmes dans leur sillage, alors ils n'ajoutent pas de valeur, ils créent plus de travail pour quiconque a de les suivre pour identifier et résoudre ces problèmes.
Ma suggestion serait d'essayer d'entamer une discussion appropriée la prochaine fois que votre équipe aura l'un de ces votes. Ne vous contentez pas d'en faire un vote à main levée; parlez-en d'abord. Si quelqu'un semble gagner des votes sur la base du nombre de "correctifs" qu'ils ont faits, indiquez (avec tact) où ces correctifs ont provoqué des régressions, et suggérez que peut-être la personne qui a corrigé ces régressions soit nommée pour nettoyer d'autres personnes désordre. Si quelqu'un a passé tout le sprint à asservir un problème désagréable, signalez-le à l'équipe, soulignant le fait que bien que le nombre de correctifs de cette personne soit un, ils ont à eux seuls résolu un problème majeur avec votre logiciel - un problème qui était si méchant que personne d'autre ne voulait y toucher.
Choisir des correctifs faciles et les faire de manière précipitée ou au hasard n'est pas utile, donc les développeurs qui le font ne devraient probablement pas être considérés comme des candidats MVP. Lors de la sélection du nouveau MVP, oubliez tout sur l'équipe et les personnes qui s'y trouvent, et regardez le logiciel. Choisissez le changement le plus important dans ce logiciel depuis la dernière fois. Je veux dire célibataire ici; "pas autant de petits bugs" n'est pas un changement majeur. Un bug particulièrement flagrant a-t-il été corrigé? Une excellente nouvelle fonctionnalité a-t-elle été ajoutée? Une fois que vous avez identifié ce qu'est ce grand changement, demandez qui en est responsable. L'une de ces personnes est probablement votre véritable MVP. Si "pas autant de minuscules bogues" est la seule différence, alors et seulementalors le nombre de bogues est une mesure valide de MVP - et même dans ce cas, je regarderais le rapport des bogues corrigés aux bogues de régression causés. Chaque bug que quelqu'un cause en déduit au moins 1 de son décompte. En fait, je dirais plus de 1, car une mauvaise correction entraînera un bogue inconnu que vous devrez ensuite trouver, ce qui est pire qu'un bogue connu qui a déjà été trouvé. Un bogue connu nécessite des efforts de développement de la part du développeur; un bogue inconnu demande des efforts de contrôle qualité pour trouver, et des efforts de développement pour résoudre, et il y a alors le risque que le contrôle qualité le manque.
En théorie, si les développeurs réalisent que le chemin vers le prix est de résoudre moins de problèmes plus gros, ils viseront les plus difficiles, les plus complexes, les défauts de blocage. Cela les obligera parfois à se regrouper, soit parce qu'il n'y a pas assez de problèmes charnus pour contourner, soit parce que le problème est assez délicat pour nécessiter plus de paires d'yeux . Peut-être suggère que dans des cas comme celui-ci, le prix pourrait être partagé s'il n'est pas immédiatement clair lequel parmi un ensemble de personnes a fait plus de travail pour corriger un bogue - et rappelez-vous, travail fait! = Lignes de code écrites. Les développeurs le sauront probablement, mais vous avez dit que la direction est impliquée, et la direction ne comprend pas toujours ce point.
Et bon, si tout le reste échoue, oubliez le programme MVP. Parlez à vos collègues développeurs en dehors de la mêlée et montrez l'impact négatif que les récompenses MVP ont sur le logiciel. Voyez si vous pouvez les amener à l'ignorer ou à ne pas en faire un gros problème. Laissez le trophée dans un tiroir, dépensez le prix en argent sur une série de boissons pour l'équipe après le travail, utilisez le déjeuner gratuit pour obtenir quelque chose que vous pouvez partager, comme un tas de petits gâteaux. Agile est un système d'équipe; mettre en évidence les performances individuelles risque de confronter l'équipe. Unis, vous vous tenez, divisé, vous expédiez des logiciels remplis de bogues, après la date limite, en dépassant le budget.