Une transformation organisationnelle réussie nécessite d’avoir une culture qui brise les silos traditionnels qui cloisonnent les différentes équipes de l’organisation. Dans le cas de DevOps, nous cherchons à rapprocher, voire fusionner, les équipes responsables du développement et des opérations. L’idée de base est plutôt simple : il s’agit d’encourager la communication et la collaboration entre toutes les parties impliquées dans la livraison d’applications et de systèmes, et de mettre l’accent sur l’amélioration continue des processus et des produits. Tout cela dans le but d’améliorer la capacité de développer et de livrer plus rapidement, sans sacrifier la qualité et la sécurité.

Nous voulons donc rapprocher deux importants pôles d’activité : le développement et les opérations. Nous visons à ce que les employés qui développent les logiciels collaborent directement avec ceux qui s’occupent de leur livraison, de leur intégration et de leur soutien. Par exemple, les développeurs et les experts de l’interface utilisateur travaillent côte à côte avec les spécialistes réseau et les architectes de bases de données.

En théorie, cela doit permettre au département de TI d’accélérer considérablement ses cycles de déploiement. En fusionnant ou en rapprochant les deux groupes, la surveillance, l’analyse et les tests du nouveau code peuvent être effectués au cours du développement, ce qui permet aux nouvelles versions d’être expédiées de plus en plus rapidement.

En pratique, les équipes de TI divergent souvent dans leurs interprétations. Nous retrouvons, par exemple, des équipes pour qui il s’agit d’une façon d’appréhender le développement et le déploiement dans leur ensemble, et d’autres pour qui il s’agit plutôt d’une façon de structurer les équipes et d’établir des pratiques et des flux de travail.

Structure des équipes

Dans un contexte DevOps, les équipes peuvent prendre plusieurs formes. Un type d’organisation souvent rencontrée consiste à structurer les équipes autour du produit plutôt que des rôles. Au lieu d’avoir un produit sur lequel différentes équipes travaillent, une seule équipe multidisciplinaire est dédiée à chaque produit.

Un autre type d’organisation possible est de faire en sorte que les équipes de développement et d’opérations collaborent de façon soutenue tout en étant distinctes. Chaque équipe conserve ses responsabilités, mais travaille étroitement avec l’autre afin de régler les problèmes ou d’améliorer les façons de faire. Cela implique que les équipes connaissent les compétences des autres et sont en mesure de se mettre à la place de leurs collaborateurs pour trouver les difficultés et les surmonter.

Flux de travail

Une approche DevOps s’apparente aux stratégies Agiles de livraison continue avec lesquelles elle partage habituellement plusieurs caractéristiques. Bien qu’il n’y ait pas un ensemble de processus sur lequel tous s’entendent, il est possible de définir certaines étapes incontournables de la réalisation d’un logiciel :

  • La planification, durant laquelle les exigences, les études de cas et les métriques sont déterminées.
  • La création, qui consiste simplement à programmer le logiciel.
  • La vérification, qui implique les tests et l‘essentiel du processus d’assurance qualité.
  • La configuration, qui permet d’effectuer les modifications nécessaires en matière d’infrastructure.
  • Le lancement, durant lequel le logiciel est déployé.
  • La surveillance, lors de laquelle on observe l’expérience utilisateur et le rendement de l’application.

Les données recueillies au cours de cette dernière phase sont utilisées pour la planification du prochain déploiement. DevOps utilise également des outils automatisés, la virtualisation et l’intégration continue afin de fluidifier le processus de livraison qui devient continu.

Ces étapes peuvent à plusieurs égards rappeler un processus traditionnel, mais l’idée ici est de les répéter constamment, soit au cours de chaque itération, et non une seule fois pour l’ensemble d’un projet. La capacité des intervenants à rendre ce cycle le plus fluide possible dépend également de leur capacité d’adaptation et d’apprentissage basé sur l’expérience.

Le fait de continuellement surveiller les environnements applicatifs de façon itérative améliore les processus et le code. Cela permet également d’obtenir un retour constant de la part des utilisateurs, tout comme des intégrateurs, et de s’ajuster en conséquence. Nous profitons alors d’un avantage concurrentiel essentiel dans le domaine du développement logiciel.

L’importance de la culture organisationnelle

DevOps est plus qu’une approche, c’est un état d’esprit. En ce sens, nous recommandons fortement de revisiter la culture d’entreprise pour trouver des moyens de l’adapter en conséquence. Sa compatibilité avec cette façon d’appréhender le développement et la livraison conjointement aura une importance indéniable. Tout comme il est difficile d’adopter Scrum dans une équipe sans travailler sur son environnement et sa culture, il est au moins aussi ardu de rallier le développement et les opérations sans influer de façon décisive sur la culture en place.

La gouvernance d’une organisation ne doit donc surtout pas sous-estimer l’influence de sa culture. Malgré son caractère intangible, elle peut être responsable de la réussite ou de l’échec d’une initiative de transformation vers une culture DevOps. Le choix des gestionnaires et leur degré d’implication et de flexibilité auront une influence certaine sur la capacité d’accueillir le changement.

Et, surtout, nous recommandons fortement de mettre en place des mécanismes qui permettent aux gens de comprendre et d’intégrer ce que nous attendons d’eux. Malheureusement, il n’y a pas de pensée magique. Les gens ne se mettent pas instantanément à mieux communiquer et à mieux collaborer parce que nous leur disons de le faire. Il faut prendre le temps de les accompagner, de les informer et de les responsabiliser.

En terminant…

La culture DevOps cherche à s’assurer que nous offrons toujours une expérience exceptionnelle au client. Après tout, c’est lui que nous cherchons à satisfaire, et il doit toujours demeurer au centre de nos préoccupations. Par contre, il ne faut pas perdre de vue que nous devons également prendre en compte une multitude d’autres facteurs opérationnels ou financiers. Au-delà de la satisfaction du client, la faisabilité et la viabilité du point de vue des affaires sont évidemment centrales.

Tout comme l’Agilité, DevOps n’est pas une finalité en tant que telle. Il est plutôt question d’apprentissage et d’amélioration continue. Nous nous attaquons à un problème complexe. Ce n’est pas aussi simple que de livrer plus de logiciels, il faut livrer des logiciels de meilleure qualité plus rapidement, sans compromettre la fiabilité et la stabilité. Pour ce faire, le changement culturel qui permet aux équipes de ne plus être divisées, d’avoir les mêmes objectifs fondamentaux et de collaborer librement est incontournable.

gabriel bélanger

Billet précédent

Garder les gens engagés et motivés !

Billet suivant

Trois principaux obstacles à l’Agilité du produit

Pas de commentaire

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.