Délai nécessaire aux changements expliqué (métrique DORA)

Dans l'environnement actuel qui évolue rapidement, l'une des tâches cruciales des équipes de développement de logiciels est d'apporter en permanence une nouvelle valeur ajoutée aux clients. Différentes pratiques ont été introduites pour rendre les équipes d'ingénieurs plus efficaces et plus agiles dans le processus de développement de logiciels. Pour les équipes logicielles, il est très important d'intercepter les changements requis et de mettre en œuvre les nouvelles fonctionnalités logicielles en douceur.

Dans cet article, nous développons la métrique du délai d'exécution des changements, l'une des métriques clés de DORA.

Introduction aux métriques DORA

Tel que discuté dans les articles précédents, menés par l'enquête State of DevOps, en 2015 Google a établi le programme appelé DORA (DevOps Research and Assessment). En 2018, ils ont publié leur livre Accelerate introduisant les métriques DORA, un concept qui définit 4 métriques clés qui peuvent distinguer les équipes de développement très performantes des équipes moyennes :

• La fréquence de déploiement (Deployment Frequency ou DF) - mesure la fréquence à laquelle le code est déployé avec succès dans un environnement de production. Les équipes d'ingénieurs logiciels ont tendance à livrer de nouvelles fonctionnalités aux clients dès que possible, et cette mesure est donc utile pour comprendre à quelle fréquence cela se produit.
• Le délai nécessaire aux changements - cette mesure indique le temps nécessaire pour qu'une modification apparaisse dans l'environnement de production en examinant le délai moyen entre la première validation effectuée dans l'environnement de développement et le moment où cette fonctionnalité est exécutée avec succès dans l'environnement de production.
• Le délai de récupération après un échec de déploiement (aussi connu comme le temps de rétablissement du service ou le temps moyen de récupération) - mesure le temps nécessaire au système pour se rétablir d'un incident en production. Pour améliorer le délai de récupération après un échec de déploiement, DevOps doit constamment observer l'environnement de production.
• Le taux d'échec des changements (Change failure rate ou CFR) - mesure le pourcentage de déploiements provoquant un échec en production, et se calcule en divisant le nombre d'échecs par le nombre total de déploiements.

Les métriques DORA donnent aux chefs d'équipe des informations véridiques, qu'ils peuvent analyser pour évaluer la performance de l'équipe. Ils peuvent alors améliorer leurs processus internes. En examinant le CFR et le délai de récupération après un échec de déploiement, les responsables peuvent s'assurer que leur code est robuste et stable, tout en réduisant les défaillances. D'autre part, le suivi du DF et du LTFC permet de s'assurer que l'équipe travaille à un bon rythme. Combinées, les mesures DORA fournissent des informations cruciales sur la qualité et la rapidité de l'équipe.

Qu'est-ce que le délai nécessaire aux changements - définition

Comme indiqué plus haut, le délai nécessaire aux changements mesure le temps requis pour qu'un changement apparaisse dans l'environnement de production. Imaginez que vous êtes en train de développer une fonctionnalité. Vous l'avez apportée au sprint, puis quelqu'un a commencé à travailler dessus. Une fois que le développeur est satisfait, il ouvre la demande de fusion, celle-ci est vérifiée et, enfin, votre fonctionnalité atterrit dans la branche principale. Combien de temps faut-il pour passer de la validation à la branche principale, puis à la version de production? C'est le temps nécessaire pour effectuer le changement. Moins, c'est mieux.

Pourquoi le délai nécessaire aux changements est important?

Cette métrique aide les équipes à produire des versions de code efficaces en identifiant les obstacles et en optimisant les processus de développement. Il peut également être utilisé pour fixer un calendrier réaliste et prendre des décisions concernant les délais de livraison futurs et l'achèvement du projet. Un faible délai de modification permet de réduire le gaspillage et d'optimiser le processus de livraison du logiciel. En identifiant et en éliminant les bloquants, votre équipe peut réduire efficacement le temps et les ressources nécessaires à la livraison de nouvelles fonctionnalités.

En outre, un délai nécessaire aux changements réduit peut vous aider à atténuer les risques en permettant des mises à jour plus fréquentes et moins nombreuses. Les tests et le retour d'information sont ainsi plus rapides, ce qui réduit la possibilité de déployer des bogues ou des problèmes majeurs.

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

Le délai nécessaire aux changements est calculé en mesurant le temps qui s'écoule entre le moment où un changement est demandé et le moment où il est livré à la production. Pour calculer manuellement le délai nécessaire aux changements, il convient de suivre les étapes suivantes :

• Déterminer les points de départ et d'arrivée du processus de demande de changement. Cela peut varier d'une organisation à l'autre, mais le processus commence généralement par une demande de changement et se termine lorsque le changement est déployé dans la production.
• Attribuer et mémoriser un marqueur temporel des points de départ et d'arrivée d'une demande de modification donnée.
• Calculez la différence de temps entre les points de départ et d'arrivée, ce qui vous donnera le délai d'exécution du changement.

Ce processus peut être répété pour plusieurs demandes de changement au cours d'une période donnée, par exemple une semaine ou un mois. Vous pouvez ensuite analyser les données afin d'identifier les tendances et les points à améliorer. Le délai d'exécution des modifications peut varier en fonction de l'ampleur des modifications et des processus impliqués dans la mise en production. Il est donc important de suivre régulièrement le délai d'exécution au fil du temps afin d'en déterminer les améliorations ou les diminutions.

Exemple :

• Vous avez reçu une demande de changement qui a été soumise le 1^er octobre. L'équipe a terminé et déployé le changement en production le 15 octobre. Le délai d'exécution de cette modification est de 14 jours.

• Vous avez reçu une autre demande de modification le 5 octobre. La modification a été achevée et mise en production le 10 octobre. Le délai d'exécution de cette modification est de 5 jours.

Au cours du mois d'octobre, il y a eu au total 2 demandes de changement avec des délais allant de 5 à 14 jours.

Qu'est-ce q'un bon délai nécessaire aux changements?

Comme nous l'avons dit, différentes équipes peuvent considérer différentes valeurs de délai nécessaire aux changements comme bonnes ou acceptables pour elles. Néanmoins, DORA publie un rapport annuel indiquant le niveau de performance des meilleures équipes pour cette mesure. voici ses conclusions :

• Équipes élites - délai inférieur à 1 heure
• Équipes très performantes - délai entre 1 heure et 1 semaine
• Équipes moyennement performantes - délai entre 1 semaine et 6 mois
• Équipes peu performantes - délai de plus de 6 mois

Quel est la différence entre le délai de livraison, le temps de cycle et le délai nécessaire aux changements?

Dans la terminologie DevOps, il existe des définitions distinctes pour le délai de livraison et le délai nécessaire aux changements. Outre le délai d'exécution des modifications, le délai d'exécution mesure le temps nécessaire pour passer de la demande d'un client à la réalisation de cette demande. Il existe également un délai de cycle qui mesure le temps qu'il faut à votre équipe pour achever des éléments de travail dès qu'elle commence à y travailler activement.

Le délai nécessaire aux changements mesure le temps qui s'écoule entre le premier engagement et la livraison de la modification, et il s'agit d'un délai approximatif. Il a néanmoins ses avantages : c'est la mesure la plus simple des trois pour évaluer la performance des pipelines CI/CD. Elle permet également d'éviter l'incertitude qui caractérise les premières étapes du cycle de vie du développement logiciel.

Lorsque vous choisissez la métrique à mesurer, vous devez vous intéresser à la visibilité de bout en bout de votre processus, et donc prendre en compte le lead time et le cycle time.

Quelles sont les causes d'un délai nécessaire aux changements élevé?

Les causes d'un délai nécessaire aux changements élevé sont multiples et nous énumérons ici les principales :

• Exigences floues du client
• Mauvaise définition du terme «prêt»
• Changements importants requis et apportés au code
• Processus de tests manuels
• Processus de développement inefficace (par exemple, blocs, dépendances, code hérité)
• Goulots d'étranglement et chemins complexes inutiles vers la production

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

Pour améliorer votre délai nécessaire aux changements, vous pouvez suivre les conseils suivants :

• Des changements plus petits et indépendants - travailler avec des versions plus petites des changements permet aux développeurs d'obtenir une rétroaction plus rapide et de résoudre les problèmes plus tôt.
• Hiérarchisation des changements - établir des priorités en fonction de la valeur commerciale et de l'impact permet de s'assurer que les changements de grande valeur seront réalisés rapidement.
• Automatisation des processus - vous réduirez les délais en automatisant les tâches répétitives et fastidieuses telles que les tests, le déploiement et l'approvisionnement.
• Réduction des transferts - chaque transfert dans le processus de changement augmente le délai d'exécution. Pour maintenir de faibles délais, essayez de minimiser le nombre de transferts entre les équipes et les départements.
• Normalisation des processus - l'utilisation d'outils et de technologies cohérents réduit la variabilité et augmente l'efficacité, ce qui permet de réduire les délais.
• Contrôle et analyse continus des données relatives aux délais - cela vous permettra d'identifier les facteurs de blocage et les améliorations à apporter aux processus afin de réduire davantage les délais.
• Améliorer la communication - assurer une communication claire entre les parties prenantes et les équipes afin d'éviter les malentendus et les retards, qui peuvent augmenter les délais.

Une façon simple de mesurer le délai nécessaire aux changements

Axify est une plateforme unique permettant d'observer tous les indicateurs clés de performance qui vous aideront à améliorer vos processus de développement et de livraison. Elle est équipée de tableaux de bord de qualité supérieure et permet un suivi constant des indicateurs DORA en temps réel, ce qui simplifie l'ensemble du processus et permet aux équipes de se concentrer sur les améliorations à apporter.

Les fonctionnalités d'Axify incluent les quatre mesures DORA :

• Fréquence de déploiement - mesure la fréquence à laquelle une organisation réussit à déployer en production. Cette mesure importante facilite les tests, les déploiements, les rétroactions et les retours en arrière, tout en augmentant la valeur perçue par les clients.
• Délai d'exécution des changements - temps écoulé entre la première validation et l'exécution réussie du code en production. Cette mesure nous permet d'évaluer l'efficacité des cycles et des initiatives de développement de logiciels. Il tend à entraîner des changements organisationnels, humains et techniques.
• Taux d'échec des changements - mesure le pourcentage de déploiements entraînant un échec en production, et se calcule en divisant le nombre d'échecs par le nombre total de déploiements.
• Délai de récupération après un échec de déploiement - mesure le temps nécessaire au système pour se remettre d'un incident en production.

Les calculs manuels peuvent vous fournir des informations utiles, mais un outil automatisé comme Axify peut modéliser le comportement du système de manière pronostique et suivre le délai d'exécution des changements sans effort. Garder un œil sur le délai d'exécution des changements vous donnera des indications sur le rythme de travail de l'équipe. En faisant des efforts diligents pour réduire ce taux, vous réduirez le gaspillage et optimiserez le processus de livraison de logiciels, ce qui se traduira par des opérations rationalisées et une équipe satisfaite.