Comprendre les métriques DORA : votre guide complet

Source : 2023 Accelerate State of DevOps, Google

Pourquoi mesurer le délai nécessaire aux changements?

Le délai nécessaire aux changements est un indicateur de la rapidité avec laquelle une équipe livre des changements aux utilisateurs. Il représente l’efficacité du flow, la complexité du code et la capacité de l’équipe. Des délais de livraison plus courts sont préférables, car ils permettent une boucle de rétroaction plus courte sur ce qui est développé et de corriger le tir plus rapidement. 

Les déploiements peuvent être retardés pour diverses raisons, notamment la peur de l’échec au déploiement ou le refus d’une livraison partielle : il est donc important que les équipes de développement aient une idée précise du temps nécessaire pour mettre les changements en production. Cette mesure est particulièrement utile pour les entreprises ou gestionnaires devant suivre plusieurs contextes ou équipes, puisqu’elle devient un indicateur de référence.

Causes potentielles d’un délai nécessaire aux changements élevé

• Goulots d’étranglement et dépendances dans le processus
• Beaucoup de temps de délai où les tâches ne sont pas activement travaillées
• Manque d’automatisation de déploiement ou difficile d’aller en production rapidement
• Revues de code trop lourdes et longues à effectuer
• Manque de tests automatisés sur les comportements (compensé par des tests manuels faits par des humains)
• Legacy code ou aucun temps alloué à rembourser la dette technique
• Dérapage du champ d’application (scope creep) et suringénierie

Comment améliorer le délai nécessaire aux changements?

Peu importe où se situe votre équipe dans le tableau ci-haut, voici quelques pistes pour vous améliorer : 

• Encourager la collaboration et la réduction du travail en cours (WIP) et du nombre de revues effectuées en parallèle
• Mise en place de processus de déploiement et de révision plus automatisés
• Division des tâches et fonctionnalités en petits items plus faciles à gérer
• Analyse du temps passé par étape du pipeline de développement afin d’identifier les goulots d’étranglement
• Ne pas dépendre d’une personne externe à l’équipe pour les révisions de code
• Favoriser le trunk-based development pour apporter de plus petits changements fréquemment
• Encourager le test-driven development (TDD) ou investir davantage dans des tests automatisés qui sont orientés sur les comportements

Le délai nécessaire aux changements d’une équipe de développement dans Axify

Taux d’échec des changements

Cette métrique capte le pourcentage de modifications apportées à un code qui ont ensuite entraîné des incidents, des retours en arrière ou tout autre type d’échec de production. Selon le rapport DORA, les entreprises les plus performantes se situent autour de 5%.

La partie la plus délicate pour la plupart des équipes consiste à définir ce qu’est un «incident». Il peut s’agir d’une non-disponibilité du système (partielle ou complète), d’une fonctionnalité non utilisable, d’un bogue critique, majeur ou tout type de bogue. Selon DORA, il s’agit de changements apportés à la production ou aux versions destinées aux utilisateurs qui entraînent une dégradation du service (par exemple, une détérioration ou une interruption du service) et qui nécessitent ensuite des mesures correctives (par exemple, un hotfix, un rollback, un fix forward ou un patch). Une définition trop large ou trop restrictive pourrait nuire à l’équipe et la réponse dépend fortement du contexte de celle-ci.

Indicateur de référence

Quel pourcentage des modifications apportées à la production ou aux utilisateurs finaux entraîne une dégradation du service?

Source : 2023 Accelerate State of DevOps, Google

Pourquoi mesurer le taux d’échec des changements?

Il s’agit d’un indicateur de qualité et de stabilité du code. Cette métrique montre le pourcentage de changements effectués qui entraînent un incident. Comme mentionné précédemment, le type d’incident considéré pour cette métrique est propre à chaque équipe. Mais il est important de comprendre qu’un taux d’échec élevé implique une augmentation du temps passé à retravailler sur des fonctionnalités existantes, donc une diminution du temps alloué à livrer de la nouvelle valeur aux utilisateurs. Bien que ce ne soit pas une métrique de temps à proprement parler, le taux d’échec des changements peut avoir des implications importantes sur votre capacité à créer de la valeur rapidement.

Un faible taux d’échec des changements montre que l’équipe identifie les erreurs et les bogues d’infrastructure avant le déploiement du code. C’est le signe d’un processus de déploiement solide et de la livraison de logiciels de haute qualité. L’objectif de l’équipe DevOps devrait être de réduire le taux d’échec des modifications afin de garantir la disponibilité et le bon fonctionnement du logiciel. 

Causes potentielles d’un taux d’échec des changements élevé

• Absence de tests automatisés, trop de tests manuels, ou tests inefficaces ou absents avant le déploiement
• Problèmes dans le processus de développement
• Des gros changements qui demandent de longues révisions et où il y a peu de commentaires
• Code de mauvaise qualité ou couplage trop élevé
• Maintenabilité difficile et introduction de nouveau code
• Changements d’infrastructure non reproductibles

Comment améliorer le taux d’échec des changements?

Peu importe où se situe votre équipe dans le tableau ci-haut, voici quelques pistes pour vous améliorer : 

• Réduire le travail en cours (WIP) dans les itérations
• Favoriser les activités sociales de développement (ex. : pair programming, revue de code synchrone) 
• Augmenter la confiance envers nos tests automatisés, en écrire davantage et encourager le TDD
• Travailler avec des itérations plus petites
• Utiliser des outils d’analyse de code statique dans votre intégration continue
• Créer une routine de surveillance d’équipe afin d’augmenter l’imputabilité de l’équipe face à la disponibilité et la fiabilité du système
• Créer une boucle de rétroaction récurrente
• Automatiser les migrations de base de données ou de création d’environnement

Conseil | Les équipes qui ne déploient pas beaucoup de changements verront moins d’incidents, mais cela ne signifie pas nécessairement qu’elles ont plus de succès avec les changements qu’elles déploient. Les équipes qui déploient fréquemment peuvent voir un nombre plus élevé d’incidents, mais si le taux d’échec des changements est faible, ces équipes auront un avantage en raison de la rapidité de leurs déploiements et de leur taux de réussite global.

Temps de récupération d'un échec de déploiement

Le temps de récupération d'un échec de déploiement mesure le temps nécessaire à un service pour rebondir après un incident ou une dégradation du service. Quel que soit le niveau de performance d’une équipe, des pannes ou des incidents imprévus se produiront. Et comme les incidents ne peuvent être évités, c’est vraiment le temps qu’il faut pour restaurer ou récupérer un système ou une application qui fait la différence.

Cette métrique est importante, car elle encourage les développeurs à construire des systèmes plus fiables, disponibles et résilients. Elle est généralement calculée en suivant le temps moyen entre le signalement de l’incident et le moment où sa restauration est déployée. Pour les équipes les plus performantes, il s’agit d’être capable de restaurer le service en moins d’une heure.

Indicateur de référence

Combien de temps faut-il pour restaurer le service après une panne, une dégradation ou l’introduction d’un bogue ayant un impact sur les utilisateurs?

Source : 2023 Accelerate State of DevOps, Google

Pourquoi mesurer le temps de récupération d'un échec de déploiement?

Le temps de récupération d'un échec de déploiement indique le temps de réponse d’une équipe et l’efficacité du processus de développement. Lorsqu’il est bas, il démontre qu’une équipe réagit et résout les problèmes rapidement pour garantir la disponibilité et le bon fonctionnement du produit.

De plus, la capacité d’une équipe à se rétablir rapidement peut avoir un impact positif sur le niveau de confiance des utilisateurs et amener plus d’aisance de la part des dirigeants face aux expérimentations. C’est donc un avantage concurrentiel non négligeable!

Causes potentielles d’un temps de récupération d'un échec de déploiement élevé

• Absence de tests automatisés

• Dépendance vers un membre externe à l’équipe ou manque d’accès à certaines composantes du système

• Pas de changement de focus dans l’équipe pour résoudre l’incident

• Processus de gestion des incidents inefficace

• Difficulté de déployer en production rapidement

• Pas de processus de restauration à une version antérieure (rollback)

• Outils inefficaces

Comment améliorer le temps de récupération d'un échec de déploiement?

Peu importe où se situe votre équipe dans le tableau ci-haut, voici quelques pistes pour vous améliorer : 

• Favoriser une surveillance en continu et améliorer l’observabilité

• Donner la priorité à la restauration lorsqu’une défaillance se produit

• Essayer les feature flags pour être en mesure de désactiver rapidement un changement sans causer trop de perturbations

• Livrer de petites itérations pour qu’il soit plus facile de découvrir et de résoudre les problèmes

• Investir davantage dans les tests automatisés et utiliser une stratégie de tests orientés sur les comportements

• Documenter le processus de gestion des incidents et former les membres de l’équipe sur la façon de réagir en cas d’incidents

• Lorsque c’est applicable, automatiser plusieurs étapes du processus de gestion des incidents et désigner des responsables pour les étapes qui doivent être réalisées manuellement

Conseil | Équilibrez vitesse et stabilité! Permettez-vous parfois de ralentir pour mieux accélérer, en réduisant par exemple le travail en cours (WIP). Évitez de mettre en production des changements soudains au détriment d’une solution de qualité. Plutôt que de déployer une solution rapide, assurez-vous que le changement que vous apportez est durable et testé. Vous devriez suivre le temps moyen de récupération d'un échec de déploiement dans le temps pour voir comment votre équipe s’améliore et viser une croissance régulière et stable.

Le temps de récupération d'un échec de déploiement dans Axify

Les avantages de suivre la progression des métriques DORA

Amélioration continue

Pour s’améliorer, il faut deux éléments : un point de départ et un objectif à atteindre. Les métriques DORA donnent aux équipes de développement des objectifs concrets, qui peuvent ensuite être décomposées en résultats clés. En sachant quelles données suivre au fil du temps, les développeurs vont ajuster leur comportement pour améliorer la mesure de leur côté, ce qui aura un impact sur l’efficacité de l’équipe et des processus.

De plus, les variations dans les résultats des métriques DORA vous aideront à cibler rapidement les points à améliorer en ce qui concerne le processus de livraison et à repérer les problèmes tels que l’inefficacité des tests.

Meilleure visibilité

Les métriques DORA sont des métriques fiables résultant d’études scientifiques à jour. Comme les quatre métriques sont reliées entre elles, elles sont difficiles à tricher : vous avez donc un portrait réaliste de votre situation. Elles permettent aussi de comparer votre équipe au reste de l’industrie, d’identifier les possibilités d’amélioration et d’apporter des changements pour optimiser vos résultats à plusieurs niveaux.

Aide à la prise de décision

Les entreprises qui rationalisent leur processus de développement et de livraison augmentent la valeur des logiciels qu’elles développent et sont plus performantes à long terme. Le suivi des performances à l’aide des métriques DORA permet aux équipes DevOps de prendre des décisions fondées sur des données, et non sur des intuitions.

De plus, les métriques DORA aident à aligner les objectifs de développement sur les objectifs commerciaux. Du point de vue de la gestion des produits, ils permettent de savoir comment et quand les équipes de développement peuvent répondre aux besoins des clients. 

Production de valeur

Ces dernières années, la gestion de la chaîne de valeur (Value Stream Management) est devenue un élément important du développement logiciel. Dans ce contexte, les métriques DORA jouent un rôle indispensable, car les équipes qui se mesurent ont tendance à s’améliorer en continu. Ainsi, lorsque les équipes DevOps utilisent les métriques DORA, elles constatent généralement une augmentation de la valeur au fil du temps.

En tant qu’ensemble de repères DevOps éprouvés qui sont devenus la norme dans le secteur, les métriques DORA fournissent une base pour ce processus. Elles identifient les points d’inefficacité ou de gaspillage, et vous pouvez utiliser ces informations pour rationaliser et réduire les goulots d’étranglement dans vos flux de travail, par exemple en décortiquant le délai nécessaire aux changements en étape pour observer les étapes qui bloquent le processus. Lorsque les indicateurs DORA de vos équipes s’améliorent, l’efficacité de l’ensemble de la chaîne de valeur s’améliore avec elles.

En outre, les métriques DORA vous permettent de vous mesurer et vous améliorer pour ultimement :

• Livrer plus rapidement, en garantissant une meilleure stabilité

• Offrir plus de valeur aux clients en garantissant des itérations rapides et une meilleure réactivité au retour d’information

• Augmenter plus rapidement la valeur commerciale d’un produit

Équilibre entre vitesse et stabilité

Les mesures DORA donnent également un aperçu des performances des équipes. En examinant le taux d’échec des changements et le temps de récupération d'un échec de déploiement, les responsables de l’ingénierie peuvent s’assurer que leurs équipes construisent des produits robustes avec des temps d’arrêt minimaux. De même, le suivi de la fréquence de déploiement et du délai nécessaire aux changements permet d’avoir l’assurance que l’équipe travaille rapidement. Ensemble, ces mesures donnent un aperçu de l’équilibre entre vitesse et qualité au sein de l’équipe. 

En comparant ces quatre indicateurs clés, on peut évaluer dans quelle mesure l’organisation parvient à équilibrer vitesse et stabilité. Par exemple, si le temps moyen de récupération d'un échec de déploiement est inférieur à une semaine avec des déploiements hebdomadaires, mais que le taux d’échec des changements est élevé, alors il se peut que l’équipe précipite les déploiements alors qu’il manque de tests automatisés, ou elles peuvent ne pas être en mesure de prendre en charge les changements qu’elles déploient. D’autre part, si les déploiements ont lieu une fois par mois et que le temps de récupération d'un éhec de déploiement et le taux d’échec des changements sont élevés, l’équipe passe peut-être plus de temps à corriger le code qu’à améliorer le produit. Tout est une question de contexte!

Les plus grands défis des métriques DORA

Accessibilité des données

La plupart du temps, les environnements et les données sont décentralisés, c’est-à-dire que les données sont dispersées dans différentes sources à travers l’organisation. De plus, les extraire peut être complexe lorsqu’elles ne sont disponibles qu’au format brut. Enfin, les données doivent être transformées et combinées en unités calculables pour permettre aux équipes de développement d’en tirer tous les avantages. En plus du temps requis pour faire ces manipulations, calculer manuellement les données laisse place à l’interprétation, ce qui présente un risque d’erreur ou de communiquer la mauvaise information.

Analyse des résultats

Comme toutes les données, les mesures DORA doivent être mises en contexte et il faut considérer l’histoire que ces quatre métriques racontent ensemble. Le délai nécessaire aux changements et la fréquence de déploiement donnent un aperçu de la cadence d’une équipe et de la rapidité avec laquelle elle répond aux besoins en constante évolution des utilisateurs. D’autre part, le temps moyen de récupération d'un échec de déploiement et le taux d’échec des changements indiquent la stabilité d’un produit logiciel et la réactivité de l’équipe en cas d’interruption ou de défaillance du service. Seul un professionnel qui comprend la réalité de l’équipe de développement sera en mesure de bien interpréter ces données pour contribuer à leur amélioration continue.

Par où commencer?

Chez Axify, nous intégrons les métriques DORA à nos tableaux de bord pour voir tous les facteurs permettant de soutenir votre équipe dans l’amélioration continue d’un seul coup d’œil. Pas d’extraction de données ni d’ambiguïté sur leur interprétation. Tout est à portée de main pour rester dans le feu de l’action! De plus, puisque toutes vos équipes utiliseront la même structure et la même méthode d’extraction, il sera plus facile pour vous de comparer des pommes avec des pommes. 

Comment implanter les métriques DORA dans votre processus?

Lorsque vous aurez choisi un outil vous permettant de suivre les métriques DORA, ne focalisez pas trop sur les métriques dans un premier temps. Commencez à collecter des données, suivez les métriques pendant quelques semaines, puis analysez ce que vous devez améliorer.

Ensuite, établissez des objectifs d’amélioration : concentrez-vous sur votre produit et sa croissance, ainsi que sur la croissance de votre équipe et l’amélioration des processus. Considérez les indicateurs DORA comme un ensemble d’indicateurs de ce que vous pouvez faire pour avoir un impact positif sur le produit et ses résultats commerciaux.

Ce qu’il faut retenir

En réalité, les métriques ne sont qu’un outil. L’important, c’est que l’équipe de développement souhaite améliorer son efficacité et qu’elle utilise des indicateurs pour savoir si elle progresse dans ses efforts d’amélioration continue. Donnez à votre équipe les outils dont ils ont besoin pour réussir à apporter les meilleurs changements qui aideront votre équipe à atteindre ses objectifs.

Lorsque vos métriques DORA s’améliorent, vous pouvez être sûr que vous avez pris les bonnes décisions pour améliorer la performance de votre équipe et que vous apportez une plus grande valeur à vos clients.

Axify regroupe plusieurs fonctionnalités pour vous aider à visualiser la progression de ces métriques pour votre (ou vos!) équipe(s). Premièrement, nos intégrations avec les outils que vous utilisez déjà comme GitLab, GitHub et Azure DevOps recueillent et traitent les données alimentant les métriques DORA. Deuxièmement, notre outil de création et suivi d’objectif vous permet de sélectionner les métriques à améliorer et d’indiquer la variation souhaitée sur un horizon temporel de votre choix. Ces tableaux de bord vous permettent de suivre vos progrès au fil du temps. 

Pour plus d’informations sur la façon dont Axify aide les équipes de développement à mesurer les indicateurs de performance DORA, contactez-nous ou demandez une démonstration.