Indicateurs
Bien que le Scrum et l'eXtreme Programming ne définissent pas de liste d'indicateurs à mesurer pour analyser la santé de l'équipe, il est important d'établir une liste qui peut être optimisée régulièrement afin d'obtenir un résultat précis facilement.
Voici quelques exemples d'indicateurs :
Vélocité de l'équipe
Si la vélocité baisse alors peut-être que l'équipe passe trop de temps sur du bugfix ou chore.
Volatilité de la vélocité
La volatilité de la vélocité indique la déviance de la vélocité par rapport à la vélocité moyenne.
Si la vélocité n'est pas stable alors il y a probablement un problème dans la façon dont l'effort est estimé ou alors les User Stories sont de taille trop importante.
Gaspillage
Mesurez l'intérêt et le temps perdu dans les tâches "ingrates" ou celles qui semblent inutiles. Exemples : tâches manuelles, pointage, paperwork etc...
Cela peut révéler un "process" inutile ou l'absence d'outils adaptés.
Negativity Bias : Une heure sur une tâche "ingrate" est plus coûteuse qu'une heure sur une tâche utile.
Moral de l'équipe
Pensez à mesurer l'humeur ou encore mieux le moral de l'équipe.
Cela peut se faire en proposant à chaque membre de répondre à ces questions à chaque Sprint Retrospective par exemple :
Je me sens adapté à mon équipe ;
Je suis fier du travail que je produis au sein de mon équipe ;
Je suis enthousiaste du travail que je dois produire ;
Notre travail a du sens.
https://blog.agilistic.nl/agile-teams-dont-use-happiness-metrics-measure-team-morale/
Evitez le Niko Niko Calendar. Ce dernier peut nuire au moral de l'équipe.
https://www.tinypulse.com/blog/sk-niko-niko-calendar-workplace-morale
Isolement au sein de l'équipe
Vos développeurs travaillent-ils avec des boucliers d’interaction sociale (A.K.A. casques audios) ?
Entendez-vous du vocabulaire possessif au sein de l’équipe tel que “ton outil ne marche plus”; “mon code”; “j’ai fini ma story”; “ah non ! je ne toucherai pas à ça, c’est machin qui s’en occupe”; ”ce code/cette application/cet outil, c’est mon bébé !” 😱
L’absence de certaines personnes clées peut-elle aboutir au blocage ou au ralentissement considérable de l’équipe ?
Votre équipe peut-elle survivre avec 50% de l’effectif ?
Est-ce que les développeurs sont capables de différencier le code qu’ils ont produits de celui des autres ?
Qualité du produit
Nombre de bugs et satisfaction du ou des client(s).
Code Smell
Qualité du code.
Last updated
