5 min de lecture
Dans notre chapitre précédent, Concevoir pour la testabilité : franchir le prochain obstacle, nous avons examiné comment la testabilité est devenue une priorité absolue après la résolution des premiers goulets d'étranglement liés à l'organisation des équipes et aux tests manuels. Ce chapitre a marqué un tournant dans notre transformation DevOps, en orientant notre attention vers des principes de conception logicielle plus approfondis permettant des tests plus fluides et plus rapides.
Désormais, dans le chapitre 4, nous entamons une nouvelle phase cruciale : la définition et le suivi des indicateurs clés de performance (KPI) pertinents, ainsi que la configuration de tableaux de bord pour mesurer nos progrès. Disposant de bases solides et d'une testabilité améliorée, nous avions besoin de méthodes objectives et fondées sur les données pour visualiser les flux, repérer les contraintes et progresser continuellement.
Pourquoi les indicateurs clés de performance (KPI) et les tableaux de bord sont essentiels en 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 de KPI, il est essentiel de garder à l'esprit que les équipes et les organisations ont tendance à optimiser les métriques qu'elles surveillent. Cela fait écho à la loi de Goodhart, qui énonce 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 KPI qui orientent les équipes vers les bons résultats plutôt que de les encourager à simplement atteindre des chiffres. L'objectif de ces KPI est de mesurer les progrès accomplis vers notre but global. Mais quel est précisément ce but ?
Définition de l'objectif
Comme l'indique l'ouvrage Le But d'Eliyahu M. Goldratt, l'objectif d'une entreprise est d'accroître son bénéfice net tout en améliorant simultanément son ROI et sa trésorerie. Transposé à notre contexte de développement logiciel, où nous nous trouvons actuellement dans la phase d'investissement, nous avons défini l'objectif comme suit :
« Développer et proposer 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é → 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 création de valeur.
- 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 définition de nos indicateurs clés de performance (KPI) en nous concentrant non seulement sur la vitesse et l'efficacité, but also on building a scalable, cost-effective product that delivers long-term business value.
Visualisation du flux : configuration des tableaux de bord
Comme l'indique l'ouvrage Accelerate de Nicole Forsgren, Jez Humble et Gene Kim, notre objectif était de configurer un tableau de bord capable de visualiser et de suivre les quatre indicateurs DevOps clés :
- Fréquence des déploiements → La fréquence à laquelle les équipes déploient du code en production.
- Délai de livraison des modifications → La rapidité avec laquelle le code passe de la validation à la production.
- Taux d'échec des modifications → Le pourcentage de déploiements entraînant des défaillances.
- Temps moyen de restauration (MTTR) → La rapidité avec laquelle les équipes se remettent d'une panne.
Toutefois, générer ces indicateurs de manière pertinente s'est avéré difficile au départ en raison du manque de suivi systématique du travail entre les équipes. C'est là que l'adoption d'Azure DevOps en tant solution de gestion du travail unique et commune à toutes les équipes a fait une différence significative.
Nous avons commencé par configurer des tableaux de bord spécifiques aux équipes pour suivre :
- Tous les éléments de travail assignés par équipe.
- Le travail en cours.
- Le travail terminé.
- Les anomalies classées par étape 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 d'anomalies différemment. Cette incohérence a rendu l'analyse des flux entre les équipes presque impossible.
Le premier défi que nous avons rencontré a été l'utilisation incohérente des états des éléments de travail et des classifications d'anomalies, malgré des directives claires. Les différentes équipes utilisaient les statuts de manière disparate, ce qui rendait difficile l'identification des problèmes de flux d'une équipe à l'autre. Il est devenu primordial d'harmoniser le suivi du travail pour garantir que les tableaux de bord puissent servir non seulement aux équipes individuelles, mais aussi à l'optimisation des flux à l'échelle de l'organisation.
Nous nous sommes ensuite attachés à définir correctement les éléments de travail pour qu'ils reflètent avec précision l'état d'avancement dans la chaîne de valeur, tout en restant 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 suffisaient pas toujours. Il était important de définir des catégories de statut alignées sur notre structure d'équipe, notre mode de fonctionnement et nos goulets d'étranglement connus.
Analyse du flux de travail pour identifier les goulets d'étranglement
Les premiers tableaux de bord ont principalement été mis en place pour visualiser le travail en cours afin d'obtenir une vision claire de la situation au sein des équipes. Cela comprenait les fonctionnalités, les user stories, les anomalies et les plans de test. Ils ont fourni un aperçu du travail en cours, mais ne donnaient toujours pas une vue d'ensemble claire du flux de travail et de la valeur.
Avoir une visibilité sur le travail en cours constituait une première étape importante, mais le défi suivant consistait à relier cette visibilité à des indicateurs de flux capables de mettre en évidence les blocages et les axes d'amélioration.
À partir du statut des tâches, nous avons établi des indicateurs pour afficher le nombre de tâches à chaque étape. Au début, nous disposions uniquement du décompte des tâches selon leur état. Des analyses plus avancées, telles que le suivi du temps passé par les tâches dans chaque état, ont nécessité de nouveaux outils introduits par la suite. Cependant, lors de cette phase initiale, nous avons entamé notre analyse en nous basant uniquement sur ces 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 :
- Un nombre trop élevé de tâches en cours par rapport au nombre de tâches achevées sur une période donnée.
- Un arriéré croissant de nouvelles tâches qui dépassait largement ce que nous pouvions raisonnablement accomplir au cours des 3 à 6 prochains mois.
- Les équipes ayant le plus grand volume de tâches inachevées, ce qui a permis de cibler les besoins de soutien et d'accompagnement supplémentaires.
Chacun de ces constats a exigé une solution spécifique, mais la capacité à visualiser le flux de travail a constitué une avancée majeure. Cette amélioration a renforcé le volet Outils de notre triangle DevOps, servant de catalyseur pour progresser dans les deux autres domaines : l'architecture et les équipes.
Utiliser les indicateurs clés de performance (KPI) pour stimuler l'amélioration continue
Nous sommes revenus sur le sujet des indicateurs clés de performance (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 nous ont aidés à :
- Mesurer l'évolution au fil du temps pour veiller à ce que nous progressions vers notre objectif de développer un logiciel commercialisable.
- Identifier les dépendances et les transferts qui ralentissaient le déroulement du travail.
- Cerner les secteurs où les équipes avaient besoin d'un soutien accru ou d'améliorations de processus.
- Harmoniser davantage nos KPI avec les quatre indicateurs DevOps essentiels issus d'Accelerate, afin de disposer d'une mesure objective de notre réussite.
En alignant les outils, l'architecture et les équipes sur les bons KPI, nous avons créé un système qui offre une visibilité claire sur notre progression, nous aide à identifier et à débloquer les goulets d'étranglement, et garantit que nous restons concentrés sur la création de valeur commerciale à long terme.
Quelle est la prochaine étape ? Gestion des branches et déploiement continu
Nos KPI et tableaux de bord étant en place, nous sommes désormais prêts à optimiser le flux de code à travers les environnements et jusqu'en production. Au chapitre 5, nous aborderons en détail notre approche de la gestion des branches et du déploiement continu, ainsi que les évolutions culturelles et techniques qui nous ont permis de déployer plus rapidement et en toute sécurité.
Restez à l'écoute !
