Explorer la culture DevOps

• 7 minutes

La culture est une base essentielle de DevOps, dont la réussite nécessite un état d’esprit ouvert sur la croissance et l’apprentissage continu. Le soutien des dirigeants est l’un des éléments primordiaux pour sa réussite.

Avant d’aborder ce qu’est la culture DevOps, considérons le rôle de la culture dans la capacité d’une organisation à adopter DevOps. Selon Gartner :

La résistance culturelle et les niveaux bas de discipline à l’égard des processus vont créer des niveaux significatifs d’échec des initiatives DevOps.

Gene Kim, auteur de Phoenix Project and DevOps Handbook, affirme ce qui suit :

DevOps est un voyage semé d’embûches, et ces embûches sont rarement simplement le fait d’une mauvaise technologie ou de mauvais processus. En fait, les obstacles les plus importants et les plus difficiles ont tendance à être culturels. Et, si votre culture n’est pas la bonne, alors que tout le reste est correct, vous courrez tout droit vers la frustration, les coûts supplémentaires et probablement un échec.

Qu’est-ce que la culture ?

Dans notre contexte, la culture correspond au patrimoine social d’un groupe. Elle constitue la tendance des réponses découvertes, développées ou inventées au fil des expériences passées du groupe pour gérer les problèmes issus des interactions entre ses membres, et entre ces derniers et leur environnement.

La culture détermine :

• Ce qui est acceptable ou inacceptable.
• Ce qui est important ou sans importance.
• Ce qui est correct ou incorrect.
• Ce qui est réalisable ou irréalisable.
• Qui vous recrutez, renvoyez et promouvez.

Pourquoi les initiatives DevOps échouent-elles ?

Les recherches de Gartner montrent que jusqu’en 2023, 90 % des initiatives DevOps vont échouer en raison des limites des approches de management utilisées par les dirigeants.

Les personnes qui travaillent sur des tâches créatives n’ont pas besoin de « bière dans la salle de pause » pour se motiver. Les créatifs ont plutôt besoin de maîtrise, d’autonomie et d’intention.

Quand la question est posée sur ce qui fait la majeure partie du succès de Microsoft, les réponses mentionnent-elles sa vision, sa stratégie, son exécution ? Selon Satya Nadella, PDG de Microsoft, tous ces éléments de réponse ont leur importance, mais en fin de compte, le succès de Microsoft est majoritairement dû à son état d’esprit axé sur l’intention et la croissance.

Les 12 exemples de l’état d’esprit DevOps

Voici 12 exemples de l’état d’esprit DevOps : sens du leadership, priorité au client, pensée rationnelle, pensée systémique, élimination du gaspillage, théorie des contraintes, alignement et autonomie, tests selon l’approche shift-left, état d’esprit prônant la sécurité, développement piloté par les hypothèses, site actif et mesure du résultat, pas de l’activité.

Sens du leadership

Gartner émet les recommandations suivantes :

• Identifiez les leaders transformationnels en hiérarchisant les caractéristiques comportementales spécifiques nécessaires pour diriger une initiative DevOps, en accordant moins d’importance aux ensembles de compétences techniques.
• Développez les leaders transformationnels en considérant l’échec comme une opportunité d’apprentissage.
• Gérez les leaders transformationnels en leur donnant la liberté de prendre des décisions sans anticipation et en leur fournissant des objectifs clairs et des métriques clés.

Puisque DevOps est transformateur, les leaders Infrastructure et opérations doivent identifier des candidats visionnaires, capables de s’adapter, motivants, valorisants et responsables.

État d’esprit centré sur le client

Que signifie être centré sur le client ?

• Écouter nos clients et communiquer avec eux
• Mesurer ce qui est important
• Gérer les problèmes en production
• Générer, mesurer et apprendre
• Utiliser le basculement de fonctionnalités pour un déploiement gracieux
• Collecter des données globalement, mais délicatement

Pensée rationnelle

Valeur : La pensée rationnelle commence par une compréhension détaillée de la valeur que le client attribue au produit et aux services. L’organisation se concentre sur l’élimination du gaspillage pour pouvoir fournir la valeur attendue par le client au niveau de rentabilité le plus élevé.

La chaîne de valeur englobe tout le cycle de vie du produit, depuis les matières premières, en passant par l’utilisation du client, jusqu’à la mise au rebut éventuelle du produit. Pour éliminer le gaspillage, objectif ultime de la méthode Lean, la compréhension de la chaîne de valeur doit être précise et complète.

Flux : La compréhension du flux est essentielle pour éliminer le gaspillage. Si la chaîne de valeur arrête de progresser à un moment donné, le gaspillage est un sous-produit inévitable. Le flux, principe de fabrication Lean, vise à créer une chaîne de valeur, sans interruption dans le processus de production, où chaque activité est en phase avec toutes les autres.

Système Pull : Le principe Lean du système Pull permet de garantir le flux en veillant à ce que rien ne soit fait à l’avance, car cela génère un inventaire du travail en cours et arrête le flux synchronisé. Au lieu d’utiliser l’approche américaine classique de la fabrication qui consiste à pousser le travail selon une prévision et un calendrier, l’approche du système Pull impose de ne rien faire tant que le client ne l’a pas demandé.

Perfection : Les adeptes de la méthode Lean aspirent à la perfection. L’accès à cette perfection se produit au fur et à mesure que des améliorations continues traitent les causes racines des problèmes de qualité et des gaspillages en production. La quête continuelle de la perfection amène les utilisateurs à chercher plus loin, à mesurer davantage et à changer plus souvent que leurs concurrents.

Pensée systémique

Une pensée systémique insiste sur les performances de l’ensemble du système, pas sur les performances d’un silo de travail ou département spécifique.

Concentrez-vous sur toutes les chaînes de valeur métier liées à l’informatique. En d’autres termes, la pensée systémique commence dès que des exigences sont identifiées par l’entreprise ou le service de développement informatique intégré, puis transmises au service des opérations informatiques, où la valeur est alors livrée au client sous forme de service.

Élimination du gaspillage

Un état d’esprit au plus juste met un point d’honneur à identifier et éliminer les sept sources de gaspillage inutiles qui n’apportent aucune valeur au client :

• Travail partiellement effectué
• Processus supplémentaire
• Fonctionnalités supplémentaires
• Changement de tâche
• En attente
• Mouvement
• Défauts

Théorie des contraintes

La théorie des contraintes est une méthodologie qui permet d’identifier et d’éliminer les contraintes (également appelées goulots d’étranglement) qui limitent le débit. Dans la pratique, commencez par identifier le facteur le plus important qui empêche d’atteindre un objectif. Efforcez-vous de minimiser ce facteur jusqu’à ce qu’il cesse d’être une limite.

Trouver l’équilibre entre alignement et autonomie

Il est nécessaire de trouver un équilibre entre alignement et autonomie. Trop d’alignement entraîne moins d’innovation, moins de motivation et moins de collaboration. Trop d’autonomie entraîne plus de désordre, de confusion et de conflits, mais aussi moins de cohérence.

Tests selon l’approche shift-left

Les tests selon l’approche shift-left sont utilisés pour accélérer les tests logiciels et faciliter le développement en déplaçant le processus de test à un stade plus précoce dans le cycle de développement. L’approche shift-left fait référence au décalage vers la gauche des tests dans la chronologie. Elle permet d’augmenter la qualité et d’identifier les problèmes plus tôt afin de réduire le gaspillage qu’implique la répétition du même travail.

Les tests selon l’approche shift-left ont vocation à incarner un modèle de développement rapide, car les modèles de test traditionnels qui doivent attendre un stade plus avancé du cycle de développement peuvent engorger le développement en lui-même.

État d’esprit prônant la sécurité

Pour incarner un état d’esprit prônant la sécurité, les équipes ont besoin de :

• Promouvoir la prise de conscience.
• Définir leurs principes.
• Respecter leurs principes.

Développement piloté par les hypothèses

L’approche du produit au plus juste pour développer des cycles plus courts et le développement piloté par les hypothèses permettent de créer des petites expériences pour obtenir un retour d’information de la part de nos clients et prendre des décisions pilotées par les données.

L’approche du développement pilotée par les hypothèses se définit ainsi :

• Elle commence par une hypothèse : une proposition acceptée comme vraie sans preuve.
• Elle articule l’hypothèse à tester.
• Elle effectue l’expérimentation et les tests.
• Elle examine la preuve : un indicateur du résultat.

Site actif

Pour une équipe DevOps, le meilleur endroit est la production. Tout son travail a pour seul but d’améliorer l’expérience des clients.

Pour créer un site stable à haut niveau de performance, appliquez les bonnes pratiques en matière d’opérations continues avec discipline et constance, afin que le site reste sain.

Les principaux facteurs de notre culture du site actif sont les suivants :

• Détecter avant que les clients se rendent compte
• Piloter avec des données
• Trouver la cause racine car elle est la clé
• Configurer sous forme de code
• Automatiser pour survivre
• Être ouvert et apprendre

Mesurer le résultat, pas l’activité

La façon dont vous mesurez les gens influe sur leur comportement. Vous devez mesurer l’utilisation, la vélocité et la santé du site actif, pas les lignes de code, l’avancement de l’équipe et le nombre de bogues trouvés.