Tous les articles de notre série “Mesurer l’agilité” :
- #1 Mesurer l’agilité : qu’est-ce que cela signifie ?
- #2 Mesurer l’agilité : une bonne idée ?
- #3 Mesurer l’agilité : quels pièges éviter ? (1)
- #4 Mesurer l’agilité : quels pièges éviter ? (2)
- #5 Mesurer l’agilité : que mesurer ? (1)
- #6 Mesurer l’agilité : que mesurer ? (2)
- #7 Mesurer l’agilité : le mot de la fin
Précédemment, dans la mesure de l’agilité…
Que peut-on mesurer pour se rendre compte de notre capacité à être plus agiles ? Et à quoi cela va-t-il nous servir ?
Dans le précédent article, nous avons parlé de trois indicateurs agiles : l’évolution de la valeur ajoutée perçue par les utilisateurs, l’évolution du temps de cycle et l’évolution du temps de traversée.
En voici trois supplémentaires.
#4 indicateur agile : L’évolution du nombre d’anomalies remontées
Visualiser l’évolution du nombre d’anomalies remontées peut nous aider à comprendre si le travail que nous fournissons en tant qu’équipe, programme ou organisation est conforme au niveau de qualité que nous souhaitons pour nos utilisateurs.
Que prendre en compte dans cet indicateur agile? Uniquement les anomalies remontées par les utilisateurs en production ? Également celles détectées par l’équipe, dont le Product Owner, lors de ses vérifications avant livraison ? Ou par la plateforme d’intégration continue, si du code vérolé a été poussé sans vérification préalable ? Il y a plusieurs écoles, à vous de voir où vous souhaitez placer le curseur.
Un code ou un processus n’est jamais dépourvu à 100% d’anomalies. Même les langages sur lesquels nos programmes sont basés sont en constante amélioration, pour des raisons de fonctionnalités ou de performances. L’introduction de nouveau code signifie l’introduction potentielle de nouvelles anomalies.
La question à se poser est : à quel point sommes-nous capables d’en produire le moins possible dans la durée, de façon à continuer à satisfaire nos utilisateurs et à ce que notre dette technique n’explose pas dans le temps ?
Pourquoi le mesurer ?
Une augmentation dans le temps de la quantité d’anomalies remontées peut induire une diminution de la qualité de notre production, ce qui nous fait perdre en agilité (moins bonne capacité à répondre au besoin utilisateur par exemple). Il est alors nécessaire de comprendre les causes racines de cette évolution. Puis, il est nécessaire de mettre en place les actions correctives adéquates.
Comment le mesurer ?
Cela pourrait être une mesure, une fois par période (semaine, mois, trimestre…), du nombre d’anomalies remontées sur cette dernière, et le traçage d’un graphique comme celui ci-dessus.
Comment l’améliorer ?
L’automatisation d’un certain nombre de tests (unitaires, d’intégration, fonctionnels…) peut permettre d’identifier le plus tôt possible les anomalies, et donc de les corriger avant qu’elles ne viennent perturber les utilisateurs.
#5 indicateur agile : L’évolution du taux de couverture du code
La couverture du code, dans une approche logicielle, est le pourcentage du code source du produit qui est exécuté par vos tests automatisés. Supposons que vous ayez 1000 lignes de code dans votre produit. Vos tests sont automatisés. Une fois exécutés, ils éprouvent 700 lignes de ce même code (laissant donc planer un doute sur le bon fonctionnement des 300 autres). Votre couverture du code sera de 70%.
Il s’agit d’un indicateur agile plus technique que les précédents. Mais même celui-ci pourrait être éventuellement adapté à des équipes non techniques. Comment ? On mesurera par exemple la proportion d’étapes dans un processus qui disposent de procédures de vérifications associées. Dans notre équipe RH : a-t-on bien une liste de contrôle pour l’étape de qualification ? Et pour l’étape d’entretien avec le candidat ?
Il s’agit également d’un indicateur agile peut-être plus controversé que les précédents, car plus facile à “truquer”. Pour améliorer le score, il suffit de rajouter des tests inutiles. Cela permet alors d’augmenter le score. Au lieu de réellement le faire de façon rationnelle dans une optique de réduction du nombre de cas non testés.
Mais si j’en parle, c’est que de façon très concrète, au sein des organisations de tailles diverses que j’ai accompagnées, j’ai vu un vrai lien entre la couverture du code et la capacité d’une équipe à être agile, à partir du moment où les tests sont rédigés en bonne intelligence, pour une bonne raison, et dans un ordre et une quantité pertinents.
Pourquoi le mesurer ?
Une meilleure couverture du code, c’est normalement une capacité accrue à détecter les anomalies dans le code. Et donc une réactivité accrue pour les corriger avant même que le code en défaut n’ait été poussé jusqu’au dépôt. C’est aussi, à terme, un temps moindre passé à retester toujours les mêmes procédures. Et donc un temps plus important passé à créer de la valeur nouvelle pour les utilisateurs. Une équipe agile devrait donc viser une amélioration de son taux de couverture du code jusqu’à un certain point, et un maintien à long terme de ce taux à un niveau qu’ils jugent satisfaisant.
Comment le mesurer ?
Le taux de couverture du code est mesuré par des outils dédiés, qui varient généralement en fonction de la technologie sur laquelle est basée votre produit.
Comment l’améliorer ?
Il n’y a pas de magie : si le taux de couverture paraît insuffisant, il faut sans doute passer plus de temps à implémenter les tests couvrant votre code, et donc généralement moins de temps à développer de nouvelles fonctionnalités. C’est un juste équilibre à trouver. Vous n’avez sans doute pas besoin de viser une couverture de 100%. En revanche, il faut faire en sorte de prioriser l’implémentation des tests pour les pans les plus critiques du produit, et faire en sorte que le taux de couverture augmente ou reste stable dans le temps. En effet, au fur et à mesure que vous développerez de nouvelles fonctionnalités, le nombre de lignes de code devrait augmenter : si le taux de couverture diminue, c’est peut-être le signe qu’il n’y a pas de tests implémentés pour ces nouvelles fonctionnalités, ce qui est un problème.
#6 Indicateur agile : L’évolution de la satisfaction des utilisateurs et des collaborateurs
L’agilité, c’est notamment la régularité et l’amélioration continue. Et contrairement l’interprétation que certains peuvent faire de certains termes, comme le fameux “sprint” de Scrum, adopter une approche agile n’est pas synonyme d’aller le plus vite possible. Mais garder un rythme soutenable dans le temps, idéalement “indéfiniment” si l’on se réfère aux principes agiles (n°8).
À ce titre, il est important de prendre régulièrement “la température” des humains qui nous accompagnent dans cette démarche. Il y a les utilisateurs d’une part. Mais il y a aussi les personnes qui travaillent pour ces utilisateurs : les développeurs, testeurs, graphistes, facilitateurs, Product Owners, managers, etc. Et cela reste évidemment vrai dans une démarche qui n’a rien à voir avec du développement logiciel.
Pourquoi le mesurer ?
Une diminution dans le temps de cette satisfaction est le signal que quelque chose ne va pas dans notre façon de fonctionner. Cela permet alors de prendre des mesures avant que la situation ne se dégrade trop, jusqu’à arriver parfois à un point de non-retour (syndrome d’épuisement professionnel, démissions…).
Comment le mesurer ?
Il y a, là aussi, plusieurs pistes. Le modèle du Squad Health Check, popularisé par Henrik Kniberg, permet aux membres des équipes de s’exprimer collectivement sur un certain nombre de points et de donner leur satisfaction sur chacun. Le calendrier Niko Niko du Management 3.0 est peut-être moins intéressant de ce point de vue. Il est cependant plus rapide à mettre en œuvre. Pour ce qui est de la satisfaction des utilisateurs, un sondage simple avec une note, comme par exemple le Net Promoter Score (NPS), permet déjà d’avoir un résultat.
Comment l’améliorer ?
Il n’y a pas de magie : si le score ne vous paraît pas suffisamment bon, il faut écouter les retours qui ont été faits et se remonter les manches pour les mettre en application. C’est justement là qu’un exercice comme le Squad Health Check, plus collectif et basé sur l’échange, va être plus intéressant qu’un Niko Niko. Attention : écouter et ne pas agir ne suffit pas.
L’évolution, signe de la direction prise
Les six indicateurs agiles qui vous ont été présentés dans cet article et le précédent ont tous été présentés comme “l’évolution de quelque chose” (temps de traversée, nombre d’anomalies, etc.). Pourquoi ?
Un nombre, pris hors de son contexte, peut vouloir tout ou rien dire. Dans une approche d’amélioration, ce qui devrait nous intéresser est plutôt de savoir à quel point nous sommes capables de progresser dans la bonne direction, en agissant afin de permettre la diminution de la valeur de certains indicateurs, et l’augmentation de la valeur de certains autres.
Si vous avez une satisfaction utilisateurs de 7 / 10, cela peut être une note acceptable. Si, sur les douze mois précédents, la satisfaction moyenne de vos utilisateurs était de 5 / 10, alors bravo, vous avez bien progressé et il faut continuer dans cette voie. Mais si cette même moyenne sur les douze derniers mois était de 9,7 / 10, qu’a-t-il bien pu se passer depuis ? Et que devrions-nous changer pour endiguer cette dégringolade ?
Vous êtes peut-être lancés dans une démarche produit ou service qui durera un, deux, cinq, dix ans. Ne soyez pas trop impatient. Ne faites pas confiance aux chiffres tels quels. Cherchez à vous améliorer dans une direction plutôt que vers un objectif bien précis. Visualiser l’évolution des indicateurs est ce qui vous permettra de prendre la bonne décision au bon moment. Vous ajouterez un contexte bienvenu que le chiffre seul ne donne pas.
La suite et fin au prochain épisode
Comment les choses ont-elles évolué chez Scholesoft, l’entreprise de Paul ? Quels résultats ont été obtenus ? Restez connectés pour être mis au courant des prochains articles sur le sujet.
