Le suivi des éléments essentiels : KPI et tableaux de bord

Dans notre chapitre précédent, Concevoir pour la testabilité : Franchir la prochaine barrière, nous avons exploré comment la testabilité est devenue un axe majeur après avoir résolu les goulots d'étranglement initiaux liés à la mise en place de l'équipe et aux tests manuels. Ce chapitre a marqué un tournant dans notre transformation DevOps, car nous avons porté notre attention sur des principes de conception logicielle plus approfondis qui ont permis des tests plus fluides et plus rapides.

Désormais, dans le Chapitre 4, nous passons à une prochaine phase critique : définir et suivre les bons indicateurs clés de performance (KPI) et mettre en place des tableaux de bord pour mesurer nos progrès. Avec des pratiques fondamentales établies et une testabilité en amélioration, nous avions besoin de moyens objectifs et basés sur les données pour visualiser le flux, identifier les contraintes et nous améliorer continuellement.

Pourquoi les KPI et les tableaux de bord sont importants dans le DevOps

À mesure que nous progressions dans notre démarche de rationalisation de la livraison End-to-End, nous avons reconnu le besoin d'un mécanisme visuel et objectif pour suivre le travail et identifier les goulots d'étranglement. Cela signifiait définir des KPI qui ne se limitaient pas aux chiffres, mais qui mettaient en évidence des informations exploitables et favorisaient les bons comportements.

Lors de la mise en place des KPI, il est essentiel de reconnaître que les équipes et les organisations ont tendance à optimiser les indicateurs qu'elles surveillent. Cela est conforme à la loi de Goodhart, qui stipule :

« Quand une mesure devient un objectif, elle cesse d'être une bonne mesure. »

Ce principe souligne l'importance de choisir des KPI qui orientent les équipes vers les bons résultats plutôt que de les inciter à simplement atteindre des objectifs. Le but de ces KPI est de mesurer les progrès vers notre objectif global. Mais quel est exactement cet objectif ?

Définition de l'objectif

Comme discuté dans Le But d'Eliyahu M. Goldratt, l'objectif d'une entreprise est d'augmenter le bénéfice net tout en améliorant simultanément le ROI et la trésorerie. En transposant cela à notre contexte de développement logiciel, où nous sommes actuellement en phase d'investissement, nous avons identifié l'objectif comme suit :

 « Développer et livrer un produit logiciel commercialisable qui génère des revenus durables. »

Atteindre cet objectif nécessite de remplir plusieurs conditions nécessaires, notamment :

• Délai de mise sur le marché → Livrer rapidement des fonctionnalités et des produits pour saisir les opportunités du marché.
• Évolutivité future → S'assurer que le logiciel est conçu pour évoluer avec la demande sans compromettre les performances.
• Optimisation des Coûts → Équilibrer les dépenses de développement tout en maximisant la valeur délivrée.
• Retour sur Investissement (ROI) → S'assurer que le produit génère des avantages financiers à long terme qui justifient l'investissement.

Ces conditions ont guidé la manière dont nous avons défini nos KPIs, en nous concentrant non seulement sur la vitesse et l'efficacité, mais aussi sur la création d'un produit évolutif et rentable qui apporte une valeur commerciale à long terme.

Visualiser le flux : Mise en place de tableaux de bord

Comme décrit dans Accelerate par Nicole Forsgren, Jez Humble et Gene Kim, notre objectif était de mettre en place un tableau de bord capable de visualiser et de suivre les quatre indicateurs clés DevOps :

• Fréquence de déploiement → À quelle fréquence les équipes déploient du code en production.
• Délai de mise en œuvre des changements → La rapidité avec laquelle le code passe du commit à la production.
• Taux d'échec des changements → Le pourcentage de déploiements entraînant des échecs.
• Temps moyen de restauration (MTTR) → La rapidité avec laquelle les équipes se remettent des pannes.

Cependant, générer ces indicateurs de manière significative était initialement difficile en raison d'un manque de suivi systématique du travail entre les équipes. C'est là que l'adoption d'Azure DevOps comme solution unique et commune de gestion du travail pour toutes les équipes a fait une différence significative.

Nous avons commencé par mettre en place des tableaux de bord spécifiques aux équipes pour suivre :

• Toutes les tâches attribuées par équipe.
• Travaux en cours.
• Travail terminé.
• Défauts catégorisés par étape et par priorité.

Premier défi : Utilisation incohérente

Même avec des directives claires, les équipes utilisaient les statuts et les catégories de défauts différemment. Cette incohérence rendait l'analyse des flux inter-équipes presque impossible.

Le premier défi que nous avons rencontré était l'utilisation incohérente des états des éléments de travail et des classifications des défauts, malgré des directives claires en place. Différentes équipes utilisaient les statuts différemment, ce qui rendait difficile l'identification des problèmes de flux entre les équipes. Apporter de la cohérence à la manière dont le travail était suivi est devenu essentiel, garantissant que les tableaux de bord pouvaient être utilisés non seulement pour les équipes individuelles, mais aussi pour l'optimisation des flux à l'échelle de l'organisation.

Nous nous sommes ensuite concentrés sur la définition correcte des éléments de travail, en veillant à ce qu'ils puissent refléter précisément la position du travail dans la chaîne de valeur, tout en étant suffisamment génériques pour être utilisés par plusieurs équipes. La plupart des outils fournissent des catégories de statut par défaut, mais celles-ci n'étaient pas toujours suffisantes. Il était important de définir des catégories de statut qui correspondaient à notre structure d'équipe, à la manière dont le travail circulait et à nos goulots d'étranglement connus.

Analyse du flux de travail pour identifier les goulots d'étranglement

Les premiers tableaux de bord ont été principalement configurés pour visualiser le travail en cours afin d'obtenir une image claire de ce qui se passait au sein des équipes. Cela incluait les récits de fonctionnalités, les récits d'utilisateurs, les défauts et les plans de test. Ceux-ci fournissaient un aperçu du travail en cours, mais ils ne donnaient toujours pas une image claire du flux global de travail et de valeur.

Avoir une visibilité sur le travail en cours était une première étape importante, mais le défi suivant consistait à relier cette visibilité à des métriques basées sur les flux qui pourraient mettre en évidence les points de blocage du travail et les domaines où nous devions nous améliorer.

En utilisant le statut des éléments de travail, nous avons créé des indicateurs pour montrer le nombre d'éléments de travail à chaque étape. Initialement, nous disposions uniquement d'informations sur le nombre d'éléments de travail dans différents états. Des analyses plus poussées – comme le suivi de la durée pendant laquelle les éléments de travail sont restés à chaque étape – ont nécessité des outils supplémentaires, que nous avons introduits par la suite. À ce stade initial, cependant, nous avons commencé notre analyse en nous basant uniquement sur ces décomptes.

Même avec ces données de base, les tableaux de bord se sont avérés précieux pour identifier les principaux goulots d'étranglement :

• Trop d'éléments de travail en cours par rapport au nombre d'éléments achevés au cours d'une période donnée.
• Un arriéré croissant de nouvelles tâches qui dépassait de loin ce que nous pouvions raisonnablement accomplir au cours des 3 à 6 prochains mois.
• Équipes avec le plus grand arriéré d'éléments de travail inachevés, indiquant où un effort et un soutien supplémentaires étaient nécessaires.

Chacune de ces informations a nécessité une solution différente, mais la capacité à visualiser le flux de travail a constitué une avancée majeure. Cette amélioration a poussé plus loin l'aspect Outils de notre Triangle DevOps, donnant l'impulsion au progrès dans les deux autres aspects : Architecture et Personnes.

Utiliser les KPI pour favoriser l'amélioration continue

Nous sommes revenus sur le sujet des KPIs à plusieurs étapes de notre transformation DevOps. À mesure que nos capacités de suivi s'amélioraient, nous avons pu générer des métriques plus détaillées qui nous ont aidés à :

• Mesurer les progrès au fil du temps pour nous assurer que nous avancions vers notre objectif de développer un produit logiciel commercialisable.
• Identifier les dépendances et les transferts qui causaient des retards dans le déroulement du travail.
• Identifier les domaines où les équipes avaient besoin d'un soutien supplémentaire ou d'améliorations des processus.
• Aligner nos KPI plus étroitement avec les quatre métriques clés DevOps issues d'Accelerate, offrant une mesure objective de notre succès.

En alignant les outils, l'architecture et les personnes avec les bons KPIs, nous avons créé un système qui a fourni une visibilité claire sur nos progrès, nous a aidés à identifier et à débloquer les goulots d'étranglement, et a garanti que nous restions concentrés sur la fourniture d'une valeur commerciale à long terme.

Et ensuite ? Ramification et déploiement continu

Avec nos KPI et tableaux de bord en place, nous sommes maintenant prêts à optimiser le flux de code à travers les environnements et jusqu'à la production. Dans le Chapitre 5, nous examinerons comment nous avons abordé le branchement et le déploiement continu, ainsi que les changements culturels et techniques qui nous ont permis de déployer plus rapidement et en toute sécurité.

Restez à l'écoute !