DevOps et agile pour tous: les professionnels de la technologie doivent montrer la voie dans l’ère post-Covid à venir

Le DevOps et les méthodologies agiles ont certainement changé les priorités et les pratiques des équipes technologiques. Désormais, alors que les organisations se préparent au boom d’activité post-Covid, ces efforts devront être à la pointe du changement culturel et de l’engagement des clients. DevOps et agile doivent sortir du département informatique et devenir les meilleures pratiques de tous. Le rôle des professionnels et des gestionnaires de l’informatique dans l’année à venir sera d’appliquer leurs apprentissages et d’éduquer et de démontrer la puissance de ces philosophies au reste de l’entreprise.

Il ne fait aucun doute que DevOps et agile sont partout maintenant, du moins dans le monde informatique. Comme indiqué dans notre article précédent, 74% des organisations déclarent désormais avoir un programme DevOps actif, contre 47% il y a cinq ans – et la crise Covid de 2020 n’a mis qu’un point d’exclamation sur ces efforts. Agile est plus répandu, les données les plus récentes montrant que 95% des organisations pratiquent des méthodes de développement agiles. Cependant, seuls 33% déclarent que plus de la moitié de leurs équipes mettent en pratique les principes agiles.

Les pratiques agiles ont peut-être été ce qui a poussé de nombreuses entreprises à traverser la crise Covid, alors que la grande dispersion des entreprises avait eu lieu. «Il suffit de voir à quelle vitesse un grand nombre d’entre eux pourraient s’adapter à la nouvelle situation lorsque la pandémie a frappé», déclare Johan Karlsson, consultant senior chez Perforce. « C’était époustouflant de voir comment même les très grandes entreprises pouvaient passer à une distribution complète en très peu de temps. C’est un exemple où les améliorations agiles déjà mises en œuvre sont devenues extrêmement précieuses. »

Alors que nous nous dirigeons vers l’ère suivante, une grande partie de ce qui se passe avec le DevOps et l’agilité consiste à avoir le bon état d’esprit. DevOps, pour sa part, « est un mouvement qui refuse d’être défini », déclare Mike Loukides, vice-président des contenus technologiques émergents chez O’Reilly Media. «De nombreuses entreprises exploitent DevOps en tant qu’ensemble spécifique d’outils et de pipelines pour déployer des applications. Cependant, cela reste irrégulier en termes d’organisations exploitant DevOps pour des changements culturels autour de l’interaction entre les groupes d’exploitation, les développeurs et la direction. Lorsqu’il s’agit de fournir une collaboration directe entre les développeurs et les opérations, cela s’observe davantage dans la brèche.  »

DevOps tient-il ses promesses? Dans certaines entreprises qui se concentrent sur la bonne exécution du DevOps, les résultats ont été impressionnants. «Nous avons adopté de multiples pratiques et, surtout, le changement de mentalité culturelle qui est au cœur de DevOps», déclare John Donoghue, directeur du développement chez Smart Communications. « Cet alignement plus étroit des équipes de développement et d’exploitation a entraîné moins de retouches des fonctionnalités pour répondre aux besoins opérationnels, des versions plus fréquentes, une meilleure stabilité opérationnelle et une qualité améliorée. »

La maturité des initiatives DevOps est un facteur majeur. «D’un côté, vous avez des industries entières telles que l’industrie du développement de jeux qui a été révolutionnée par les opérations en direct, et DevOps en est rapidement devenue une partie naturelle», déclare Karlsson. « De l’autre côté, vous avez des industries qui proviennent d’une approche plus cloisonnée qui ne font que toucher la surface des possibilités – mais elles ont commencé le voyage. »

«Vous ne pouvez pas simplement prendre un certificat Agile, lire un livre, regarder une vidéo et mettre en œuvre les pratiques suggérées ici», déclare Karlsson. . « Les équipes de direction qui cherchent à mettre en œuvre des cadres agiles à grande échelle courent ce risque. La douleur la plus réelle ne se situe généralement pas au niveau de l’équipe – c’est au niveau du système entre les équipes. »

Ce sont les compétences générales qui peuvent faire ou défaire les DevOps et les engagements agiles. « Vous pouvez configurer tous les outils, pipelines et tableaux de bord DevOps, mais si les équipes commencent à revenir aux anciennes méthodes de changements ad hoc, de déploiements sans tests, le processus et la méthodologie s’effondrent », prévient Joe Clarke, éminent ingénieur en expérience client. chez Cisco: « De même, avec Agile, vous avez besoin d’une culture de transparence avec un alignement sur la stratégie où tout le travail est enregistré afin que vous ayez une traçabilité de bout en bout et une responsabilité vis-à-vis de la stratégie. »

Dans l’entreprise de Donoghue, le plus grand défi avec DevOps a été d’étendre les avantages au client. Cela signifie «équilibrer le support pour les clients ayant un appétit différent pour les changements qui les impactent», raconte-t-il. «La livraison continue en est un excellent exemple: certains clients sont les bienvenus en sachant qu’ils disposent toujours des dernières mises à jour, tandis que d’autres sont préoccupés par la fréquence des changements. Garantir à tous les clients une grande confiance dans la qualité des changements est un élément clé pour continuer à aller de l’avant.  »

Le client doit également être au centre des efforts agiles. «La démonstration au client» doit être au cœur de toute initiative agile, déclare Loukides. « Agile consiste vraiment à atteindre le bon point final en apportant de nombreuses petites corrections à mi-parcours à votre direction. Donc, s’il y a une chose qui manque, dans la plupart des cas, c’est cet engagement envers le client. »

Bien sûr, les clients entrent en jeu à tous les niveaux et ne sont pas nécessairement des consommateurs de téléphones portables. «Nous avons constaté qu’une approche DevOps est nécessaire pour continuer à améliorer et à étendre les avantages aux opérations», déclare Donoghue. «En tant que fournisseur de très grandes entreprises, nous n’avons pas trouvé pratique pour les équipes de développement de collaborer directement avec les utilisateurs finaux. Nous préférons travailler avec un représentant client dont le rôle essentiel est de trouver les collaborateurs appropriés au sein de chaque client, de rassembler et de consolider leurs commentaires, puis équilibrer leurs besoins et priorités variables.  »

Donoghue conseille de démarrer DevOps avec « une compilation, un test et un déploiement automatisés. Une approche de micro-services permet d’encapsuler la portée des changements, permettant des versions ciblées de taille réduite. Celles-ci deviennent plus rapides à déployer avec une compréhension claire et des risques plus facilement contrôlés. La conteneurisation améliore cela en outre, en minimisant la différence entre les environnements de développement, de test et de production, en augmentant encore le contrôle et en réduisant les risques.  »

La communication passe à travers les patchs difficiles qui peuvent être rencontrés avec DevOps ou les efforts agiles qui s’égarent. «Cela est particulièrement vrai avec la réduction du temps de présence et la collaboration directe de nos jours», déclare Clarke. « Ne laissez pas les problèmes s’aggraver et faire dérailler les efforts. » De bons outils de collaboration et de communication aident, ajoute-t-il, « il est tellement plus facile de faire les choses là où ces outils correspondent à votre flux de travail plutôt que d’avoir à faire des choses contre nature pour se synchroniser avec les gens. » En même temps, il conseille de garder cet outillage simple. « Plus il y a de boîtes dans votre architecture, plus les choses deviennent fragiles et fragmentées, ce qui conduit à la frustration et à la douceur du processus. » Recherchez les bons outils « pour le contrôle de code source, les builds CI / CD, les tests et les déploiements, et le suivi des problèmes, de sorte que vous ayez des outils uniques pour des tâches spécifiques – et non un nouvel outil tous les jours ou des outils concurrents pour faire la même chose, « Conseille Clarke.

Il est important de noter que le simple fait d’annoncer que vous créez une pratique DevOps n’apporte rien. «Les organisations qui créent des équipes DevOps ou embauchent des ingénieurs DevOps ont presque complètement raté le but», déclare Loukides. « DevOps est une question de collaboration entre les équipes existantes, plutôt que de créer de nouvelles équipes et de nouvelles spécialités. Pour l’essentiel, le type de collaboration entre les groupes de développement et les groupes opérationnels que DevOps envisage n’a pas eu lieu. »

L’avènement de l’IA et de l’apprentissage automatique pourrait aider à changer cette équation, poursuit Loukides. «Il y a eu des progrès à ce sujet, car les gens parlent maintenant de MLOps – et DevOps est bien placé pour résoudre ces problèmes. Mais MLOps à ce stade est encore très immature. Il y a beaucoup d’outils nécessaires que nous sommes seulement commencer à avoir, comme le contrôle de version pour les données, le contrôle de version pour les modèles, les tests pour les applications qui ne sont pas déterministes et les pipelines de déploiement pour les modèles qui peuvent prendre des jours à s’entraîner.  » Simultanément, « il n’y a pas assez de reconnaissance qu’une application d’IA est radicalement différente de l’application Web / base de données typique avec laquelle DevOps a grandi », ajoute Loukides.

Les progrès sont également lents sur le front agile. «Si vous parlez à des personnes travaillant dans le domaine du développement de logiciels, vous constaterez que beaucoup d’entre eux exécutent des processus agiles qui ne sont que des versions renommées de leurs anciens processus», déclare Loukides. « Agile a beaucoup de valeur, mais 20 ans après le Manifeste Agile, nous ne tenons toujours pas les promesses. » Alors que le manifeste met l’accent sur un contact profond avec le client, «certains groupes d’ingénierie évitent toujours le contact avec le client», dit-il. « Cela signifie que la chose la plus importante dans le Manifeste Agile est celle que la plupart des équipes de développement sont le moins susceptibles de faire. »

Une vue d’entreprise est nécessaire. «Une équipe peut vraiment réussir à réussir au niveau local avec les bons outils et la bonne mentalité», déclare Karlsson. « Cependant, sans le bon soutien de la direction et des autres équipes pour parvenir à des optimisations mondiales et à une pollinisation croisée des succès, ils pourraient simplement déplacer les problèmes sous-jacents d’un domaine à un autre. » Comme pour l’agilité, ajoute-t-il, «si une organisation me disait qu’elle a atteint la station finale, elle a atteint le nirvana agile, alors elle a raté toute la pièce autour de l’amélioration continue et il ne faut pas y croire».