Suivre ce qui compte : ICP et tableaux de bord

Dans le chapitre précédent, Concevoir pour la testabilité : Lever la prochaine barrièrenous avons exploré comment la testabilité est devenue une priorité après avoir résolu les goulets 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 profonds qui ont permis des tests plus fluides et plus rapides.

Au chapitre 4, nous passons à la phase critique suivante : définir et suivre les bons indicateurs clés de performance et mettre en place des tableaux de bord pour mesurer nos progrès. Les pratiques fondamentales étant en place et la testabilité s'améliorant, nous avions besoin de moyens objectifs, fondés sur des données, pour visualiser le flux, identifier les contraintes et nous améliorer en permanence.

L'importance des indicateurs de performance clés et des tableaux de bord pour DevOps

Au fur et à mesure que nous progressions dans notre démarche de rationalisation des livraisons de bout en bout, nous avons reconnu la nécessité d'un mécanisme visuel et objectif pour suivre le travail et découvrir les goulets d'étranglement. Il fallait donc définir des indicateurs clés de performance qui ne se limitent pas à des chiffres, mais qui permettent de mettre en évidence des informations exploitables et de susciter les comportements adéquats.

Lors de la mise en place des ICP, il est essentiel de reconnaître que les équipes et les organisations ont tendance à optimiser les mesures qu'elles contrôlent. Cela correspond à la loi de Goodhart, qui stipule ce qui suit :

"Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.

Ce principe souligne l'importance de sélectionner des ICP qui guident les équipes vers les bons résultats plutôt que de les encourager à simplement atteindre les objectifs. L'objectif de ces ICP est de mesurer les progrès accomplis dans la réalisation de notre objectif global. Mais quel est exactement cet objectif ?

Définir l'objectif

Comme l'explique Eliyahu M. Goldratt dans son ouvrage The Goal, l'objectif d'une entreprise est d'augmenter son bénéfice net tout en améliorant son ROI et le flux de trésorerie. En transposant cela au contexte du développement de logiciels, où nous sommes actuellement en phase d'investissement, nous avons identifié l'objectif suivant :

 "Développer et fournir un produit logiciel commercialisable qui génère des revenus durables".

Pour atteindre cet objectif, plusieurs conditions doivent être remplies, notamment

• Délai de mise sur le marché → Fournir rapidement des fonctionnalités et des produits pour saisir les opportunités du marché.
• Évolutivité future → Veiller à ce que le logiciel soit conçu pour s'adapter à la demande sans compromettre les performances.
• Optimisation des coûts → Équilibrer les dépenses de développement tout en maximisant la valeur ajoutée.
• Retour sur investissement (ROI) → S'assurer que le produit offre des avantages financiers à long terme qui justifient l'investissement.

Ces conditions ont guidé la manière dont nous avons défini nos indicateurs clés de performance, en nous concentrantnon seulement sur la rapidité et l'efficacité, mais aussi sur la mise au point d'un produit évolutif et rentable qui apporte une valeur commerciale à long terme.

Visualisation des flux : mise en place de tableaux de bord

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

• Fréquence de déploiement → fréquence à laquelle les équipes déploient le code en production.
• Délai d'exécution des modifications → rapidité avec laquelle le code passe de la validation à la production.
• Taux d'échec des modifications → Pourcentage de déploiements ayant entraîné des échecs.
• Temps moyen de rétablissement (MTTR) → Rapidité avec laquelle les équipes se remettent d'une défaillance.

Cependant, il était initialement difficile de générer ces mesures de manière significative en raison d'un manque de suivi systématique du travail au sein des é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 à chaque équipe pour assurer le suivi :

• Toutes les tâches assignées à chaque équipe.
• Travaux en cours.
• Travaux réalisés.
• Défauts classés par stade et par priorité.

Premier défi : une 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 presque impossible l'analyse des flux entre les équipes.

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é la mise en place de lignes directrices claires. Les statuts étaient utilisés différemment selon les équipes, ce qui rendait difficile l'identification des problèmes de flux entre les équipes. Il était essentiel de rendre cohérente la manière dont le travail était suivi, afin que les tableaux de bord puissent être utilisés non seulement pour les équipes individuelles, mais aussi pour l'optimisation des flux dans l'ensemble de l'organisation.

Nous nous sommes ensuite attachés à définir correctement les éléments de travail, en veillant à ce qu'ils reflètent avec précision l'état d'avancement 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 ne sont pas toujours suffisantes. Il était important de définir des catégories de statut qui correspondent à la structure de notre équipe, à la façon dont le travail se déroule et à nos goulets d'étranglement connus.

Analyse des flux de travail pour identifier les goulets d'étranglement

Les premiers tableaux de bord ont d'abord été mis en place pour visualiser le travail en cours, afin d'obtenir une image claire de ce qui se passait au sein des équipes. Il s'agissait notamment des feature stories, des user stories, des défauts et des plans de test. Ils donnaient un aperçu du travail en cours, mais ne permettaient pas encore de se faire une idée précise du flux global de travail et de valeur.

La visibilité du travail en cours était une première étape importante, mais le défi suivant consistait à relier cette visibilité à des mesures basées sur le flux qui pourraient mettre en évidence les points d'achoppement du travail et les domaines dans lesquels 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 dans chaque état. Au départ, nous ne disposions que d'informations sur le nombre d'éléments de travail dans les différents états. Une analyse plus poussée, telle que le suivi de la durée pendant laquelle les éléments de travail sont restés dans chaque état, nécessitait des outils supplémentaires, que nous présenterons plus tard. Toutefois, à ce stade initial, nous avons commencé notre analyse en utilisant uniquement les décomptes.

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

• Trop de travaux en cours par rapport au nombre de travaux achevés dans une période donnée.
• Un arriéré croissant de nouveaux travaux qui dépassait de loin ce que nous pouvions réaliser de manière réaliste dans les 3 à 6 mois à venir.
• Les équipes ayant le plus grand nombre de tâches inachevées, ce qui indique qu'elles ont besoin d'une attention et d'un soutien supplémentaires.

Chacune de ces idées nécessitait une solution différente, mais la capacité à visualiser le flux de travail a constitué une avancée majeure. Cette amélioration a fait progresser l'aspect " outils" de notre triangle DevOps, donnant l'impulsion nécessaire pour progresser dans les deux autres aspects, à savoir l'architecture et le personnel.

Utiliser les indicateurs de performance clés pour favoriser l'amélioration continue

Nous sommes revenus sur le sujet des KPI à 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 us ont aidés à :

• Mesurer les progrès au fil du temps pour s'assurer que nous nous rapprochons de notre objectif de développement d'un produit logiciel commercialisable.
• Identifier les dépendances et les transferts qui entraînaient des retards dans le flux de travail.
• Identifier les domaines dans lesquels les équipes ont besoin d'un soutien supplémentaire ou d'une amélioration des processus.
• Aligner davantage nos indicateurs clés de performance sur les quatre indicateurs clés DevOps d'Accelerate, afin d'obtenir une mesure objective de notre réussite.

En alignant les outils, l'architecture et les personnes sur les bons indicateurs clés de performance, nous avons créé un système qui us a permis de visualiser clairement nos progrès,d'identifier et de lever les obstacles, et de rester concentrés sur la création de valeur commerciale à long terme.

Et ensuite ? Branchement et déploiement continu

Grâce à nos indicateurs clés de performance (KPI) et à nos tableaux de bord, nous sommes désormais prêts à optimiser le flux de code à travers les environnements et jusqu'à la production. Au chapitre 5, nous verrons comment nous avons abordé la création de branches et le déploiement continu, ainsi que les changements culturels et techniques qui us ont permis us déployer plus rapidement et de manière plus sûre.

Restez à l'écoute !