.png)
Les métriques DORA sont devenues incontournables pour évaluer et améliorer la performance des équipes DevOps. Ces indicateurs clés permettent de mesurer la rapidité, la stabilité et l'efficacité du processus de développement et de déploiement logiciel.
Dans cet article, nous analyserons en profondeur ces métriques, leurs implications pour les équipes techniques, et comment les implémenter efficacement. Que vous soyez CTO, membre de la DSI ou développeur, comprendre et utiliser les métriques DORA est essentiel pour optimiser vos opérations et garantir la livraison continue de valeur à vos utilisateurs finaux.
Voici un exemple de projet pour lequel nous suivons les DORA Metrics chez Yield Studio :
Pour qui ?
Avant d’attaquer le sujet concrètement, commençons par définir la cible de ces métriques.
Contre toute attente, elles sont transverses. Moyennant une bonne application, les métriques peuvent être consultées par la DSI , le CTO ou le management top level mais elles sont belles et bien pilotées par les équipes techniques. Ces métriques sont également essentielles pour les équipes DevOps qui cherchent à améliorer leur collaboration et leur performance globale.
Pourquoi ?
Assez simplement ce sont des métriques, des KPI, des nombres qui portent plus ou moins de contexte et permettent de quantifier la performance des équipes techniques (software team). Bien souvent, la littérature retient 4 métriques au total bien qu’il en existe une 5ème qu’on évoquera rapidement mais qu’on exclura par la suite.
Elles fournissent des informations précieuses sur la rapidité avec laquelle les équipes DevOps peuvent répondre aux changements, le temps moyen pour déployer du code, la fréquence des itérations et les échecs.
Ces indicateurs sont cruciaux pour :
- Fournir des estimations de réponse réalistes
- Améliorer la planification du travail
- Identifier les domaines à améliorer
- Consolider les investissements techniques et en ressources
Les 4 Principales Métriques DORA
- DF (Deployment Frequency)
Il s’agit de la fréquence à laquelle du code est déployé en production sur une période de temps. Précisions tout de même que le code doit être déployé avec succès. S’il faut rollback chaque déploiement ça compte pas.
C’est également un indicateur de fréquence à laquelle les ingénieurs délivrent de la valeur aux utilisateurs finaux.
Plus elle est élevée et plus les utilisateurs profitent vite des incréments de code.
A titre indicatif, une valeur moyenne est de 1 déploiement par semaine.
- MLTC (Mean Lead Time for Changes)
Il s’agit du temps moyen entre le premier commit et le déploiement en production.
Souvent les développeurs doivent repasser plusieurs fois sur le code produit initialement suite notamment à la re-lecture par d’autre développeurs ou pour apporter des corrections demandées par le product owner.
Dans un autre domaine, cette métrique correspond au temps d’immobilisation (stock).
A titre indicatif, une valeur moyenne est de 1 semaine.
- CFR (Change Failure Rate)
Il s’agit du pourcentage de déploiements en production qui causent un problème.
On le calcule en divisant le nombre d’incident par le nombre de déploiements.
A titre indicatif, une valeur moyenne se situe entre 16 et 30%.
- MTTR (Mean Time To Recovery)
Il s’agit du temps moyen nécessaire pour réparer un problème et remettre le système dans un état stable.
A titre indicatif, une valeur moyenne se situe à moins d’un jour.
Une Cinquième Métrique : La Fiabilité
aSouvent oubliée, cette métrique est plus orientée DevOps/SRE et se base sur des objectifs opérationnels/contractuels (SLA). Elle mesure la capacité à atteindre ou dépasser ces objectifs, fournissant une perspective supplémentaire sur la performance opérationnelle.
Comment mettre en place ces métriques ?
Il existe plusieurs approches pour mettre en places ces métriques. La plus simple reste de s’appuyer sur un outil qui les intègre déjà, comme LinearB.
.png)
Qu’importe le flacon l’outil, pourvu que vous commenciez à mesurer.
Et si cela ne marche pas dans mon cas ?
“Oui mais moi ma feature est complexe, il me faut plusieurs semaines pour terminer, je vais biaiser la moyenne gneu gneu gneu …”
- Découpe ta feature et utilise des feature flags pour délivrer de façon incrémentale.
"Oui mais c’est long de tout tester à chaque fois gneu gneu gneu …"
- Sois flemmard et écris des tests pour automatiser ton job.
TL;DR
Les métriques DORA sont des indicateurs de la production de valeur produit/business.
Elles sont applicables aux DevOps comme aux développeurs et intéressent toute la software team. Pour être pertinentes, les développeurs doivent être acteurs du pilotage de ces métriques car aucun manager ne pourra les forcer à cela.
Une observation macro est que les DORA poussent naturellement à réduire les incréments de code. En effet, en envoyant moins de code à chaque déploiement, on mitige le risque et les déploiements sont naturellement plus rapide.
Notons aussi que les DORA ne se suffisent pas à elle même, elles appellent à d’autre bonnes pratiques que sont le respect du manifeste agile https://agilemanifesto.org/, l’ajout de tests ou encore les principes LEAN de Toyota.
Enfin, avis aux néophytes avides de tableau Excel, si les DORA permettent de quantifier un problème, une lame de fond, elles ne le qualifie pas pour autant. Le sujet central reste un sujet humain, on parle d’équipes d’homme et de femme qui ont leur code, leur cohésion, leur problématique propre. Piloter uniquement les DORA pour présenter un Excel “tout au vert” serait naïf et pourrait compromettre l’équipe ciblée.
Et Yield Studio là dedans ?
Selon la classification mentionnée en annexe Yield Studio se situe en “high performer” et s’améliore en continu pour atteindre prochainement le grade “elite”. Et vous, vous vous situez où dans ce tableau ? Aujourd'hui les DORA Metrics nous permettent de garantir une réelle qualité auprès de nos clients dans les projets qu'ils nous confient.
Source
Valeurs indicatives pour chaque DORA metric
.png)
Source: Google Cloud https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance?hl=en
