L'agilité comme objectif

Les responsables informatiques doivent éviter ces cinq écueils typiques lors de la transformation DevOps :

1. remettre en question la nécessité

Tous les environnements informatiques organisés de manière classique ne souffrent pas d'une charge de coûts trop élevée, d'un manque de flexibilité, d'une stabilité insuffisante des applications, de faiblesses de productivité ou d'une faible satisfaction des clients.

Pourtant, les optimiser est l'une des premières motivations pour l'utilisation de méthodes agiles. Il faut donc d'abord se demander quels paramètres de performance pourraient être améliorés par DevOps.

Sinon, on investit beaucoup d'efforts dans un changement sans bénéfice chiffrable, parce que l'organisation informatique suit sans réfléchir une tendance générale.

2. ne pas considérer DevOps comme un outil

DevOps est souvent présenté comme une sorte de cadre agile. En réalité, il ne s'agit pas d'un concept de méthode au sens propre du terme, mais d'une nouvelle philosophie avec des mécanismes de planification modifiés, des processus plus flexibles et des hiérarchies plus plates pour améliorer les processus entre les domaines du développement et de l'exploitation de logiciels.

Certains principes tels que la confiance mutuelle, l'esprit Lean, les critères d'évaluation uniformes, la livraison continue, l'automatisation des processus et le partage d'informations jouent un rôle essentiel pour une collaboration plus efficace entre les deux secteurs.

Ils sont à la base de versions logicielles plus rapides, d'une élimination plus rapide des erreurs critiques et d'une gestion plus efficace des tâches non planifiées.

3. aborder la transition de manière contrôlée

L'orientation vers DevOps peut donc conduire à des confrontations importantes avec la mentalité de l'organisation classique. C'est pourquoi il est recommandé d'organiser le changement de manière progressive et de suivre de près le succès à l'aide d'indicateurs définis.

Cela peut se faire par exemple sur la base de la fréquence des nouveaux déploiements ou en déterminant le temps écoulé entre l'identification des erreurs et leur élimination. La mesure de la performance des applications ou le nombre de déploiements ayant échoué peuvent également faire partie des critères d'évaluation.

Alternativement, il peut être utile d'introduire l'approche DevOps à l'aide d'exemples d'applications non critiques pour l'entreprise.

4. identifier les personnes qui donnent l'impulsion

Les supérieurs hiérarchiques à tous les niveaux de la direction et les employés eux-mêmes doivent comprendre ce qui se cache derrière la philosophie de DevOps. Cependant, étant donné que l'introduction s'accompagne d'un changement culturel important dans la collaboration, il est peu probable que ce changement soit couronné de succès par la seule annonce de nouvelles pratiques.

C'est pourquoi il est important de disposer de personnes qui donnent l'impulsion au sein de l'entreprise, qui assurent les connaissances de base nécessaires et une compréhension commune, mais qui fournissent également une aide en ce qui concerne les procédures opérationnelles.

Les équipes agiles et autonomes constituent le noyau opérationnel des processus DevOps, ce qui signifie en même temps un remplacement des processus jusqu'ici gérés de manière centralisée et divisés en responsabilités.

C'est pourquoi une autre conception de la gestion est nécessaire si l'on veut éliminer autant que possible les frontières entre les services et les hiérarchies, c'est-à-dire si l'on veut que les développeurs, les services spécialisés et la direction travaillent ensemble sur un pied d'égalité.

Une nouvelle culture de l'erreur fait également partie intégrante des changements, et la transformation DevOps nécessite de la part des dirigeants une pensée visionnaire et une action inspirante.