Faire le passer à DevOps L’évaluation DevOps peut être une tâche ardue, de nombreuses organisations ne sachant pas par où commencer. J’ai récemment eu l’occasion de faire quelques évaluations DevOps pour voir quelles solutions sont actuellement sur le marché. J’ai varié mes réponses, allant d’une organisation qui a pleinement adopté DevOps à une organisation qui en est au début de son parcours. Certaines évaluations ont apporté une réelle valeur ajoutée, m’ont renvoyé à des articles sur la culture et les méthodologies, et d’autres m’ont offert un outil pour concrétiser tous mes rêves DevOps.

Tout d’abord, je dois dire que je pense que les outils sont absolument essentiels dans le parcours DevOps, car ils peuvent fournir des logiciels qui permettent aux utilisateurs de fournir, d’automatiser ou de surveiller en continu un service. Cependant, DevOps n’est pas un produit et les outils seuls ne peuvent pas vous permettre de mettre en place les processus nécessaires pour exploiter pleinement la valeur de DevOps. Avec DevOps, ce sont les personnes qui comptent le plus. Sans elles, vous ne pourrez pas créer l’état d’esprit et la culture nécessaires pour adopter pleinement et avec succès DevOps.

Ne gagnez pas à DevOps ; devenez un champion

J'ai récemment eu une conversation avec Jennifer Tejada, PDG de PagerDuty, concernant le fait d'être un gagnant par rapport à un champion. Elle a expliqué à quel point gagner est fantastique : vous obtenez un trophée, un titre, ou peut-être même quelques millions de dollars s'il s'agit de la loterie. Cependant, si l’on considère la situation dans son ensemble, la victoire est avant tout une question d’objectifs à court terme. En revanche, être un champion signifie se concentrer sur les réussites ou les résultats à long terme. Cette conversation m'a fait réfléchir à la manière dont les mêmes principes peuvent être appliqués aux organisations adoptant DevOps.

L’un de mes exemples préférés d’outils DevOps est le tableau périodique des outils DevOps de XebiaLabs :

Comme le montre le tableau, de nombreux outils entrent dans les catégories DevOps. Cependant, j’ai trop souvent vu ou entendu des histoires d’organisations qui « se transforment en DevOps » en achetant des outils. Comme je l’ai mentionné plus tôt, si les outils sont un élément essentiel du parcours DevOps, un outil à lui seul ne crée pas un environnement DevOps. Il faut prendre en compte tous les facteurs qui font qu’une équipe DevOps fonctionne bien : la collaboration, l’automatisation, la prise en charge, la suppression des silos et la définition des processus, ainsi que l’amélioration continue et la livraison continue.

Prendre la décision d’acheter des outils est un grand pas dans la bonne direction ; le plus important est cependant de définir d’abord le « pourquoi » ou l’objectif final derrière les décisions, ce qui nous ramène à la mentalité d’un champion.

Prenons par exemple le cas du médaillé d'or olympique Michael Phelps. Au cours de sa carrière de nageur, Phelps a été l'olympien le plus décoré de tous les temps et détient également 39 records du monde. Phelps ne s'est pas arrêté à 1, 2 ou même 20 victoires ; il a cherché à devenir un champion. Tout cela a été accompli grâce à l'engagement, à la pratique et à la concentration sur l'état final souhaité.

Définition de DevOps

Bien qu'il existe des centaines de définitions pour DevOps, presque tout le monde peut s'accorder sur le principe fondamental décrit dans le Rapport sur l'état de DevOps : « DevOps est un ensemble de principes visant à créer une culture et des processus pour aider les équipes à travailler plus efficacement et à fournir de meilleurs logiciels plus rapidement. »

La culture et les processus ne peuvent pas être modifiés avec une carte de crédit. Les outils peuvent permettre à une organisation de mieux collaborer, d'automatiser ou de livrer en continu. Cependant, sans l'état d'esprit et l'adoption appropriés, il est possible que les capacités complètes d'un outil ne soient pas atteintes.

Utilisons Mou Par exemple, un de mes anciens collègues qui a rejoint une nouvelle entreprise était présent à une conférence et a entendu à quel point Slack était formidable pour les équipes qui se convertissaient à DevOps, car il ouvrait des canaux de collaboration. Il a convaincu son responsable que Slack résoudrait tous leurs problèmes de communication. Cependant, six mois après l’adoption de Slack, la majorité des équipes utilisaient toujours Skype, y compris le responsable. Slack a fini par être davantage un lieu de discussion sur le brassage de la bière qu’un outil utilisé pour mettre le produit sur le marché plus rapidement. Le problème n’était pas Slack, mais le manque d’adhésion de l’équipe et de l’organisation, et l’absence de connaissances sur toutes les fonctionnalités du produit.

Faire en sorte que les outils et les meilleures pratiques fonctionnent pour l'équipe et atteindre les objectifs à court et à long terme est le point sur lequel notre conversation sur le fait d'être un champion DevOps se pose. Par exemple, quel est l'objectif global et à long terme de l'équipe ou de l'organisation ? Une fois l'objectif identifié, comment obtenir l'adhésion des principales parties prenantes ? Une fois l'adhésion obtenue, comment mettre en œuvre la solution ?

Changement organisationnel

Le changement est difficile pour de nombreuses organisations et personnes, et un changement significatif ne se produit pas du jour au lendemain. Il est important de comprendre comment les personnes et les organisations gèrent le changement.

Dans le Processus Kotter en 8 étapes pour conduire le changement , la première étape consiste à articuler le besoin d’un changement, à créer l’urgence autour du pourquoi, puis à commencer petit et à trouver et développer ces champions internes avant d’essayer de prouver des victoires (ou dans ce cas, d’acheter un outil).

Si les membres d’une organisation ne sont pas conscients d’un problème ou de l’existence d’une meilleure façon de fonctionner, il sera difficile d’obtenir l’adhésion nécessaire et de motiver les membres de l’équipe à adopter de nouvelles idées et à agir. Les gens peuvent être parfaitement satisfaits de la situation actuelle, peut-être parce que les processus en place sont adéquats. Il se peut aussi que, au minimum, la situation actuelle soit un facteur connu. Cependant, pour que l’équipe dans son ensemble fonctionne bien et atteigne ses objectifs communs de manière plus rapide et plus agile, de nouveaux mécanismes doivent d’abord être mis en place.

Comment devenir un champion DevOps

Être un champion dans le monde DevOps signifie aller au-delà de la victoire. Cela signifie approfondir la structure et la culture de l'équipe/organisation pour identifier les problèmes périphériques au-delà des outils, puis travailler avec d'autres pour adopter les changements nécessaires qui conduisent aux résultats définis. En bref, vous devrez revenir au début et définir l'objectif final. Voici quelques questions simples que vous pouvez poser pour commencer :

• Quelles sont vos valeurs fondamentales?
• Pourquoi essayez-vous de devenir une entreprise plus agile ou équipe ?
• À quels obstacles votre équipe ou votre organisation est-elle confrontée ?
• Que permettra d’accomplir l’outil ou le processus ?
• Comment les gens communiquent-ils et collaborent-ils ?
• Existe-t-il des silos et pourquoi ?
• Comment défendez-vous le client ?
• Les employés sont-ils responsabilisés ?

Après avoir défini l'état final, trouvez d'autres personnes partageant les mêmes idées pour faire partie de votre équipe de champions et ne perdez pas de vue ce que vous essayez d'accomplir. Soyez conscient que lorsque vous apportez des changements, commencez par de petits changements, par exemple en commençant par une équipe ou un environnement de test. En commençant petit et en vous appuyant sur les succès, les champions internes commenceront à se créer eux-mêmes.

N'oubliez pas que les entreprises sont heureuses et désireuses d'essayer de vous vendre DevOps. Mais en fin de compte, DevOps n'est pas un produit ; c'est une méthodologie et un état d'esprit entièrement adoptés, axés sur l'automatisation, la collaboration, les personnes et les processus.

*La version originale de cet article a été publiée plus tôt sur opensource.com.