Aujourd’hui, DevOps est un terme largement accepté pour accroître l’agilité des organisations, et il joue généralement un rôle clé dans les programmes de transformation informatique de nombreuses entreprises. Cependant, de nombreuses organisations sont confrontées à divers défis lors de l’adoption de modèles et de processus attribués à DevOps. En tant que responsables informatiques, il est important de connaître ces problèmes courants et de prendre des mesures préventives pour les éviter. Cet article de blog a pour but de détailler cinq problèmes courants que nous rencontrons lorsque nous aidons des organisations qui éprouvent des difficultés pour devenir plus agiles grâce à l’adoption de DevOps.
Au cours des dix dernières années, DevOps est devenu un cadre complet de culture, de méthodologies, de technologies et de pratiques. Par conséquent, le terme DevOps possède de nombreuses définitions. En règle générale, on s’attend à ce que l’utilisation de DevOps permette à une organisation de mettre en place des valeurs fondamentales fondées sur la méthode Agile, de suivre les meilleurs principes et pratiques, de tirer parti des technologies de pointe et d’automatiser les pipelines de construction et de test afin de fournir des produits de valeur aux clients de manière continue et itérative. Pour commencer, les organisations devraient créer une ou plusieurs équipes DevOps interfonctionnelles comme points de départ pour tester leurs idées DevOps. Les équipes décident des outils, des piles technologiques, des processus scriptés, du processus de développement agile, etc.
Ce faisant, les problèmes typiques suivants peuvent être observés :
1. Faire du DevOps pour le plaisir du DevOps
Après l’adoption avec succès de DevOps par de nombreux géants de la technologie comme Google, Facebook, Netflix, etc., cette passion a véritablement touché de nombreuses entreprises. Être à la mode fait partie de l’objectif. C’est pourquoi les organisations traditionnelles entament leur transformation interne aussi vite qu’elles le souhaitent. Généralement, les groupes informatiques commencent par utiliser des outils CI/CD bien connus et une équipe Scrum, en s’inspirant des meilleures pratiques DevOps. De nombreux termes à la mode liés à DevOps tels que « Fail-fast », « Test Automation », « Staging » sont introduits et largement utilisés. Des sprints, des itérations et des rétrospectives sont utilisés pour organiser le travail et les équipes se font un plaisir de développer davantage d’outils. Cependant, après quelques mois, de nombreux chefs d’équipe commenceront à se demander : qu’essaient-ils d’atteindre ? Tout le monde est occupé, mais on ne fait pas grand-chose ! En rendant le cycle de développement plus flexible, l’objectif final s’éloigne de plus en plus.
L’une des raisons pour lesquelles une organisation devrait adopter un modèle DevOps est de fournir plus rapidement la valeur des produits au client et d’être adaptable pour garantir que la feuille de route du développement puisse s’adapter à l’évolution de ce qui constitue la « valeur ». C’est pourquoi le développement de logiciels dans un état d’esprit DevOps préconise les produits plutôt que les projets. L’objectif ne peut pas être de terminer le projet, mais de faire évoluer en permanence un produit sur la base d’une idée en constante évolution de ce qu’est la valeur selon le client final.
L’objectif et la vision doivent être créés au tout début, mais aussi régulièrement revus pour s’assurer que les activités de transformation sont toujours sur la bonne voie.
2. Silos
L’un des défis de l’adoption de DevOps vient souvent des unités organisationnelles divisées en équipes travaillant en silos. Lorsqu’une initiative de transformation est lancée, il n’y a généralement pas encore de consensus à l’échelle de l’entreprise sur le démantèlement des silos. Comme peu de parties prenantes sont informées ou impliquées, l’équipe centrale du projet peut progresser rapidement. Ensuite, après une expérimentation réussie, les organisations décident de lancer la transformation et de l’étendre à grande échelle. Elles voient rapidement la progression ralentir, car de nombreuses dépendances imprévues et déconcertantes apparaissent.
En fait, cette situation est simplement due au conflit avec le modèle de prestation existant au sein des organisations. L’organisation informatique traditionnelle sert toujours les clients à l’aide de processus prédéfinis dans le déploiement des applications, la sécurité informatique, la conformité des données et le contrôle des coûts. La livraison rapide n’est pas la première priorité. C’est pourquoi l’adoption de DevOps représente en fin de compte une opposition à ce modèle. Les entreprises luttent avec « DepOps » pour résoudre les innombrables dépendances.
Pour résoudre ces problèmes, un plus large éventail d’engagements peut jouer un rôle clé. Si les parties prenantes de l’entreprise sont impliquées dès le début, les équipes peuvent s’assurer qu’elles se conforment à la valeur. La transformation ne concerne pas seulement la technologie mais va au-delà de l’organisation informatique. Il est extrêmement utile que la direction générale puisse offrir un soutien solide pour briser les chaînes.
En outre, la création d’équipes DevOps à partir de zéro et la mise en place d’un nouveau modèle de livraison sont toujours encouragées. Les équipes doivent être libérées de la charge d’innombrables processus pour s’assurer qu’elles peuvent fournir la valeur de manière productive. En recueillant une bonne expérience DevOps, les entreprises peuvent établir ce nouveau modèle qui se concentre sur la fourniture de valeurs dans un environnement changeant.
3. Toujours occupé mais peu de livrables
Lors de l’adoption de méthodologies DevOps, les équipes DevOps sont constituées à l’aide de processus agiles comme Scrum ou Kanban. En ce qui concerne les membres de l’équipe, ils suivent strictement les événements agiles, participent aux stand-up quotidiens, préparent les réunions de planification, conçoivent les pipelines d’intégration continue, etc. Les membres participent aux discussions techniques et échangent activement leurs idées et réflexions sur les outils et les concepts. Cependant, si vous examinez de plus près les résultats des sprints de leur équipe, vous constaterez qu’il y a peu de fonctionnalités démontrables ou d’artefacts livrables. Certaines tâches restent dans le backlog pendant plusieurs sprints. Et pourtant, ils continuent à s’engager dans de nouvelles tâches pour le sprint à venir.
La cause profonde de ces problèmes peut varier. La taille de l’équipe est une raison importante. L’objectif de DevOps n’est pas seulement d’introduire un processus agile mais plutôt de tisser une équipe de livraison dans son ensemble pour qu’elle se comporte de manière tactique. Certaines équipes DevOps sont plus grandes que nécessaire. Chaque événement de sprint prendrait plus de temps. Même le stand-up quotidien est douloureux pour les membres. Dans une telle équipe, il y a plus de débats que de travail. Jeff Bezos a déjà instauré la règle suivante : chaque équipe interne doit être suffisamment petite pour pouvoir être nourrie avec deux pizzas. Les équipes de petite taille peuvent produire des fonctionnalités plus efficacement.
4. Trop de roues
Pour de nombreuses organisations informatiques traditionnelles, la planification et la mise en œuvre d’un modèle DevOps complet dans le cadre d’un programme de transformation informatique constituent une option intéressante. Nous pouvons voir des organisations embaucher des développeurs qualifiés et ajouter du personnel d’exploitation pour constituer de nouvelles équipes DevOps. Pour les nouvelles équipes DevOps, l’utilisation de nouveaux outils constitue la première étape immédiate. Nous pouvons voir les équipes passer des sprints à réécrire du code, à reconstruire des composants ou à réinventer des roues. Comme chaque équipe se concentre sur des domaines d’activité différents, applique différents modèles d’architecture, établit des piles technologiques différentes, elle a tendance à avoir des chaînes d’outils différentes avec des processus automatisés différents pour assurer son travail.
Il ne faut pas sous-estimer le temps consacré à l’évaluation des technologies et à la maintenance de ces outils, car le coût augmente de façon exponentielle avec le nombre d’équipes. Pour les grandes organisations, cela deviendrait un problème visible si de nombreux outils étaient introduits avec des risques de sécurité inconnus. La gouvernance serait assez coûteuse et, d’autre part, il est difficile de décider quels outils doivent être éliminés à temps.
La normalisation des outils et des processus DevOps est la solution pour pallier ce problème. La mise en place d’environnements standardisés avec des outils préconfigurés est la tâche de l’équipe de gouvernance. En outre, la mise en place d’une plateforme interne constitue un meilleur choix pour les grandes organisations afin de permettre le partage des connaissances, la réutilisation des outils, l’atténuation des risques, etc.
5. Attentes élevées, faibles performances
DevOps est considéré comme un moteur turbo boosté pour de nombreuses organisations, afin d’accélérer la livraison et d’apporter plus de valeur commerciale. En outre, elles s’attendent à ce que DevOps permette de réduire les coûts grâce à l’automatisation et aux logiciels libres. Cependant, les véritables résultats attendus peuvent s’écarter des attentes de la direction. Les clients peuvent être déçus par la qualité de la livraison, le nombre de fonctionnalités, etc.
En réalité, DevOps n’est pas un travail ponctuel, mais une approche itérative qui exige des organisations qu’elles définissent en permanence des objectifs clairs mais plus modestes. Parfois, les organisations doivent procéder à davantage de changements ou explorer différemment pour identifier l’étape suivante. Il est important que chaque itération apporte une valeur convenue aux clients.
Deuxièmement, pour aligner les attentes des clients sur les performances, des paramètres quantifiables doivent être définis avant la livraison. Typiquement, nous pouvons avoir des mesures dans les domaines suivants :
- Activité : nombre d’utilisateurs, nombre de produits
- Livraison : délai, fréquence de déploiement effective
- Gestion des modifications : pourcentage d’échec des modifications, temps moyen de récupération (MTTR)
Avec de telles mesures, les organisations peuvent garantir une livraison plus transparente couvrant la valeur, le coût et le risque, afin de créer des attentes commerciales plus réalistes.
Enfin, il est également recommandé de développer un modèle de maturité pour DevOps. Le modèle de maturité permet d’évaluer l’état DevOps de l’organisation et de guider les activités d’amélioration futures.
Conclusion
L’adoption de DevOps est un sujet compliqué pour de nombreuses entreprises. Il existe d’autres problèmes connus qui ne sont pas décrits ici. Pour les organisations, le choix de produits appropriés, la suppression des silos, la normalisation des processus et des outils, la gestion des attentes et l’utilisation de méthodes incrémentielles peuvent consolider les principes fondamentaux et permettre l’adoption à grande échelle de DevOps afin de rendre l’entreprise plus agile.
Si vous cherchez de l’aide pour vos efforts de transformation, prenez contact avec notre équipe de Développement d’applications Cloud.
