Que sont les métriques DORA ?

Découvrez dans cet article le rôle précis de chacune des métriques DORA et comment elles peuvent être exploitées pour favoriser l'excellence dans la livraison de logiciels.

Dans le monde du développement logiciel, il y a toujours eu une certaine tension du fait de la séparation entre équipes de développement et équipes d'exploitation. Le mouvement DevOps s'est efforcé de répondre à cette tension en encourageant la collaboration, la confiance et la création d'équipes multidisciplinaires pour briser les silos entre « Dev » et « Ops » (nos équipes d'exploitation).

DevOps a été largement adopté depuis son apparition en 2007-2008. Une poignée de leaders du mouvement DevOps ont publié le rapport State of DevOps de 2014 à 2017, avant de créer ensemble une start-up appelée DevOps Research and Assessment, ou DORA. (Rachetée depuis par Google Cloud, DORA continue de publier ce rapport annuel.)

Jez Humble, Gene Kim et Nicole Forsgren ont fondé DORA dans le but d'utiliser leurs recherches sur le DevOps pour mieux comprendre les pratiques, les processus et les capacités qui permettent aux équipes d'optimiser leur performance en matière de développement et de livraison de logiciels.

Les fondateurs de DORA ont identifié quatre métriques clés qui sont essentielles au succès du DevOps :

• Fréquence de déploiement (DF)
• Délai d'exécution des changements (LT)
• Délai moyen de rétablissement (MTTR)
• Taux d'échec des changements (CFR)

L'équipe DORA a identifié ces métriques comme ayant le plus grand impact sur le développement et la livraison de logiciels au travers d'une enquête menée auprès de plus de 31 000 professionnels sur une période de six ans.

Les quatre métriques DORA permettent aux responsables de l'ingénierie d'évaluer la performance de leur équipe par rapport à d'autres dans l'industrie, c'est-à-dire de déterminer si s'agit d'équipes « d'élite » ou si elles pourraient au contraire s'améliorer (équipes très performantes, moyennement performantes et peu performantes). Grâce à ces informations, les responsables peuvent identifier les axes d'amélioration et apporter les changements nécessaires.

Fréquence de déploiement (DF)

La fréquence de déploiement (DF) est une mesure du rendement moyen. Il s'agit de la fréquence moyenne à laquelle le code est déployé en production sur une période donnée. Cette métrique peut ainsi être utilisée pour évaluer la fréquence à laquelle une équipe d'ingénierie livre de la valeur aux clients.

Pour fidéliser les clients et garder une longueur d'avance sur la concurrence, il est essentiel de pouvoir leur proposer de nouvelles fonctionnalités régulièrement et rapidement.

Mesurer la fréquence de déploiement au fil du temps peut aider les équipes à identifier des moyens d'améliorer leur vitesse de livraison. DORA a notamment constaté que les équipes DevOps les plus performantes effectuent généralement des déploiements plus petits et plus fréquents.

Les équipes DevOps peuvent utiliser leurs métriques DF pour comparer leur performance à celles des autres équipes. Les équipes très performantes déploient en moyenne une fois par semaine, tandis que les équipes les plus performantes sont capables de faire plusieurs déploiements dans une même journée.

Si une équipe est peu performante dans ce domaine, elle peut utiliser cette information pour identifier des moyens spécifiques de s'améliorer : par exemple, en décomposant le travail en lots plus petits ou en créant des pull requests moins importantes.

Délai d'exécution des changements (LT)

Le délai d'exécution des changements (LT) mesure le temps qu'il faut à une équipe pour mettre en œuvre un changement une fois le codage commencé.

Le délai d'exécution des changements est mesuré en suivant le temps qui s'écoule entre le moment où un engagement est pris pour livrer un changement et le moment où ce changement est mis en production. La moyenne de tous les changements apportés au cours d'une période donnée est donnée par une autre métrique, le délai moyen d'exécution des changements (MLTC).

La mesure du MLTC est importante, car elle permet de quantifier le temps nécessaire à une équipe pour livrer le travail aux clients. Une mauvaise performance dans ce domaine signifie qu'une équipe est incapable d'implémenter les changements réclamés de façon fiable et en temps voulu.

Comme les autres métriques DORA, le délai moyen d'exécution des changements peut être utile pour évaluer la performance d'une équipe comparativement aux autres. En règle générale, les équipes les plus performantes peuvent mettre en œuvre les changements en l'espace d'une journée, alors que les équipes moyennes ont besoin d'une semaine environ. Cette métrique peut aider les responsables à mieux appréhender la capacité de l'équipe et à ajuster les attentes de manière réaliste quand des changements sont demandés.

De nombreux facteurs peuvent affecter le MLTC, c'est pourquoi il est important de suivre les métriques de délai d'exécution pour chaque étape du processus de développement. Les responsables peuvent analyser le temps nécessaire à leur équipe pour ouvrir, traiter, tester et déployer les changements afin de déterminer s'il y a des goulots d'étranglement à certains endroits.

Si une équipe n'est pas satisfaite de son délai d'exécution des changements, elle peut essayer de décomposer le travail en lots plus petits, de créer des pull requests moins importantes, d'améliorer son processus de revue du code ou d'automatiser ses processus de test ou de déploiement.

Délai moyen de rétablissement (MTTR)

Le délai moyen de rétablissement (MTTR) mesure le temps nécessaire à une équipe pour rétablir le fonctionnement normal d'un système après une défaillance dans l'environnement de production.

La capacité à se rétablir rapidement d'une défaillance est essentielle pour les équipes DevOps. Elle exige d'être capable d'identifier rapidement la défaillance, puis de la résoudre sans délai. L'amélioration de l'observabilité, c'est-à-dire la mise en place de systèmes garantissant l'identification rapide des défaillances, est une mesure utile pour améliorer le délai moyen de rétablissement.

Bien sûr, plus le MTTR est court, mieux c'est. Les équipes les plus performantes sont capables de se rétablir d'une panne en moins d'une heure. Toutefois, la plupart des équipes ont besoin de plusieurs heures, voire d'une journée entière.

Pour améliorer cette métrique, les équipes doivent élaborer un plan d'action clair pour la résolution des défaillances et s'assurer que chaque membre de l'équipe comprend le processus.

Taux de défaillance des changements (CFR)

La quatrième et dernière métrique DORA est le taux de défaillance des changements (CFR), dont le calcul indique le pourcentage de déploiements qui ont provoqué une défaillance en production. Le CFR est déterminé en divisant le nombre d'incidents par le nombre total de déploiements.

Quand on met la pression aux équipes pour qu'elles livrent le travail et implémentent les changements rapidement, il est inévitable qu'un certain nombre de bugs ou d'anomalies échappent à leur vigilance. Si le CFR est élevé, cela indique que cette situation est fréquente, et la qualité s'en ressent très probablement. Selon le rapport State of DevOps 2021, la plupart des équipes font état d'un taux de défaillance des changements compris entre 0 et 15 %.

Ainsi, le CFR sert de contrepoint critique aux métriques de fréquence de déploiement et de délai d'exécution des changements, qui se focalisent sur la vitesse. Déployer fréquemment est une bonne chose, mais pas si cela implique de sacrifier constamment la qualité – et de devoir passer du temps à corriger les problèmes qui s'ensuivent. En analysant le CFR, les responsables peuvent s'assurer que les équipes optimisent à la fois la stabilité et le rendement.

La plupart des approches suggérées pour améliorer les autres métriques DORA sont aussi valables pour le taux de défaillance des changements : réduction de la taille des lots, automatisation des processus de test et amélioration de l'efficacité des processus de revue du code.

Peter Drucker, expert en management, aurait dit : « Si vous ne savez pas le mesurer, vous ne pourrez pas le gérer. » Les métriques DORA permettent aux équipes d'ingénierie et DevOps d'augmenter considérablement leur efficacité en leur offrant un moyen standardisé de comparer leur performance à celles des autres équipes et d'identifier des axes d'amélioration spécifiques.

Optimiser la performance de chacun des quatre indicateurs DORA est un moyen éprouvé de gagner à la fois en stabilité, en qualité et en vitesse. Le suivi de la fréquence de déploiement et du délai d'exécution des changements permet aux équipes de gérer la capacité, d'améliorer la fiabilité et de livrer de la valeur de façon régulière.

Les efforts d'amélioration du délai moyen de rétablissement peuvent contribuer à garantir la satisfaction des clients et à prévenir les pertes de clientèle. En surveillant l'évolution du taux de défaillance des changements dans le temps, les responsables peuvent s'assurer que les équipes optimisent non seulement la vitesse, mais aussi la qualité.

La maîtrise des métriques DORA aide les équipes à publier du code de qualité rapidement et en toute confiance. Cependant, elles ne permettent pas de savoir si votre équipe fournit la bonne valeur et les bons résultats métiers, c'est-à-dire ce dont le client a besoin et ce qu'il veut. Les métriques DORA optimisent une petite partie d'un processus beaucoup plus étendu : le parcours de bout en bout d'une demande, depuis sa réception jusqu'à la mise en production associée.

Les métriques DORA aident les équipes DevOps à optimiser la vitesse, la qualité et la stabilité dans le développement et la livraison de logiciels, mais pas à rester alignées sur les résultats commerciaux, comme les revenus ou la fidélisation des clients. Le maintien de cet alignement est pourtant essentiel. En effet, la rapidité avec laquelle vous pouvez déployer du code n'a pas d'importance si le code n'est pas aligné sur de la valeur métier réelle.

Pour optimiser véritablement la valeur pour le client, les équipes doivent être en mesure de comprendre et de visualiser le processus de développement dans son intégralité. Dans le domaine de la livraison de logiciels, ce concept est appelé Value Stream Management (VSM). Mik Kersten, CTO de Planview, a créé le Flow Framework® pour offrir aux organisations logicielles un moyen de mesurer et d'optimiser la livraison de valeur métier sur l'ensemble de la chaîne de valeur.

« Mesurer une seule partie de la chaîne de valeur, c'est comme n'utiliser que 5 cm d'une règle de 30 cm. »

– John Willis, directeur senior du Global Transformation Office chez Red Hat, co-auteur de The DevOps Handbook, podcast Mik + One: Project to Product, épisode 17

Le Flow Framework est fondé sur la nécessité de mesurer le flux de bout en bout de valeur métier et les impacts qui en découlent. Les Flow Metrics permettent d'évaluer le flux de valeur métier à travers toutes les activités qui contribuent à la chaîne de valeur logicielle. En mesurant la corrélation entre les Flow Metrics et les résultats métiers, les organisations peuvent évaluer l'impact de leurs investissements et identifier les domaines où le flux et les cycles de feedback sont trop lents pour réagir face aux changements du marché et à la concurrence.

Les Flow Metrics permettent de déterminer avec prévision si le flux d'une chaîne de valeur est adéquat pour soutenir les résultats métiers souhaités (revenus, réduction des coûts, satisfaction client, engagement des collaborateurs, etc.). Elles évaluent ainsi la cadence de livraison de valeur métier pour des produits logiciels, du point de vue de vos clients (internes ou externes).

Il existe quatre Flow Metrics principales pour mesurer les chaînes de valeur produit :

1. La métrique Flow Velocity® (vélocité du flux) permet d'évaluer si la création de valeur accélère ou ralentit. Elle correspond au nombre d'éléments de flux (fonctionnalités, anomalies, risques et dettes) accomplis sur une durée spécifique.
2. La métrique Flow Time (durée du flux) mesure le temps qui s'écoule entre le début et la fin du travail pour un élément de flux donné, temps d'activité et d'attente compris. Sa valeur est donc équivalente au time-to-market.
3. La métrique Flow Efficiency® (efficience du flux) met en évidence les gaspillages dans une chaîne de valeur. Elle correspond au ratio du temps d'activité au regard de la durée totale du flux.
4. La métrique Flow Load® (charge du flux) permet de repérer les problèmes de surutilisation ou de sous-utilisation des chaînes de valeur, susceptibles de nuire à la productivité. Pour cela, elle mesure le nombre d'éléments de flux en cours (actifs ou en attente) au sein d'une chaîne de valeur donnée.

À ces quatre Flow Metrics s'ajoute l'indicateur Flow Distribution® (répartition du flux), qui mesure la proportion de chaque type d'éléments de flux (fonctionnalités, anomalies, risques ou dettes) réalisés au cours d'une période particulière.

Les Flow Metrics présentées dans le Flow Framework n'ont pas vocation à remplacer les métriques DORA, mais plutôt à les compléter. Comme pour tout processus, vous avez besoin de données pertinentes et complètes pour déterminer la rapidité à laquelle vous livrez, ce qui vous ralentit et ce que vous pouvez faire pour vous améliorer à chaque étape.

En combinant métriques DORA et Flow Metrics, les équipes peuvent créer une visibilité holistique sur l'ensemble du processus de livraison de logiciels et s'assurer qu'elles optimisent non seulement la vitesse et la qualité, mais aussi la valeur et les résultats métiers.