Métriques et analyses
L’un des principes du Manifeste Agile définit « le logiciel fonctionnel comme la principale mesure d’avancement ». Ce qui semble à nouveau simple se révèle souvent mal compris dans toute son ampleur. Pourquoi le logiciel fonctionnel est-il en réalité la principale mesure d’avancement pour le développement agile ?
Tout d’abord, il faut clarifier ce qui caractérise un logiciel fonctionnel. Pour rester dans le cadre, nous le définissons selon trois critères centraux :
- Le logiciel ne contient pas d’erreurs qui entravent le travail
- Le logiciel fonctionne avec le niveau de performance requis par le travail à effectuer
- Le logiciel apporte une valeur ajoutée réelle et mesurable à l’utilisateur
Pour rendre ces critères mesurables, il existe de nombreux indicateurs de progrès possibles. En voici quelques exemples :
- Tickets / tâches terminés
- Points d’histoire terminés
- Temps comptabilisés
- Durée du projet
- Nombre de réunions tenues
- Versions logicielles livrées
Cela semble bien, n’est-ce pas ? Ce sont tous des critères mesurables qui peuvent être enregistrés et évalués. Les tickets terminés indiquent combien de nouvelles fonctionnalités le client a reçues. Les temps comptabilisés révèlent la quantité de travail déjà effectuée sur un projet. Plus un projet dure longtemps, plus les progrès sont visibles. Il en va de même pour les réunions, car plus de réunions clarifient potentiellement plus de questions que peu de réunions. Le nombre de versions logicielles livrées est presque analogue au nombre de tickets terminés.
Percevez-vous déjà le ton ironique ? Nous, les humains, avons tendance à créer avec amour et beaucoup d’efforts des métriques, des analyses et des tableaux de bord. Nous remettons rarement en question si tout cela a encore un lien de causalité. Mais comment mesure-t-on exactement un logiciel fonctionnel ? Certes, le nombre de tâches terminées peut être un très bon indicateur de succès. Cependant, il faudrait également examiner combien de tâches terminées apportent une réelle valeur ajoutée au client et à l’utilisateur, ou combien ont été mises en œuvre sans erreur, c’est-à-dire s’il s’agit vraiment d’un logiciel fonctionnel.
Je résume : les métriques sont formidables, cependant nous devrions passer à une remise en question critique de la causalité de nos métriques, afin de ne pas obtenir au final une image d’ensemble trompeuse ou même de prendre les mauvaises contre-mesures.
Rythme constant
Un bon moment pour remettre en question ses propres évaluations est toujours lorsqu’on constate une amélioration. Pourquoi ? Eh bien, supposons qu’une équipe accomplisse en moyenne 10 tâches par semaine (pour tous ceux qui reconnaissent déjà que l’unité de mesure « tâche » n’est pas du tout appropriée : c’est vrai, j’y reviendrai tout de suite).
Après quelques semaines, l’équipe accomplit d’abord 11, puis 12 tâches par semaine. La performance a-t-elle maintenant augmenté ? Ou l’équipe a-t-elle peut-être simplement commencé à estimer généralement des tâches plus petites ? Seules des petites tâches sont-elles survenues ? Ou peut-être la qualité du travail a-t-elle baissé et c’est seulement pour cela que plus de tickets sont traités ? L’évaluation précise est difficile et probablement même impossible.
Cela a entre autres les raisons suivantes :
- L’unité de mesure « tâche » ne dit rien sur l’effort, le risque ou la complexité de la tâche.
- Une baisse de la qualité ne se fait parfois sentir que des semaines plus tard, surtout lorsque le logiciel n’est pas livré et testé en continu. D’ici là, la performance de l’équipe est déjà considérée comme ayant augmenté.
- Il n’y a aucun événement qui justifierait une performance accrue. Lorsque la performance diminue, on recherche immédiatement les causes. Pourquoi ne pas le faire lorsque la performance augmente ?
Le Manifeste Agile stipule dans ses principes que les équipes agiles devraient être capables de maintenir une performance constante sur une longue période. J’ajouterais une petite remarque : la performance peut également s’améliorer, mais il devrait y avoir des raisons tangibles pour cela. Par exemple, un meilleur environnement de développement ou de meilleurs outils pour déployer le logiciel peuvent en faire partie. Si une amélioration n’a (à première vue) aucune cause, il faut être extrêmement vigilant pour s’assurer que la qualité du travail n’a pas diminué. Cela se produit souvent involontairement. Comme toujours, nous ne cherchons pas de coupables, mais des causes.
En introduction, j’avais mentionné que l’unité « Task » n’est pas optimale. Entre-temps, nous avons compris que cette unité n’est pas seulement non optimale pour diverses raisons, mais qu’elle est même fondamentalement erronée. Il peut y avoir d’autres domaines où cette unité de mesure fonctionne très bien, mais le développement logiciel agile n’en fait pas partie.
Cependant, j’aimerais maintenant effectuer une petite digression et passer des métriques, des analyses, des relations causales et non causales à un domaine plus technique.
Excellence technique
Nous, les développeurs, avons tendance à être sujets aux vulnérabilités suivantes : « Premature Optimiziation » et « Over Engineering ». La première désigne la tendance à optimiser trop tôt des choses qui n’ont pas besoin d’être optimisées et qui pourraient même être supprimées de toute façon. L’Over Engineering est un processus naturel dans la vie d’un développeur, où il livre une solution si techniquement excellente et raffinée, abstraite et générique, que le temps nécessaire pour une solution fonctionnelle ET techniquement excellente aurait été beaucoup plus court que pour celle livrée.
Bien que le Manifeste Agile exige explicitement l’excellence technique dans ses principes, il souligne également que le travail non effectué devrait être maximisé, précisément pour limiter les phénomènes mentionnés.
La tâche du développeur est de mettre en œuvre les exigences des clients de manière aussi précise et qualitative que possible, sans se perdre dans des détails inutiles et n’apportant aucune valeur ajoutée.
La tâche d’un bon Product Owner, SCRUM Master ou, comme on l’appelle parfois encore, chef de projet, est de veiller à ce qu’une équipe ne se perde pas dans les détails tout en insistant sur les revues de code, les tests unitaires, etc.
À mon avis, ces deux points du Manifeste Agile, « l’excellence technique » et « la simplicité de la solution », devraient être résumés. Quelque chose comme ceci :
« Une attention constante pour atteindre l’excellence technique et un bon design avec un effort minimal »
Métriques fonctionnelles
Quelles sont donc les bonnes métriques pour mesurer les équipes agiles ? Eh bien, pour cela, il faut réfléchir à ce qui doit être mesuré exactement. S’il s’agit de surveiller un rythme constant, la vélocité est une métrique éprouvée. Elle mesure le nombre de points d’histoire réalisés par sprint. L’objectif est de maintenir ce nombre constant sur une longue période. Si l’on n’utilise pas de modèle de processus basé sur les sprints, comme Kanban par exemple, la vélocité doit être déterminée sur des périodes choisies.
Le Burn Down Chart, en revanche, indique la progression de l’équipe dans le sprint en cours. Ici, on ne recherche pas une évolution constante, mais une diminution constante du nombre de tâches ouvertes. Le Burn Down Chart indique ainsi à quel point les user stories ont été bien divisées en sous-tâches et à quel point la minimisation du travail en cours fonctionne bien.
Bien entendu, ce ne sont pas les seules métriques pertinentes, mais probablement les plus répandues. Le nombre de bugs réclamés peut également être un bon indicateur de la stabilité réelle du produit logiciel.
Veuillez essayer ceci chez vous ou au travail !
Je souhaite maintenant conclure cette partie de la série d’articles, avant de me retrouver dans l’Over Engineering, et je termine avec deux tâches à réaliser :
- Analysez vos évaluations, métriques et KPI. Y a-t-il des relations non causales ?
- Essayez de mettre en œuvre la prochaine user story de la manière la plus simple possible. Elle doit toujours répondre aux critères d’acceptation ! Qu’auriez-vous normalement fait différemment, cela aurait-il déjà été trop ?
Dans cet esprit : veuillez essayer ceci chez vous ou au travail !
