Explorer l’amélioration continue

  • 5 minutes

L’amélioration continue est l’une des huit fonctionnalités de la taxonomie DevOps.

Découvrez pourquoi l’amélioration continue est nécessaire

L’amélioration continue implique et nécessite des mesures. Comment pouvez-vous constater une amélioration sans effectuer de mesures ?

Le rapport Forrester Faster Software Delivery Will Accelerate Digital Transformation, publié en 2017, fait état d’importants gaspillages dus au rapport entre le délai d’exécution et le temps de traitement. Cela nous rappelle que sans mesures, nous ne pouvons pas nous rendre compte que les processus de notre organisation engendrent du gaspillage, ni dans quelles proportions.

Une fois que vous avez mesuré l’impact qu’ont certaines sources de gaspillage sur le processus, il est facile de hiérarchiser le travail en vue d’apporter des améliorations.

Diagramme montrant un important gaspillage entre le délai d’exécution de 123 jours et le temps de traitement de 39 jours. Cela donne un temps d’attente de 84 jours.

Source : Forrester, Faster Software Delivery Will Accelerate Digital Transformation, 9 mars 2017. Auteurs : Diego Lo Giudice, Christopher Condo, avec Christopher Mines, Luis Deya

Mais alors, comment améliorer l’expérience client sans effectuer de mesures ? D’après l’étude Forrester, « un pourcentage trop faible de chevauchement entre les fonctionnalités testées et les fonctionnalités utilisées est signe que les développeurs ont besoin de meilleurs insights clients ». Les fonctionnalités d’application testées et utilisées se chevauchent à un niveau de 35 % environ.

Diagramme montrant que le chevauchement des fonctionnalités testées et des fonctionnalités utilisées n’est que de 35 %.

Comment pouvez-vous créer un logiciel adapté si vous ne mesurez pas l’utilisation et l’impact des nouvelles fonctionnalités ? Sachant que vous avez une probabilité de 65 % de vous tromper, il est essentiel de mesurer.

Qu’est-ce que l’amélioration continue ?

Le fait d’observer en continu et en toute objectivité votre processus DevOps permet à vos équipes d’identifier les points d’amélioration possibles.

Toute amélioration nécessite des changements, cependant, tous les changements ne constituent pas une amélioration. C’est pourquoi les mesures sont un facteur de réussite critique pour les organisations qui utilisent DevOps. Comme le dit Peter Drucker, « Si vous ne pouvez pas le mesurer, vous ne pouvez pas l’améliorer ».

L’absence d’un système de feedback efficace empêche d’améliorer l’impact des applications sur l’activité. C’est pourquoi il est important de créer un environnement qui favorise une approche centrée sur l’apprentissage pour l’amélioration DevOps, et qui mette l’accent sur un ajustement des données. Le diagramme montre que nous devrions utiliser la mesure et l’impact pour générer une amélioration. La mesure doit entraîner un changement de comportement positif. Les organisations doivent évoluer vers une pratique de l’apprentissage continu et des commentaires pour susciter une amélioration continue des performances en matière de livraison de logiciels.

Mesures et métriques

Commençons par les mesures. Dans leur livre Accelerate, Nicole Forsgren, Jez Humble et Gene Kim décrivent les quatre mesures les plus importantes concernant les performances de livraison des logiciels :

  • Délai d’exécution des changements : mesure la cadence de livraison des logiciels. Le temps nécessaire pour passer du code validé au code s’exécutant correctement en production
  • Fréquence de déploiement : mesure directe ou indirecte du temps de réponse, de la cohésion de l’équipe, des capacités des développeurs, de l’efficacité des outils de développement et de l’efficacité globale de l’équipe DevOps.
  • Temps moyen pour restaurer : durée généralement nécessaire pour restaurer une application ou un service d’importance lorsqu’un incident de service se produit.
  • Pourcentage d’échec des modifications : pourcentage des modifications apportées en production qui échouent (par exemple, aux versions de logiciels ou à la configuration de l’infrastructure).

Il incombe aux responsables DevOps de mesurer des paramètres comme les métriques d’intégrité opérationnelle, l’utilisation, la vélocité ou l’intégrité des sites actifs. Autrement dit, il faut mesurer l’IMPACT, et non l’ACTIVITÉ. Une métrique n’est utile que si elle est exploitable.

Même si les équipes Scrum mesurent la capacité de l’équipe, la vélocité de l’équipe, le burndown et le nombre de bogues, ces métriques ne sont pertinentes que dans le contexte de l’équipe. Il est important pour les responsables DevOps de se concentrer sur l’impact.

Important

Mesurez l’impact, pas l’activité !

Ce que nous mesurons :

Utilisation

Vélocité

Intégrité des sites actifs

  • Acquisition
  • Engagement
  • Satisfaction
  • Évolution
  • Utilisation des fonctionnalités
  • Temps pour générer
  • Temps pour auto-tester
  • Temps pour déployer
  • Temps pour apprendre
  • Temps pour détecter
  • Temps pour communiquer
  • Temps pour atténuer
  • Impact client
  • Éléments de prévention des incidents
  • Problèmes de vieillissement des sites actifs
  • Contrat SLA par client
  • Métriques du support client

Ce que nous ne mesurons pas :

  • Estimation d’origine
  • Heures effectuées
  • Lignes de code
  • Capacité de l’équipe
  • Burndown de l’équipe
  • Vélocité de l'équipe
  • Nombre de bogues trouvés

Important

Les métriques affectent les résultats de l’entreprise.

Il est important d’aligner les indicateurs de performance clés sur les habitudes. Cela permet d’obtenir des résultats opérationnels positifs.

Les habitudes importantes qui permettent de renforcer les indicateurs de performance clés et de garantir la réussite des équipes sont les suivantes :

  • Autonomie de l’équipe et alignement de l’organisation : quoi, comment et pourquoi nous créons. Vous avez besoin d’une cadence (ou pulsation) commune au sein de votre organisation pour permettre à tous les responsables et à toutes les équipes chargées des fonctionnalités de collaborer de manière fluide et efficace.
  • Focus client : tous les efforts doivent avoir un impact direct ou indirect sur la valeur client.
  • Mindset axé sur la production : mindset qui ne gère pas différemment les fonctionnalités et les bogues pendant le développement, le test et le support opérationnel. Tout doit être automatisé, versionné et ajusté en production.
  • Shift-left et fail-fast : encourager les révisions, les validations et les approbations aussi tôt que possible dans le cycle de livraison des fonctionnalités, avec un mindset axé sur la qualité et le fail-fast.

Le diagramme montre la relation entre les métriques, les indicateurs de performance clés, les habitudes et les résultats opérationnels. Les métriques prennent en charge les indicateurs de performance clés (KPI), qui doivent être calqués sur les habitudes pour atteindre les résultats opérationnels. Les exemples de KPI incluent le délai d’exécution, la fréquence de déploiement, le temps moyen de restauration et le taux d’échec des modifications. Ces KPI doivent être calqués sur les habitudes comme : l’autonomie de l’équipe et l’alignement de l’organisation, le focus client, une logique de production et le shift-left et fail-fast. Cet alignement permet d’atteindre les résultats opérationnels comme un délai de mise sur le marché plus rapide, une meilleure qualité, moins de gaspillage et une sécurité de bout en bout.

Feedback continu

Voyons maintenant comment utiliser le feedback continu pour la collaboration.

Les développeurs d’applications modernes dont on parle le plus travaillent dans des start-ups. Pourquoi ont-ils tant de succès ? Parce que leurs pratiques Lean ont été épurées par des années d’affinage de processus.

Les start-ups Lean ont mis au point une méthode optimale permettant de développer, livrer et affiner leurs idées, en créant une incroyable culture de feedback continu positive :

  • Publier tôt et souvent
  • Commencer par un produit minimum viable
  • Utiliser un développement basé sur les hypothèses
  • Permettre l’amélioration continue grâce aux feedback des clients

Le diagramme montre le cycle de commentaires continus. Nous commençons par des idées, générons le code et mesurons les résultats pour collecter des données. Les données nous aideront à apprendre et générer de nouvelles idées. Les commentaires continus réduisent au minimum le temps total grâce à la boucle.

Amélioration continue via la cartographie des chaînes de valeur

Lorsque nous disposons de mesures et de feedback, l’amélioration devient un exercice basé sur les données.

Un moyen efficace d’aider à l’amélioration continue est d’utiliser la cartographie des chaînes de valeur. Une chaîne de valeur est une suite d’activités qu’une organisation s’engage à offrir à la demande d’un client.

La cartographie des chaînes de valeur est un moyen très efficace d’apprendre à détecter et résoudre les déconnexions, les redondances et les écarts dans les méthodes de travail. Ce n’est pas seulement un outil. C’est une méthodologie d’équipe, qui est pour nous le fondement d’une pratique de gestion éprouvée.

L’analyse des chaînes de valeur vous permet de décomposer le processus de livraison afin de mesurer le délai d’exécution, la durée du cycle et le temps d’inactivité. Les équipes peuvent ainsi ajuster le workflow en fonction des données.

Ces mesures aident les équipes à planifier, à repérer les variations d’efficacité et à identifier les problèmes potentiels liés aux processus.

Le diagramme montre les phases du processus de livraison. Le temps d’exécution est le temps total passé dans toutes les phases. Le temps d’inactivité est le temps entre deux phases. Le temps de traitement ou de cycle mesure la durée d’une phase.

Conseil

Plus la durée du processus ou du cycle est courte, plus le flux de production de votre équipe sera rapide.

Pour identifier les changements nécessaires à l’amélioration du processus, nous devons pouvoir faire la différence entre un travail non nécessaire sans valeur ajoutée et un travail nécessaire sans valeur ajoutée.

Un travail non nécessaire sans valeur ajoutée inutile constitue un véritable gaspillage : il n’apporte rien au client, et l’organisation n’en a pas besoin pour rester viable. Il consomme des ressources sans ajouter de valeur au produit.

Diagramme montrant que le délai d’exécution comprend un temps de traitement nécessaire et non nécessaire sans valeur ajoutée, ainsi qu’un temps de traitement avec valeur ajoutée.

DevOps basé sur les données : laissez les métriques guider votre parcours

La transformation DevOps est comme un parcours. Le moyen le mieux adapté et le plus efficace pour trouver votre chemin dans ce parcours DevOps est d’utiliser DevOps en vous basant sur les données.

Le diagramme montre le flux du parcours DevOps. Les équipes se lancent dans la transformation et observent des gains rapides. Grâce à l’automatisation, il est possible de passer d’un niveau de performance faible à un niveau de performance moyen. L’automatisation impose davantage de tests, qui sont gérés manuellement. Une montagne de dettes techniques bloque la progression. La dette technique et la complexité accrue ont pour conséquence d’accroître les contrôles manuels et les couches de processus autour des changements, ce qui ralentit le travail. Le travail d’amélioration incessant conduit à l’excellence et à des performances élevées ! Les équipes hautement performantes et d’élite tirent parti de l’expertise et apprennent de leurs environnements pour observer des bonds en productivité.

Nous vous suggérons d’établir une approche holistique afin de mesurer l’efficacité de DevOps et de permettre la transparence des initiatives de transformation DevOps. Créez une culture qui promeut l’apprentissage et l’expérimentation dont DevOps a besoin en vous concentrant sur les métriques qui mettent en évidence vos réussites. Accueillez ces réussites en vous félicitant des bons comportements plutôt qu’en punissant les mauvais.