Accelerate – State of DevOps 2021 : toujours plus de vitesse malgré la pandémie

Accelerate – State of DevOps 2021 : toujours plus de vitesse malgré la pandémie

Déjà la 8ème édition du Accelerate – State of DevOps Report, ce bilan annuel est l’une des plus larges études disponibles sur les pratiques DevOps et leur lien avec la performance des organisations.

Rappelons-le, suite à la revente de DORA (DevOps Research Assessment) par Jez Humble, Nicole Forsgren et Gene Kim …. à Google en décembre 2020, cette étude est maintenant entièrement rédigée par des salariés de Google (on notera que les noms de Jez et de Nicole figurent toujours dans les remerciements !). Jez Humble, Nicole Forsgren et Gene Kim sont également les auteurs de nombreux ouvrages de référence sur le DevOps dont Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations. Ne soyez donc pas surpris de retrouver des liens entre State of DevOps, DORA et Accelerate !

Pour commencer, cette étude a pour principe de répartir les directions informatiques des entreprises en 4 groupes suivant leur niveau de performance DevOps :

  • Elite performer
  • High performer
  • Medium performer
  • Low performer

Pour ce faire, 32 000 professionnels ont été interviewés: environ 30 % en Europe, avec une bonne répartition entre startups, TPE, PME et grandes entreprises. Ces professionnels sont interrogés sur leurs pratiques et leurs résultats / performance. La grille d’analyse sur les 4 niveaux ci-dessus est construite via l’outil DORA.

Ce qui ne se mesure pas…

Comme le disait le grand Edward Deming : Ce qui ne se mesure pas ne s’améliore pas !

Ces 4 groupes de performers sont donc définis selon 4 indicateurs de performances DevOps également repris dans Accelerate

  • Lead time : temps écoulé depuis le commit du code jusqu’à la mise en production. Sur ce point, le Lean prendrait le point de vue du client : le temps passé de l’expression du besoin (ex: l’idée de feature) jusqu’à sa mise à disposition pour l’utilisateur.
  • Deployment frequency : la fréquence à laquelle du logiciel est mis en production, de plusieurs fois par jour à plusieurs fois par an.
  • Change Fail : le taux d’échec lors d’une mise en production. Par exemple 15 % des mises en production conduisent à une relivraison, à un retour arrière, à des incidents…
  • Time to restore : le temps mis pour réparer un incident depuis son apparition (attention, ce n’est pas le moment où il a été signalé mais l’instant où il est survenu) jusqu’à sa correction définitive.  Encore une fois, on mesure couramment des temps de l’ordre de quelques minutes à plusieurs semaines.

Les deux premiers indicateurs sont liés à la vitesse et les deux suivants à la stabilité.

Enfin, à noter, les auteurs nous rappellent dès l’Executive Summary, que l’amélioration doit être continue plutôt que par à-coups. Je les rejoins complètement sur ce point avec les principes du Kaizen (les petits pas d’amélioration). De plus, les problèmes doivent être quantifiables et factualisés et en se basant sur l’analyse des constraints, une démarche que l’on retrouve dans le PDCA qui vise à poser un problème sous la forme d’un écart à l’objectif pour aller chercher les causes racines.

Les résultats de l’étude

Pour cet article, je me focaliserai sur les pratiques, techniques et la culture plutôt que sur la partie Cloud, trop liée de mon point de vue à l’activité de Google Cloud.

Une fois de plus, les résultats de l’étude montrent que l’écart se creuse profondément entre les Elite / High performers et Medium / Low. Comme les années précédentes, les meilleurs excellent sur tous les plans : vitesse et stabilité. L’ordre de grandeur est de quelques heures pour les premiers à quelque mois pour les seconds.

On imagine immédiatement l’impact de ces chiffres en terme de time-to-market pour ces entreprises et l’impact sur la performance économique.

Voici donc les résultats, je vous recommande de les lire ligne par ligne:

Pour mieux appréhender l’écart de vitesse vertigineux entre High Performers et Low Performers, on peut comparer les 4 mesures suivantes:

Extrait de : state-of-devops2021.pdf, Google Cloud

Entre 2018 et 2019, bonne nouvelle, on constate globalement un glissement vers le haut (High/Elite) assez marqué de la répartition du nombre d’organisations :

Extrait de : state-of-devops2021.pdf, Google Cloud

Et moi, et moi, et moi…

Vous êtes curieux de savoir dans quelle catégorie, votre équipe ou votre DSI se situe ?
Alors prenez une minute pour répondre aux cinq questions anonymes de DORA (pas de formulaire à remplir !) :

https://www.devops-research.com/quickcheck.html

Vous obtiendrez une première estimation du niveau de performance dans votre secteur d’activité :

Ainsi qu’un comparatif par rapport aux autres performers de la catégorie et quelques pistes de réflexions pour la suite.

Quelles pistes d’amélioration en 2021 dans ce rapport ?

Qualité de la documentation

Voilà une nouveauté, la documentation étant souvent le parent pauvre des approches Agiles, XP, Craft et DevOps. L’étude met en évidence l’importance de la qualité de la documentation dont l’objectif est d’aider les utilisateurs à réussir leurs tâches. En Lean, on appelle cela un standard de travail : la meilleure façon connue par l’équipe à ce jour pour réussir telle tâche. Un peu comme une recette de cuisine qui permet de réussir son plat à coup sûr sans être un grand chef.

La qualité de la documentation passe aussi par ces exigences :

  • Pertinente, mise à jour, compréhensible
  • Facilement trouvable et bien organisée

D’après le rapport, le lien de corrélation est établi entre qualité de la documentation et performance : les équipes ayant une bonne qualité de documentation interne sont environ x3 plus en mesure d’atteindre leurs objectifs et de respecter les bonnes pratiques de sécurité.

Quelques recommandations :

  • Documenter les use-cases critiques pour vos produits et services
  • Clarifier les règles de mise à jour de la documentation et notamment le propriétaire
  • Inclure la rédaction de la documentation comme faisant partie du processus de développement

Sécurité

Inutile de rappeler les enjeux de cybersécurité, l’actualité nous montre très régulièrement des exemples retentissants de failles de sécurité, attaques… ayant des répercussions de plus en plus graves pour les clients/utilisateurs (vols de données confidentielles…), les entreprises elles-mêmes et bien évidemment les salariés de ces entreprises. A ce titre, nous avons tous assisté à la métamorphose de DevOps en DevSecOps.

Encore une fois, les Elite Performers ont les meilleurs résultats concernant la sécurité. Leurs points communs sur le sujet ?

Ils intègrent la sécurité tout au long leur process de développement.

Les bonnes pratiques d’environ 60 % des Elite performers :

  • Tests de sécurité dès la phase de spécifications, donc très en amont.
  • Implication des équipes InfoSec en amont du projet: revue de la sécurité à chaque étape avec l’InfoSec team tout au long du cycle de développement
  • Revue de la sécurité pour les fonctionnalités majeures
  • Préparation de code préapprouvé : librairies, packages, outils…

Autres techniques DevOps plébiscitées par les meilleurs performers

  • Architectures faiblement couplées
    la réduction de la dépendance des composants est l’une des techniques apportant le plus de gain pour le passage à l’échelle, travailler sur des petites pièces mieux découpées, limiter la dette technique et réparer plus facilement lors d’un incident.
  • Intégration continue
    intégrer au fil de l’eau les commits réalisés par l’équipe pour détecter au plus tôt les conflits dans le code, bugs… permet d’améliorer la qualité. C’est le principe de l’auto-qualité du Toyota Production System : pour avoir un niveau de qualité irréprochable en sortie, il faut que la qualité soit irréprochable à chaque étape du processus de développement.
  • Tests automatiques
    les meilleures pratiques montrent que le rôle du testeur est toujours indispensable mais qu’il doit se concentrer sur des tests à plus forte valeur ajoutée tandis que les tests simples sont automatisés.
  • Développements basés sur le tronc (trunk-based)
    la bonne pratique du développement sur le tronc avec des branches courtes (de l’ordre de la journée) est toujours celle retenue par les meilleurs performers par opposition aux branches longues impliquant des merge complexes.
  • Automatisation du déploiement
    déploiement en environnements de dév, intégration, recette et… le Graal, en production. Le temps ainsi gagné et la fiabilité obtenue permettent aux personnes de se concentrer sur l’amélioration continue et la résolution de problèmes.
  • Pratiques de supervision et d’observation
    pour détecter plus vite (monitoring) et trouver les causes racines plus facilement lors d’incident (observability)
  • Gestion des changements sur la base de données
    souvent négligé en comparaison du code source, l’étude montre l’importance de ce sujet sans recommandation de techniques particulières
  • Technologies open source

Et la culture dans tout ça ?

Comme je vous le disais au début de cet article : durant la pandémie, la vitesse a continué à augmenter pour les Elite et High performers.

L’étude confirme toujours qu’une culture d’entreprise de type generative selon Westrum est celle qui permet aux meilleurs performers de réussir.

Rappelons les caractéristiques des 3 types de cultures selon Ron Westrum, auteur de « A Typology of organisational Cultures » :

Extrait de Ron Westrum : A typology of organisational cultures

Le State of DevOps 2021 révèle aussi que 89% des personnes interrogées étaient en télétravail (partiel ou complet) alors que seulement 20% d’entre elles avaient déjà expérimenté le télétravail auparavant. Une situation relativement nouvelle donc pour ces équipes. L’isolement était donc renforcé et propice au mal-être et aux burn-out.
Qu’est ce qui a donc fait la différence entre Elite Performers et Low Performers sur la culture d’équipe et d’entreprise ?

Revenons sur les caractéristiques d’une culture generative et leur mise en pratique dans une démarche Lean :

  • Équipe orientée performance
    En Lean, nous construisons les indicateurs de performance d’équipes afin de clarifier la situation actuelle, la cible et l’écart pour l’atteindre (la marge de progrès). Nous favorisons les indicateurs d’équipes qui reflètent le point de vue du client. Par exemple, on mesure le nombre de features livrées plutôt que le nombre de points de complexité ou le nombre d’heures passées.
  • Coopération intensive
    Si la plupart des équipes ont leurs point du matin, on assiste malheureusement souvent à une litanie des réunions et activités de la veille. S’il peut être intéressant de partager quelque faits marquants de son agenda avec l’équipe, le point du matin est surtout l’occasion de clarifier l’objectif de la journée et de décider comment on s’organise pour y arriver tous ensemble. On doit partager les obstacles qui nous empêchent de livrer et si besoin tirer l’Andon à n’importe moment pour signaler à l’équipe un besoin d’aide immédiat (un bon  article sur l’Andon).
  • Risques partagés et droit à l’erreur
    Parmi les 10 règles du Kaizen, on retrouve : « Dur avec les situations, doux avec les personnes ». Le respect des personnes fait partie du Toyota Way, le système de management Lean.
  • Failure -> Inquiry 
    En Lean, la résolution de problèmes (par exemple un incident) donne lieu à un PDCA en plus d’une réparation plus rapide possible pour protéger le client, effectuer une recherche des causes racines afin d’éradiquer ce problème à l’avenir. Une vidéo sur le sujet pour tout savoir ou presque sur le PDCA illustrée par la célèbre roue de Deming.

Pour conclure

Comme nous le rappellent les auteurs, les bénéfices de DevOps se confirment avec les années : accélérer et améliorer la qualité. DevOps est un cercle vertueux dans lequel on améliore la situation pour les clients (livraisons plus fréquentes = plus de valeur) pour l’entreprise (time to market) et pour les équipes (qualité de vie au travail, sens, activités à plus forte valeur, empowerment, sérénité).

J’ajouterais que l’approche Lean offre le cadre indispensable pour cranter les améliorations, leur apporter un cadre structuré avec le PDCA, puis invite à mesurer le lead time sur l’ensemble du processus… et enfin s’assurer de la satisfaction des clients avec la voix du client.

Et vous, où en êtes-vous de la mise en place du DevOps dans votre organisation ?

Si vous souhaitez en discuter, vous pouvez me contacter thomas.deligny@operaepartners.com

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s