Découvrez les pratiques de gestion du changement qui sont mûres pour l'optimisation.

Le changement est devenu l'élément central de la création et de la gestion des produits numériques modernes. Si ces changements impliquent souvent l'ajout de nouvelles fonctionnalités, ils sont également motivés par la réponse aux demandes des clients et aux priorités des parties prenantes. L'objectif de DevOps L'objectif des équipes est de privilégier non seulement les changements rapides, mais aussi ceux qui peuvent apporter une valeur durable et mesurable. 

Malheureusement, les principes de l'intégration continue et du déploiement continu (CI/CD) ne se traduisent pas toujours dans les pratiques concrètes des organisations. Tout d'abord, la gestion du changement peut être entravée par un manque de tests ou de retours d'information. De plus, des processus hérités et complexes persistent, limitant souvent la vitesse à laquelle de la valeur peut être créée au sein des équipes ou des organisations. 

Mais DevOps Les équipes peuvent examiner plusieurs domaines clés pour identifier des pistes d'amélioration. Ces améliorations visent toutes à optimiser la gestion du changement afin de la rendre plus rapide, plus agile et plus susceptible de générer une création de valeur fréquente grâce à l'intégration et au déploiement continus (CI/CD). Sur la base de ces critères, nos principales recommandations d'amélioration sont les suivantes : 

• Limiter l'approbation manuelle des changements grâce à la modélisation stratégique des changements
• Générer, capter et tirer profit d'un retour d'information continu 
• Cartographie des processus pour identifier les étapes susceptibles d'être éliminées ou révisées

Accélérez les approbations de changement grâce à des modèles de changement standard.

DevOps L'approche agile valorise les changements rapides et itératifs mis en œuvre par des équipes très autonomes. Ces équipes ont généralement le pouvoir de prendre leurs propres décisions, ce qui leur permet de s'adapter et de faire évoluer leurs stratégies en fonction des informations disponibles à un instant donné. Cette structure d'équipe agile élimine les goulots d'étranglement de l'approche traditionnelle en cascade. Dans le développement en cascade classique, les équipes de développement dépendaient des directives de la hiérarchie. Souvent, ces directives concernaient des initiatives qui s'étalaient sur plusieurs mois, et les instructions n'étaient pas censées changer avant la livraison complète du produit final. 

Même l'état d'esprit agile n'a pas éliminé les réfractaires à cette approche traditionnelle en cascade. L'un des plus tenaces est l'examen manuel par le comité consultatif des changements (CAB). 

Bien qu'il soit nécessaire d'examiner et d'approuver les modifications proposées pour la prochaine version déployée, ces approbations ne doivent pas toujours être effectuées manuellement. À tout le moins, DevOps Les équipes devraient s'efforcer de limiter le nombre d'examens nécessitant la participation de l'équipe CAB de haut niveau. Limiter le nombre et la fréquence des modifications devant être examinées par le CAB contribuera à rationaliser le processus et à minimiser les perturbations. Comment peuvent-elles DevOps Comment réduire sa dépendance aux évaluations du CAB ? Cela peut commencer par modéliser les changements pour qu’ils s’intègrent aux groupes standard et non standard.

A Standard Une modification standard désigne tout changement de routine lié à des modifications similaires antérieures ou relevant d'une stratégie récurrente d'amélioration du produit. De nombreuses données permettent généralement de conclure qu'une modification standard présente un risque minimal de perturbation, de défaut ou d'échec. Ainsi, une modification standard peut être approuvée automatiquement après un examen et des tests automatisés préalables à son déploiement.

L'analyse de données peut fournir des informations sur le risque associé à un changement donné, qu'il soit standard ou non, grâce à l'utilisation de Indicateurs clés de performance (KPI) relatifs au risque de changement expressif.

Pour les modifications qui ne correspondent pas à un modèle standard, les équipes de développement peuvent scinder le déploiement en composants standard et non standard. Ainsi, les composants nécessitant un examen approfondi peuvent être isolés, ce qui réduit la portée et le temps requis par l'équipe CAB.

Il est également possible de limiter la portée de l'examen, même lorsqu'un examen manuel est nécessaire. Selon un site Web de ressources ITSM populaire, le concept de On peut recourir à la « délégation de pouvoir » lorsqu'un changement ne correspond pas tout à fait aux critères. Contrairement au modèle standard, ce modèle est limité à un service ou un site spécifique. Il garantit que les changements présentant des risques localisés sont examinés et autorisés par une autorité locale, comme un responsable informatique ou un chef d'unité opérationnelle. Cette pratique permet d'éviter de réunir l'ensemble du comité consultatif technique pour examiner et approuver les changements.

Rendre la CI et la gestion des bases de données plus agiles

L'automatisation peut globalement éliminer le besoin d'intervention humaine. Cependant, elle ne doit pas se réduire à une version informatisée d'un processus inefficace. 

DevOps Les équipes doivent veiller à optimiser l'utilité de l'automatisation en développant des capacités de documentation au sein du système. DevOps Dans le pipeline, chaque modification affectant une relation avec un élément de configuration (CI) doit être enregistrée automatiquement par les outils de développement dès que possible. Ainsi, toute personne souhaitant auditer les modifications apportées aux CI peut le faire rapidement et consulter précisément les changements affectant le CI concerné.

Les interactions avec les éléments de configuration (CI) ont tendance à ralentir les approbations de changement dès qu'une modification de la base de données est nécessaire. Si l'on ne prend pas en compte les effets de cette modification, elle peut entraîner des problèmes de performance au niveau de l'élément de configuration.

Pour réduire le risque de défauts tout en accélérant les changements liés à l'amélioration continue, un Un expert d'OpenSource.com recommande que, puisque « les modifications de bases de données ont tendance à compliquer l’intégration continue », DevOps Les équipes peuvent simplifier le processus. « Grâce à l’intégration continue des bases de données (DBCI), il est possible de s’appuyer sur une équipe agile et pluridisciplinaire comprenant un administrateur de base de données. » L’expert recommande également de privilégier le « database as code » et de « refactoriser les bases de données en utilisant les principes de la programmation orientée objet (POO) ».

S’appuyer sur un retour d’information continu des données pour améliorer la gestion du changement

L'utilisation de l'analyse des données peut fournir un retour d'information essentiel à tous les niveaux de la chaîne de valeur, permettant ainsi aux équipes de développement et d'exploitation de travailler de concert pour améliorer la fiabilité des changements. 

As Commentaires de Matthew Skelton, expert en livraison continue« La journalisation et les indicateurs sont des mécanismes de détection essentiels pour les équipes qui développent des systèmes logiciels modernes, à l'instar des systèmes radar et de reconnaissance vidéo qui aident les véhicules autonomes à se déplacer. » saferouler à grande vitesse sur les autoroutes. 

Les retours d'information issus de ces activités peuvent aider à réorienter les efforts des équipes, en les orientant vers des changements à plus forte valeur ajoutée et présentant un risque minimal d'anomalies. Il est important de noter que des indicateurs pertinents sont nécessaires pour favoriser des retours d'information rapides et efficaces. Par exemple, un taux élevé d'anomalies non détectées suite à des modifications apportées par une équipe peut indiquer la nécessité d'une meilleure couverture de tests pour ses versions ou d'une adaptation de ses pratiques de codage.

Le suivi des performances du système et l'utilisation des retours d'information pour l'améliorer sont traditionnellement considérés comme le rôle des équipes d'exploitation. Bien que ces dernières soient responsables du déploiement final et des performances en production, il est crucial que les équipes de développement aient accès aux mêmes outils de suivi afin de pouvoir analyser les indicateurs clés de performance des modifications et détecter les problèmes potentiels. Leur donner accès à ces données leur permet de détecter et de corriger les défauts, voire d'adapter leurs pratiques de codage pour obtenir des modifications plus stables. Leur permettre de suivre et de corriger ces problèmes de manière autonome, sans directives de la hiérarchie, est essentiel. autonomie proactive et, potentiellement, une plus grande satisfaction au travail.

Il faut toutefois savoir que les équipes de développement peuvent avoir besoin de temps pour s'adapter à la responsabilité d'examiner les retours d'information des opérations et d'y répondre. Cette démarche va souvent au-delà du simple travail d'adoption d'un nouveau processus ou d'une nouvelle technologie. Elle exige un changement de culture et une stratégie claire pour garantir l'adhésion de toute l'organisation à l'intégration et au déploiement continus (CI/CD) agiles. 

Mettre en œuvre une cartographie des processus pour identifier les sources de création de valeur et celles qui sont affectées négativement.

Afin d'identifier les goulets d'étranglement de la production de valeur, DevOps Les dirigeants peuvent créer une carte conceptuelle de chaque étape du travail dans DevOps et toutes les équipes impliquées. Le document issu de cette analyse est appelé « cartographie de la chaîne de valeur ». Il permet de suivre le flux non seulement du travail, mais aussi de la valeur réelle à chaque étape du processus.

Création et suivi des indicateurs pour chaque étape Ce suivi peut s'avérer extrêmement utile pour détecter les défauts et améliorer l'agilité. Par exemple, il permet de mesurer le temps total écoulé entre l'arrivée d'une tâche à une étape donnée et son départ, offrant ainsi des informations précieuses sur l'efficacité. Il met également en évidence les problèmes récurrents dans un domaine de travail précis.

Le suivi du processus à chaque étape permet DevOps Les équipes doivent aller au-delà de l'analyse de simples éléments isolés. La cartographie des processus, telle qu'elle est réalisée, permet de visualiser la circulation de la valeur tout au long du processus et son impact à chaque étape. Par exemple, la réduction du nombre d'étapes entre la compilation/les tests et le déploiement apporte une valeur ajoutée à l'ensemble du processus. 

As Matthew Skelton de Conflux observe« Les pipelines de déploiement longs et lents entravent l'obtention de retours d'information rapides. Il est préférable d'utiliser des pipelines courts et larges qui offrent aux équipes et aux chefs de produit la flexibilité nécessaire pour choisir les tests à exécuter en fonction de la nature de chaque modification. »

Utilisez ces suggestions comme base pour une gestion du changement plus efficace et plus agile.

S'il est facile de suggérer des pistes d'optimisation du processus CI/CD, il n'en reste pas moins que chaque organisation est unique en ce qui concerne… DevOps Le déploiement. C’est pourquoi la cartographie des processus est essentielle pour identifier précisément les opportunités d’amélioration au sein de votre organisation. 

Le retour d'information sur les données est essentiel pour orienter vos stratégies de prise de décision et améliorer votre agilité. De plus, la collecte automatisée de données peut favoriser une culture d'amélioration continue au sein des équipes de développement, ce qui peut, à son tour, renforcer la culture CI/CD tant au niveau informatique que dans l'ensemble de l'organisation. 

Enfin, la modélisation avancée par apprentissage automatique peut même exploiter les données pour créer une compréhension plus complexe de notions telles que les risques de changementvous permettant, ainsi qu'à vos équipes, non seulement de visualiser les données, mais aussi d'agir avec précision. Donner aux équipes d'accompagnement du changement l'accès à des outils comme la modélisation expressive des risques favorise une culture de compréhension rapide, de travail rapide et de prise de décision rapide, autant d'éléments qui permettent DevOps Produire plus de valeur plus souvent sans créer de risques imprévus.

Découvrez comment les analyses basées sur l'IA, telles que la prédiction des risques liés au changement, peuvent faire le lien l'écart entre ITIL et DevOps dans cette webdiffusion.