KPIs Game (3/3) : Les KPIs de qualité

Retrouvez les deux premières parties de cet article sur les KPIs d’équipe :
- KPI Game (1/3) : les KPIs d’efficacité.

- KPI Game (2/3) : les KPIs de prédictibilité

Cette troisième et dernière partie aborde les KPIs de qualité.

Les KPIs de qualité

Les KPIs dits de « qualité » évaluent la qualité des livrables et permettent à l’équipe d’identifier les action à mettre en oeuvre pour livrer des incréments toujours plus qualitatifs dans les délais impartis.

La couverture de code

Comment le calculer ? Les tests unitaires permettent de « couvrir » le code réalisé dans l’incrément. La couverture de code correspond au pourcentage de code couvert par les tests unitaires.
Pourquoi le suivre ? L’équipe Scrum s’engage à chaque sprint à livrer des incréments de qualité. Une des méthodes pour assurer de livrer ce qui est attendu sans générer de régressions est d’ajouter des tests unitaires à chaque développement. La couverture de code correspond donc à l’ajout de tests unitaires qui « couvrent » le code pour s’assurer que le code correspond à l’attendu et qu’il n’y a pas de régression (puisque les tests unitaires sont lancés à chaque build du code ☺️).

Comment l’analyser ? La couverture de code est une solution pour détecter facilement et le plus tôt possible des bugs et/ou régression. **Un taux de couverture de code élevé ne garantit donc pas une qualité de code élevée mais indique néanmoins que l’équipe a fourni les efforts nécessaires pour avoir le moins de chance possible d’avoir des bugs en production. La recommandation est d’avoir une couverture de code d’au moins 80%.

Anos vs Done

Comment le calculer ? Le KPI « Anos vs Done » se calcule en identifiant le nombre moyen d’anomalies générées par tâche réalisée. Concrètement, si à la fin d’un sprint nous détectons 2 bugs liés à l’US 1, 3 bugs liés à l’US 2 et 1 bug lié à l’US 3, alors nous avons un nombre moyen d’anomalies de 2 bugs par US terminées.
Pourquoi le suivre ? En suivant ce KPI sur plusieurs sprints cela permet d’identifier un éventuel problème de qualité des livrables. D’autre part, cela permet d’améliorer les prévisions et l’estimation des dates d’atterrissage : imaginons qu’il reste 20 US dans le backlog, et vous avez un nombre moyen de bugs par US done de 2, vous pouvez déjà envisager qu’il y aura 20 US + environ 40 bugs à traiter pour terminer le backlog.

Comment l’analyser ? Un nombre élevée d’anomalies générées par tâche réalisée indique une qualité de livrable à améliorer et un risque important sur la capacité de l’équipe à tenir ses engagements. Les questions possibles à se poser : vos critères d’acceptances sont-ils bien identifiés pour chaque US ? Votre feature est-elle assez découpée ? Avez-vous une bonne couverture de code ? etc

L'indicateur de confiance

Comment le calculer ? Aussi simplement qu’un ROTI. Cela se fait généralement avec votre équipe en fin de planification d’un sprint, d’une release, d’un incrément de programme (SAFe). Pour cela, chaque participant évalue, à main levée, son degré de confiance dans la capacité de l’équipe à atteindre les objectifs fixés. Le vote doit prendre en compte les risques, les dépendances et autres adhérences.
1 : Je ne suis pas confiant

2 : Je suis peu confiant

3 : Je suis assez/plutôt confiant

4 : Je suis confiant

5 : Je suis très confiant

Pourquoi le suivre ? Premièrement, cet indicateur permet de statuer en fin de planification si l’ensemble de l’équipe est confiante sur l’engagement pris pour l’itération (sprint ou release, ou autres types de planification). Suivre cet indicateur permet d’anticiper des risques et prendre des actions concrètes pour lever les doutes et rassurer l’équipe.

Si le taux de confiance est n’est pas satisfaisant en fin de planification (≥ à 4), il est primordial de continuer l’atelier (immédiatement s’il reste du temps, ou bien en planifiant une suite très rapidement) afin de comprendre le vote et d’ajuster l’engagement ou l’objectif pour atteindre un niveau de confiance correct.

Comment l’analyser ? Si une équipe est toujours confiante sur l’engagement pris mais pourtant n’arrive jamais à atteindre les objectifs fixés, cela peut révéler une mauvaise présentation ou compréhension des US et donc une mauvaise estimation, des risques non identifiés en amont, etc.

À l’inverse, une équipe toujours très peu confiante quant à l’engagement pris mais qui pourtant parvient toujours à les atteindre peut révéler différentes choses :

- Une équipe qui manque de confiance en elle et se sous-estime (manque de valorisation ? de reconnaissance ? subit beaucoup de pression ?)

- Une équipe surmenée, exemple : l’équipe travaille en dehors des heures de travail pour arriver tant bien que mal à atteindre les objectifs fixés.

- Etc.

‍