Que sont les indicateurs DORA ?

Dans cet article, nous allons nous plonger dans le monde des métriques DORA, en explorant leur signification et la façon dont elles peuvent être exploitées pour favoriser l'excellence dans la livraison de logiciels.

Au sein du développement de logiciels, il y a toujours eu des tensions entre les équipes de développement et les é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" - d'où le terme DevOps.

DevOps a été largement adopté depuis sa création en 2007-2008. Une poignée de leaders du mouvement DevOps ont publié le rapport State of DevOps Report de 2014-2017, et se sont ensuite regroupés pour former une start-up appelée DevOps Research and Assessment - également connue sous le nom de DORA. (DORA a depuis été racheté par Google Cloud et continue de publier le rapport annuel).

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

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

• Fréquence de déploiement (DF)
• Délai de mise en œuvre des changements (LT)
• Temps moyen de rétablissement (MTTR)
• Taux d'échec des changements (CFR)

L'équipe DORA a identifié ces mesures critiques comme ayant le plus grand impact sur le développement et la livraison de logiciels, sur la base des réponses à une enquête menée auprès de plus de 31,000 professionnels sur une période de six ans.

Les quatre indicateurs DORA permettent aux responsables de l'ingénierie d'évaluer les performances de leurs équipes par rapport à d'autres dans l'industrie, c'est-à-dire de déterminer s'il s'agit d'équipes "d'élite" ou d'équipes susceptibles d'être améliorées (équipes très performantes, moyennement performantes et peu performantes). Ces informations permettent aux dirigeants d'identifier les possibilités d'amélioration et d'apporter les changements nécessaires.

Fréquence de déploiement (DF)

La fréquence de déploiement (DF) est une mesure du débit moyen. Il s'agit de la fréquence moyenne à laquelle le code est déployé en production sur une période donnée. La fréquence de déploiement peut être utilisée pour évaluer la fréquence à laquelle une équipe d'ingénieurs apporte 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 de manière cohérente et rapide.

Mesurer la fréquence des déploiements au fil du temps peut aider les équipes à identifier les moyens d'améliorer leur rapidité de livraison. DORA a notamment constaté que les équipes DevOps les plus performantes ont tendance à effectuer des déploiements plus petits et plus fréquents (par opposition à des déploiements plus importants et moins fréquents).

Les équipes DevOps peuvent utiliser leurs métriques DF pour comparer leurs performances à celles d'autres équipes. Les équipes très performantes se déploient en moyenne une fois par semaine, tandis que les équipes les plus performantes peuvent se déployer plusieurs fois au cours d'une même journée.

Si une équipe obtient de mauvais résultats dans ce domaine, elle peut utiliser cette information pour identifier des moyens spécifiques d'amélioration : Par exemple, en divisant le travail en lots plus petits ou en créant des requêtes plus petites.

Délai de mise en œuvre des modifications (LT)

Le délai de mise en œuvre des changements (LT), ou délai moyen de mise en œuvre des changements (MTLC), mesure le temps qu'il faut à une équipe pour mettre en œuvre un changement une fois que le codage a commencé.

Le délai d'exécution des modifications est mesuré en suivant le temps qui s'écoule entre le moment où un engagement est pris pour une modification et le moment où cette modification est mise en production. Le délai moyen de changement est la moyenne de tous les changements apportés au cours d'une période donnée.

La mesure du MLTC est importante car elle quantifie le temps qu'il faut à une équipe pour livrer le travail aux clients. Une mauvaise performance dans ce domaine signifie qu'une équipe n'est pas en mesure de mettre en œuvre les changements de manière fiable et en temps voulu.

Comme d'autres mesures DORA, le délai moyen d'exécution des changements peut être utile pour évaluer les performances d'une équipe. En règle générale, les équipes les plus performantes peuvent mettre en œuvre des changements en l'espace d'une journée, alors que les équipes moyennes ont besoin d'environ une semaine. La compréhension de cette mesure peut aider les dirigeants à mieux appréhender la capacité de l'équipe et à ajuster les attentes de manière réaliste lorsque des changements surviennent.

De nombreux facteurs peuvent affecter le MLTC, c'est pourquoi il est important d'analyser les métriques de délais correspondant à 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 comprendre où se situent les goulets d'étranglement.

Si une équipe n'est pas satisfaite de son délai de modification, elle peut essayer de diviser le travail en lots plus petits, de créer des demandes de retrait plus petites, d'améliorer son processus d'examen 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 panne survenue dans l'environnement de production.

La capacité à se remettre rapidement d'une défaillance est une capacité essentielle pour les équipes DevOps. La récupération comporte deux éléments clés : la capacité d'identifier rapidement une défaillance et la capacité de la résoudre. 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.

En ce qui concerne le MTTR, plus il est rapide, mieux c'est. Les équipes les plus performantes peuvent être en mesure de se remettre d'une panne en moins d'une heure. Cependant, la plupart des équipes ont besoin de plusieurs heures, voire d'une journée entière.

Pour améliorer cet indicateur, les équipes doivent élaborer un plan d'action clair pour remédier aux échecs et veiller à ce que chaque membre de l'équipe comprenne le processus.

Modification du taux d'échec (CFR)

La quatrième et dernière mesure DORA est le taux d'échec des changements (CFR), qui est un calcul conçu pour quantifier le pourcentage de déploiements qui ont provoqué un échec en production. Le CFR est déterminé en divisant le nombre d'incidents par le nombre total de déploiements.

Lorsque les équipes sont sous pression pour livrer le travail et mettre en œuvre les changements rapidement, il est inévitable que certains bogues ou défauts ne soient pas détectés. Si le CFR est élevé, cela indique que cette situation est fréquente et que la qualité s'en ressent. Selon le rapport 2021 State of DevOps, la plupart des équipes font état d'un taux d'échec des changements de 0-15%.

De cette manière, le CFR sert de contrepoint critique aux autres mesures DORA, qui se concentrent sur la vitesse (c'est-à-dire la fréquence de déploiement et le délai de mise en œuvre des changements). Déployer fréquemment est une bonne chose, mais pas si cela implique de sacrifier constamment la qualité - et de devoir ensuite consacrer du temps à la résolution des problèmes. L'analyse du RCF peut aider les dirigeants à s'assurer que les équipes optimisent à la fois la stabilité et le débit.

De nombreuses approches visant à améliorer le taux d'échec des changements reflètent celles suggérées pour d'autres indicateurs DORA : réduction de la taille des lots, automatisation des processus de test et amélioration de l'efficacité des processus de révision du code.

Peter Drucker, expert en management, aurait dit : "Vous ne pouvez pas gérer ce que vous ne mesurez pas". Les métriques DORA permettent aux équipes DevOps et d'ingénierie d'apporter des améliorations significatives en les dotant d'un moyen standardisé de comparer leurs performances à celles d'autres équipes et d'identifier des opportunités d'amélioration spécifiques et exploitables.

Optimiser la réussite de chacun des quatre indicateurs DORA est un moyen éprouvé de parvenir à la stabilité, à la qualité et à la rapidité. Le suivi de la fréquence de déploiement et du délai de mise en œuvre des changements permet aux équipes de gérer la capacité, d'améliorer la fiabilité et de fournir de la valeur de manière cohérente.

S'efforcer d'améliorer le délai moyen de rétablissement peut contribuer à garantir la satisfaction des clients et à les protéger contre le désabonnement. L'examen du taux d'échec des changements au fil du temps peut aider les dirigeants à s'assurer que les équipes optimisent non seulement la vitesse, mais aussi la qualité.

La maîtrise des métriques DORA peut aider les équipes à produire un code de qualité rapidement et en toute confiance. Cependant, ils ne permettent pas de savoir si votre équipe fournit la bonne valeur et les bons résultats commerciaux, c'est-à-dire ce dont le client a besoin et ce qu'il veut. Les mesures DORA optimisent une petite partie d'un processus beaucoup plus vaste : le parcours de bout en bout, de la demande du client à la publication.

Les mesures DORA aident les équipes DevOps à optimiser la vitesse, la qualité et la stabilité du développement et de la livraison des logiciels, mais elles n'aident pas les équipes à rester alignées sur les résultats commerciaux, tels que le chiffre d'affaires ou la fidélisation des clients. Il est essentiel de maintenir cet alignement. La rapidité avec laquelle vous pouvez déployer du code n'a pas d'importance si ce code n'est pas aligné sur la valeur réelle de l'entreprise.

Pour optimiser véritablement la valeur pour le client, les équipes doivent être en mesure de comprendre et de visualiser l'ensemble du processus de développement, de bout en bout. Dans le domaine de la livraison de logiciels, ce concept est appelé value stream management (VSM). Mik Kersten, directeur technique de Planview, a créé le Flow Framework® pour combler les lacunes en matière de livraison de logiciels, en donnant aux entreprises de logiciels un moyen de mesurer et d'optimiser la livraison de la valeur commerciale dans l'ensemble du flux de valeur.

"Mesurer un seul domaine de la chaîne de valeur revient à n'utiliser que deux pouces d'une règle de 0,5 12pouce.

- John Willis, directeur principal du Global Transformation Office chez Red Hat, co-auteur de The DevOps Handbook, Mik+One : Project to Product Podcast, Episode 17

Le cadre des flux est fondé sur la nécessité de mesurer le flux de bout en bout de la valeur de l'entreprise et les résultats qui en découlent. Les mesures de flux sont utilisées pour évaluer le flux de valeur commerciale à travers toutes les activités qui contribuent à la chaîne de valeur du logiciel. En mesurant la corrélation entre les mesures de flux et les résultats commerciaux, les organisations peuvent évaluer l'impact de leurs investissements et identifier les domaines où les cycles de flux et de retour d'information sont trop lents pour répondre aux changements du marché et à la concurrence.

Flow Metrics offre une évaluation précise de l'adéquation du flux de valeur avec les résultats commerciaux souhaités, tels que le chiffre d'affaires, la réduction des coûts, la satisfaction des clients et l'engagement des employés. Ils évaluent le rythme de livraison de la valeur commerciale des produits logiciels, du point de vue de vos clients (internes ou externes).

Il existe quatre indicateurs de flux clés pour mesurer les flux de valeur des produits :

1. Flow Velocity®  permet d'évaluer si la création de valeur s'accélère ou se ralentit. La vélocité du flux est le nombre d'éléments du flux (caractéristiques, défauts, risques et dettes) réalisés au cours d'une période donnée.
2. Flow Time mesure le temps de mise sur le marché. La durée du flux mesure le temps écoulé entre le "début du travail" et la "fin du travail" pour un élément de flux donné, y compris les temps d'activité et d'attente.
3. Flow Efficiency®  identifie les gaspillages dans une chaîne de valeur. L'efficacité du débit est le rapport entre le temps actif et le temps total du débit.
4. Flow Load®  surveille la sur-utilisation et la sous-utilisation des flux de valeur, ce qui peut entraîner une baisse de la productivité. La charge de flux mesure le nombre d'éléments de flux en cours (actifs ou en attente) dans un flux de valeur particulier.

En plus des quatre indicateurs de flux, Flow Distribution®  permet d'identifier les différents types de travaux réalisés au cours de périodes spécifiques. La répartition des flux mesure le ratio des éléments de flux (caractéristiques, défauts, risques ou dettes) réalisés au cours d'une période donnée.

Les mesures de flux décrites dans le cadre de flux ne sont pas destinées à remplacer les mesures DORA, mais plutôt à les compléter. Comme pour tout processus, vous avez besoin de données significatives et complètes pour comprendre à quelle vitesse vous produisez, ce qui vous ralentit et ce que vous pouvez faire pour vous améliorer à chaque étape.

En combinant les métriques DORA avec les métriques de flux, les équipes peuvent s'assurer qu'elles ont une vision holistique de l'ensemble du processus de livraison de logiciels et qu'elles optimisent non seulement la vitesse et la qualité, mais aussi la valeur et les résultats de l'entreprise.