Explorer l’amélioration continue

Effectué

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 Accélérera la transformation numérique, publié en 2017, montre des pertes significatives entre le temps 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.

Le diagramme montre des pertes significatives entre le délai de 123 jours et le temps de processus de 39 jours. Cela équivaut à un délai d’attente de 84 jours.

Source : Forrester, Faster Software Delivery Accélérera la transformation numérique, le 9 mars 2017 par 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.

Le diagramme montre qu’il n’y a qu’un chevauchement de 35% entre les fonctionnalités testées et celles utilisées.

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 devons 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 créer une amélioration continue des performances de la livraison de logiciels.

Mesures et métriques

Tout d'abord, considérons la mesure. Selon le livre Accelerate by Nicole Forsgren, Jez Humble et Gene Kim, les quatre mesures les plus importantes des performances de livraison de logiciels sont les suivantes :

  • Délai de modification : une mesure de la cadence des performances de livraison de 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, cohérence de l’équipe, capacités du développeur, efficacité de l’outil de développement et efficacité globale de l’équipe DevOps.
  • Temps moyen de restauration : durée de restauration générale d’une application ou d’un service principal lorsqu’un incident de service se produit.
  • Pourcentage d’échec des modifications : pourcentage de modifications apportées à la production (y compris, par exemple, les versions logicielles et les modifications de configuration de l’infrastructure) qui échouent.

Il incombe au leadership devOps de mesurer des éléments tels que les métriques d’intégrité opérationnelle, l’utilisation, la vélocité et l’intégrité du site en direct. 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, et non l’activité !

Choses que nous mesurons :

Usage

Vitesse

État de santé du site

  • Acquisition
  • Engagement
  • Satisfaction
  • Attrition
  • 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

Les choses que nous ne regardons pas :

  • Estimation d’origine
  • Heures effectuées
  • Lignes de code
  • Capacité de l’équipe
  • Burndown de l’équipe
  • Vitesse 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 du client : tous les efforts doivent avoir un impact direct ou indirect sur la valeur du client.
  • État d’esprit de production : état d’esprit qui ne différencie pas la façon dont les fonctionnalités et les bogues sont gérés pendant le développement, les tests 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 des tests et de la sécurité aussi tôt que possible dans le cycle de livraison des fonctionnalités, avec un état d’esprit 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 métier. Les métriques soutiennent les indicateurs de performance clés, qui doivent s’aligner sur les habitudes pour atteindre les résultats métier. Les exemples d'indicateurs de performance clés incluent le délai de livraison, la fréquence de déploiement, le temps moyen de restauration et le taux d’échec des modifications. Ces indicateurs de performance clés doivent être alignés sur des habitudes telles que : l'autonomie de l'équipe et l'alignement organisationnel, le focus client, l'état d'esprit axé sur la production, et déplacer la qualité vers la gauche et rapidement. Cet alignement permet d'obtenir des résultats métier tels qu'un délai plus court pour la commercialisation, une meilleure qualité, moins de déchets et une sécurité de bout en bout.

Feedback continu

Ensuite, examinons comment utiliser des commentaires continus 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érez le code et mesurez les résultats pour collecter des données. La date nous aidera à apprendre et à générer de nouvelles idées. Les commentaires continus réduisent le temps total par le biais de 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. Un flux de valeur est une séquence d’activités qu’une organisation s’engage à livrer sur une demande 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 étapes du processus de livraison. Le délai d’exécution est le temps total sur toutes les étapes. Le temps d’inactivité est le temps entre deux phases. Le processus ou le temps 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.

Nous devons être en mesure d’identifier la différence entre les travaux inutiles et sans valeur ajoutée et les travaux nécessaires mais sans valeur ajoutée pour aider à identifier les modifications futures visant l’amélioration du processus.

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.

Le diagramme montre que le délai d’exécution inclut le temps de traitement inutile et nécessaire sans valeur ajoutée, ainsi que le temps de processus d’ajout de valeur.

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 commencent la transformation et identifient les victoires rapides. L’automatisation permet aux mauvais performants de progresser vers des performants moyens. L’automatisation augmente les exigences de test, qui sont traitées manuellement. Une montagne de dettes techniques bloque le progrès. La dette technique et la complexité accrue entraînent des contrôles manuels et des couches de processus supplémentaires autour des changements, ce qui ralentit le travail. Le travail d’amélioration implacable conduit à l’excellence et à de hautes performances ! Les performeurs de haut niveau et d'élite tirent parti de l’expertise et apprennent de leurs environnements pour voir les sauts de 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.