Maîtriser les métriques DORA : guide pratique pour mesurer et améliorer la livraison de logiciels

Mesurer les indicateurs DORA

Collecte de données : manuelle ou automatisée

La collecte automatisée des données est le meilleur moyen d'éviter des mesures inexactes qui conduisent ensuite à de mauvaises décisions commerciales. Cependant, l'automatisation de chaque paramètre impliqué dans le calcul d'un indicateur peut s'avérer impossible en raison de certaines contraintes. Dans ce cas, convenez d'une approche manuelle raisonnable et conforme aux normes de l'industrie.

Délai de livraison :

Mesuré en fonction du temps nécessaire à une fonctionnalité pour passer d'une demande métier à la production. Cela peut être mesuré en utilisant plusieurs outils à chaque étape.

• Automatisez les tests et les déploiements (pipelines CI/CD).
• Réduisez la taille des lots (modifications plus petites et plus fréquentes).
• Améliorez les processus de révision et d'approbation du code.
• Surveillez les goulets d'étranglement (par exemple, cycles de QA longs, approbations manuelles)

Méthode manuelle :

Lorsque les outils ou extensions requis ne sont pas disponibles pour le calcul automatisé du délai de livraison, une approche manuelle peut être adoptée. Vous pouvez calculer manuellement le délai de livraison dans Azure DevOps (ADO) ou des systèmes similaires à l'aide d'extractions de données brutes. Voici une approche étape par étape :

Extraction de données

• Source : requête d'élément de travail ADO ou API.

Périmètre :

• Filtrer pour ne garder que les Fonctionnalités / User Stories marquées comme Terminées (c'est-à-dire déployées en production).

Extraction :

• Date de création (lors de la demande de l'élément de travail).
• Date de clôture/fin (lors du passage au statut « Terminé »).

Formule du délai de réalisation (Lead time) pour une fonctionnalité ou une User Story :

• Délai de réalisation (par élément) = Date de clôture - Date de création

Formule pour la moyenne au niveau du projet :

• Délai de réalisation moyen = Somme des délais de réalisation par élément ÷ Nombre total d'éléments

* Remarque : Dans les cas où des fonctionnalités planifiées sont créées à l'avance, la mesure du délai de réalisation ne reflète pas fidèlement la réalité ; dans ce cas, le temps de cycle peut être utilisé comme alternative.

Fréquence de déploiement :

• Compter le nombre de déploiements en production sur une période donnée (par exemple, par jour, par semaine ou par mois).

Extraction de données :

• Utiliser des outils CI/CD (par exemple, GitHub Actions) pour consigner le nombre de déploiements.

Formule de la fréquence de déploiement :

• Nombre total de déploiements / Nombre de mois

Formule pour la moyenne au niveau du projet :

• Nombre de déploiements du projet / Nombre de mois

*Remarque : Conformément à la définition du secteur, les déploiements de correctifs d'urgence sont exclus du décompte des déploiements.

Taux d'échec des modifications :

Qu'est-ce qui constitue un « déploiement échoué » ?

• Retours en arrière (annulation d'une version en raison de problèmes).
• Correctifs d'urgence (correctifs urgents après le déploiement).

Méthode de suivi :

• Intégration avec les échecs de déploiement du pipeline CI/CD (par exemple, Jenkins, GitHub Actions) pour signaler les anomalies.
• Utilisation d'outils de gestion des incidents (par exemple, ADO, Jira, ServiceNow).

 Formule du taux d'échec des modifications :

• Nombre de modifications échouées ÷ Nombre total de modifications × 100.

Méthode manuelle :

Pour calculer le nombre de modifications ayant échoué, il est possible d'utiliser le nombre d' incidents de support classés comme « Bogue logiciel ». Ce résultat, divisé par le nombre total de modifications déployées, donne le taux d'échec des modifications.

Les organisations doivent faire classer leurs incidents régulièrement pour que la métrique soit exacte.

Délai moyen de restauration (MTTR) :

Qu'est-ce qui compte comme « temps de rétablissement » ?

• Début : Lorsque l'anomalie est détectée (alerte déclenchée).
• Fin : Lorsque le système est entièrement rétabli (par exemple, restauration terminée, correctif d'urgence déployé).

Méthode de suivi :

• Outils de gestion des incidents (par exemple, ADO, Jira).
• Systèmes de surveillance (par exemple, CloudWatch, Prometheus) pour enregistrer les temps de résolution.

Formule pour calculer le MTTR :

• Somme des temps de rétablissement ÷ Nombre d'anomalies

Méthode manuelle :

La somme des temps de rétablissement peut être obtenue à partir des incidents de support classés comme « Bogue logiciel ». L'écart en jours entre la « date de création » et la « date de clôture » peut servir de numérateur.

Le nombre d'incidents classés comme « Bogue logiciel » peut être utilisé comme dénominateur.

Connexion d'ADO, de la CI/CD et des systèmes de surveillance

La collecte régulière de ces métriques et leur optimisation aident les organisations à gagner en efficacité lors de la publication de logiciels.

L'utilisation d'outils efficaces et de plug-ins, ainsi que leur intégration, permet d'automatiser la plupart de ces tâches, de générer des métriques et de prendre les décisions qui s'imposent.

Azure DevOps (ADO) fournit les Metadata nécessaires pour collecter les données brutes permettant de calculer ces métriques. L'équipe DevOps doit procéder à une évaluation minutieuse en tenant compte des besoins commerciaux futurs.

Outils de visualisation et tableaux de bord

Azure DevOps (ADO) propose des fonctionnalités de tableau de bord associées à ces Metadata et à des widgets pour enregistrer certaines de ces métriques. Toutefois, il est essentiel de veiller à ce que les Metadata soient mises à jour pour chaque élément de travail afin de générer des métriques exactes.

D'autres outils, tels que Power BI et Grafana, peuvent être utilisés pour améliorer la visualisation et les rapports destinés aux parties prenantes.

Défis et considérations pour les organisations

Collecte de données et utilisation des outils

Intégrité des données et limites des outils

Défis :

• Sources de données incohérentes : Les pipelines DevSecOps extraient des données d'outils hétérogènes (systèmes CI/CD, scanners, outils de suivi des incidents), ce qui entraîne des calendriers décalés, des faux positifs ou des lacunes.
• Biais de reporting manuel : Les métriques établies par l'homme (par exemple, les rapports d'incidents) manquent souvent de standardisation, ce qui fausse des tendances telles que le MTTR (temps moyen de récupération).

Solution :

• Garantir la traçabilité : Utiliser des Metadata immuables (par exemple, les pipeline IDs d'Azure DevOps, les commits Git) pour extraire les données relatives aux modifications de code.
• Valider par corrélation croisée des outils : Combiner les données de SonarQube (qualité du code), d'ADO pour signaler les anomalies, et les normes industrielles pour valider les données de métriques.

Disponibilité des outils et des plugins

Défi :

• Les organisations peuvent manquer d'accès à des outils DevSecOps intégrés (par exemple, des scanners SAST/DAST, des outils de suivi des déploiements) ou faire face à des coûts de licence élevés.

Solution :

• Utiliser l'offre Azure DevOps Marketplace pour les plugins (par exemple, OWASP ZAP, SonarQube).
• Recourir à des alternatives open source lorsque les budgets sont restreints.

Configuration d'ADO pour la capture des Metadata

Défi :

• Les données brutes d'ADO (compilations, versions, éléments de travail) nécessitent un étiquetage et un lien appropriés pour générer des métriques telles que le Lead Time ou la Deployment Frequency.

Solution :

• Imposer des champs obligatoires dans les éléments de travail et effectuer des mises à jour périodiques.
• Utiliser ADO Analytics Views ou les connecteurs Power BI pour interroger les Metadata du pipeline.

Mises à jour efficaces lors des changements d'état des éléments de travail

Défi :

• Les mises à jour d'état manuelles (par exemple, Terminé → Approuvé) retardent les métriques telles que le Cycle Time.

Solution :

• Automatiser les transitions à l'aide de webhooks ADO ou d'v (par exemple, mise à jour automatique lors de la fusion des PR).
• Associer les états à des seuils DevSecOps (par exemple, l'état d'examen de la sécurité avant le déploiement).

Données insuffisantes pour générer des métriques

Défi :

• Données éparses (ex. : déploiements peu fréquents, faible nombre d'incidents par projet) faussant les tendances.

Solution :

• Définir des seuils minimaux (ex. : « Suivre uniquement si > 5 incidents dans la catégorie des bugs logiciels »).

Métriques non conclueuses pour la prise de décision

Défi :

• Les métriques de vanité (ex. : « MTTR de 120 jours ») ne permettent pas de passer à l'action.

Solution :

• Se concentrer sur des métriques axées sur les résultats étayées par des données suffisantes

Résistance organisationnelle et mauvaise utilisation

Résistance organisationnelle

Défis :

• Crainte d'être exposé : les équipes peuvent refuser des métriques qui mettent en évidence les inefficacités (ex. : un taux d'échec des modifications élevé en raison de rejets de sécurité).
• Surcharge d'outils : l'introduction de nouveaux outils DevSecOps, de Metadata à capturer et de plugins (ex. : analyseurs SAST) peut susciter des réticences si elle est perçue comme perturbatrice ou inutile.
• Incitations mal alignées : la direction récompense une métrique au détriment des autres. Le « délai de livraison » pris isolément peut induire en erreur.

Stratégies d'atténuation :

• Présenter les métriques comme des outils d'amélioration :
  • Mettre l'accent sur la manière dont ces métriques aident l'organisation à long terme et permettent de comparer ou de mesurer les performances.
• Indicateurs pilotes :
  • Commencez par des projets non critiques pour démontrer leur valeur avant un déploiement à l'échelle de l'entreprise, et concentrez-vous sur des indicateurs qui offrent une valeur commerciale.

Objectifs à long terme de l'organisation par rapport aux résultats issus des indicateurs

Défi :

• Désalignement : L'optimisation des indicateurs à court terme (par exemple, l'amélioration de la fréquence de déploiement) peut entrer en conflit avec les objectifs à long terme (par exemple, la réduction de la dette technique ou la maturité en matière de conformité).
• Indicateurs de vanité et création de valeur : Les équipes peuvent privilégier les indicateurs flatteurs au détriment de résultats significatifs.

Solution :

Décliner les indicateurs par thèmes stratégiques :

• Associer les indicateurs (par exemple, le délai de réalisation) aux objectifs commerciaux (par exemple, « une mise sur le marché plus rapide pour les produits soumis à des exigences de conformité strictes »).

Défi :

Le piège des indicateurs lors de la définition de la feuille de route : se focaliser outre mesure sur un seul indicateur (par exemple, le MTTR) peut amener à négliger des problèmes systémiques (par exemple, une automatisation des tests inadéquate).

Solution :

Portefeuilles d'indicateurs pondérés :

• Équilibrer les indicateurs avec les objectifs à long terme de l'organisation (par exemple, la fréquence de déploiement) et la stabilité (le taux d'échec des modifications) par rapport au délai de réalisation

Concilier les indicateurs et la culture d'équipe

Les risques culturels d'une sur-quantification

Défis :

• Crainte de la mesure : Les équipes peuvent percevoir les indicateurs comme une surveillance, ce qui engendre du stress et un risque d'épuisement professionnel.
• Manipulation du système : La pression pour atteindre les objectifs (par exemple, la fréquence de déploiement) peut inciter à prendre des raccourcis (par exemple, ignorer les analyses de sécurité).
• Étouffement de l'innovation : Un accent excessif sur les indicateurs peut décourager l'expérimentation (par exemple, la crainte que des échecs de déploiement n'affectent le taux d'échec des modifications).

Solution :

• La sécurité psychologique avant tout :
  • Soulignez que les indicateurs sont des outils de diagnostic et non des évaluations de performance.
  • Célébrez l'apprentissage par l'échec (par exemple, des analyses post-incident qui permettent d'améliorer le MTTR).
• Conception des indicateurs par l'équipe :
  • Impliquez les ingénieurs dans le choix des indicateurs (par exemple, laissez-les choisir entre le délai de réalisation et le délai de cycle comme priorité par rapport au taux d'échec des modifications).

Indicateurs et compétences des équipes : besoins de formation

Lacunes en matière de compétences entravant le suivi des indicateurs

Défi :

Les équipes manquent de compétences pour améliorer les indicateurs clés (par exemple, un délai de réalisation lent en raison d'une méconnaissance des outils de sécurité).

Solutions :

• Segmentation des indicateurs selon les compétences :
  • Exemple : suivre le délai de réalisation de manière distincte pour les équipes qui adoptent de nouveaux outils d'analyse statique du code source (SAST).
• Formation juste à temps :
  • Automatisez le déclenchement des formations (par exemple, si le taux d'échec des pipelines lié à la sécurité dépasse 15 %, attribuez une formation modulaire).
• Indicateurs de mentorat :
  • Mesurez le % de sessions de programmation en pair programming pour encourager le partage des connaissances.

Indicateurs ignorant la croissance de l'équipe

Défi :

• Mettre trop l'accent sur les indicateurs de production (par exemple, la fréquence de déploiement) dévalorise le développement des compétences.

Solutions :

• Équilibrer les indicateurs de production et de croissance :
  • Associez la fréquence de déploiement au % de l'équipe contribuant au code du pipeline.
• Indicateurs de parcours professionnel :
  • Exemple : suivez le % d'ingénieurs menant des examens de sécurité pour encourager la responsabilisation.

Références

• Accelerate par Forsgren, Humble & Kim
• Documentation Azure DevOps
• Rapports de recherche et d'évaluation DevOps (DORA)