Mesurer la qualité logicielle : ne vous trompez pas de combat
Les chiffres, c’est bien : nos ressentis sont une chose, mais ces ressentis peuvent nous égarer. Alors, nous nous mettons en tête de mesurer la qualité logicielle. Vaste programme. Comment s’y prendre ? Quels indicateurs rechercher ?
Commençons par lister 2 ou 3 choses que nous serions bien inspirés de ne pas faire…
Ces indicateurs qui font plus de mal que de bien
Considérons le taux de couverture de tests unitaires : cet indicateur méconnaît le B-A-BA des stratégies de tests, à savoir utiliser différents types de tests pour déceler différents types de bugs. Vous pouvez mettre autant de tests unitaires que vous voulez, cela ne remplacera jamais un test d’intégration…
Donc ça part mal, mais ce n’est pas fini. Le problème de ce type d’indicateur focalisé sur les moyens, c’est qu’il dicte à l’équipe une manière de travailler. Pour des profils très juniors, cela sera peut-être rassurant, mais nombreux sont les profils séniors qui se sentiront déresponsabilisés – surtout quand l’indicateur n’a aucun sens, comme ici. Que voulez-vous au final ? Qu’il y ait des tests unitaires (output), ou bien qu’il n’y ait pas de bug (outcome) ?
Autrement dit, mieux vaudrait probablement être exigeant avec l’équipe en observant un indicateur tel que le nombre de bugs en production (quelque chose qui a de la valeur pour les utilisateurs et pour le business), et la responsabiliser en lui laissant le choix des moyens pour y parvenir (tendre vers 0). Bien sûr qu’il faudra des tests automatisés, et bien sûr qu’il faudra des tests unitaires. Mais il n’y a pas une seule bonne manière de faire les choses, et l’équipe de développement reste la mieux à même de faire un choix éclairé en la matière (quel équilibre entre tests unitaires/d’intégration/end-to-end, approche test-after/test-first/TDD ?)
Revenons aux mots. L’output désigne ce qui est directement produit : du code, des tests, de la documentation, des mises en production, etc. L’outcome désigne quant à lui les changements ou bénéfices réels générés par l’output, du point de vue des utilisateurs ou de l’organisation : une meilleure expérience utilisateur, l’acquisition de nouveaux clients, l’augmentation du chiffre d’affaires, du feedback utilisateur, la diminution de la dette technique etc.
Un indicateur relatif à l’output est particulièrement sujet à la Loi de Goodhart, selon laquelle « Lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure ». Si je décide de mesurer la productivité d’une équipe par le nombre de lignes de code qu’elle produit, chacun sait combien cela est absurde. Cela ne dit rien de l’intérêt des fonctionnalités livrées à l’utilisateur, rien de la qualité de code ni de la dette technique, rien. Alors, très vite, volontairement ou non, les développeurs se mettront à écrire le même code en revenant plus fréquemment à la ligne, et vous aurez créé un indicateur « pastèque », c’est-à-dire vert dehors mais rouge dedans.
Enfin, l’outcome est bien plus intéressant que l’output parce qu’il responsabilise l’équipe dans son ensemble, avec ses différents profils. Que signifierait avoir de très bons développements – bien modularisés, bien architecturés, bien testés, peu de dette technique – si les fonctionnalités étaient mal conçues ou, pire, si ces dernières ne répondaient pas aux vrais problèmes de vos utilisateurs ? Cela voudrait dire que vos développeurs travaillent pour rien, voire font consciemment des choses absurdes, faisant « juste ce qu’on [leur] a dit de faire ». Ce n’est clairement pas la mentalité que vous voulez. Vous souhaitez que chacun se sente concerné par la finalité métier et prête main forte à ses collègues quand il le faut, même en dehors de son attribution.
Quelques repères pour des indicateurs utiles
Mesurer la qualité logicielle est une vaste tâche, que je ne fais qu’effleurer dans cet article. Avant de la mesurer, il faut déjà pouvoir la définir, sujet sur lequel on peut aussi passer un peu de temps.
Concernant les indicateurs à proprement parler, voici cependant quelques recommandations :
-
Privilégiez la mesure d’un outcome à celle d’un output, comme nous venons de le voir extensivement ;
-
Veillez à ce que votre indicateur ne puisse pas être distordu de manière évidente, volontairement ou non (ici aussi, outcome > output) ;
-
Privilégiez des indicateurs qui responsabilisent l’équipe dans son ensemble, pas un sous-ensemble (éviter en particulier l’antagonisme PM/Dev) ;
-
Dans la mesure du possible, automatisez le calcul de l’indicateur, pour éviter les erreurs et pour faire en sorte qu’on le calcule encore 1 mois après…
-
Limiter le nombre d’indicateurs, maximum 5 (les doigts d’une main), afin que chacun puisse les retenir et qu’ils guident toute l’entreprise.
Voici quelques exemples d’indicateurs qui ont de bonnes chances de fonctionner :
-
Le Time to Market : temps écoulé entre l’idée et la première réalisation en production ;
-
Le Feature Adoption Rate, qui mesure la vitesse d’adoption d’une fonctionnalité par les utilisateurs ;
-
Le Production Bug Count, éventuellement pondéré en fonction de la criticité des bugs ;
-
Le Mean Time to Recovery, temps moyen de retour à la normale après incident.
Conclusion
Plus généralement, vous ne sauriez vous contenter de mesurer la qualité logicielle. Ce que vous voulez, c’est probablement aider vos équipes à progresser, en les formant, en favorisant la diffusion du savoir entre équipes, en proposant des bibliothèques de code partagées. Accompagnement et mesure sont l’avers et le revers d’une même pièce.
Enfin, si vous constatez des bugs en production, pensez Shift Left (le dernier mot à la mode) : plutôt que de courir après les bugs, demandez-vous comment et pourquoi ils sont apparus. [Spoiler Alert] La conception fonctionnelle est souvent en cause.