Tag: ALM

DevOps – Comment joindre l’ITIL à l’agréable ?

Le chemin vers le DevOps peut être long et sinueux. Nous ferons face à de nombreux obstacles, à la fois culturels et organisationnels.  Une équipe DevOps doit être avant tout Agile et s’adapter en toutes circonstances. L’objectif de cet article et de partager une vision long terme et les étapes qui nous y amènent.

Pourquoi l’ITIL ?

La plupart des grosses structures ont, par définition et d’un point de vue RH, des groupes d’entités « métier » et « techniques ». Les entités métiers ont pour but d’apporter de l’innovation dans le métier de l’entreprise, d’augmenter le chiffre chiffre d’affaire et optimiser les dépenses. Les entités techniques, quant à elles, ont pour objectif d’implémenter, d’héberger et d’assurer le fonctionnement des outils nécessaires aux entités métiers pour exercer leurs fonctions. Les besoins sont multiples : performance, stabilité, sécurité, disponibilité. Afin que l’ensemble de ces critères soit satisfait, des méthodes et process ITIL ont été mis en place dans le but de contrôler et canaliser les changements pour plus de stabilité opérationnelle.

Un peu d’historique

Avant l’avènement des méthodes agiles, la plupart des projets suivaient un cycle de livraison en V. Les principes de cette méthode s’inspirent directement de l’industrie. On commence par recueillir le besoin initial puis définir des Blueprints d’architecture. L’ensemble des besoins est ensuite détaillé à la fois sur les aspects fonctionnels et techniques. Vient ensuite les phases d’implémentation, de test et de déploiement.

Cette méthode couplée à des processus ITIL permet une stabilité opérationnelle optimale. On modifie peu la production et lorsque cela arrive on canalise au maximum le changement via des processus définis. Cette façon de fonctionner a fait ses preuves durant de nombreuses années. Cependant, elle est de plus en plus controversée au bénéfice d’approches plus agiles. En effet, la plupart des équipes de développent travaillent en agile au plus près du métier. Elle délivrent des incréments régulièrement et sont souvent confrontés à la latence des process une fois l’incrément livré. Cela apporte de la frustration à la fois au niveau métier mais aussi au niveau des équipes de développement.

« Individuals and interactions over processes and tools »

Il s’agit du premier concept souligné par l’agile manifesto. Les fondements de l’agile sont la transparence, l’inspection et l’adaptation. Le principe est d’analyser les situations, d’apprendre de ses échecs et d’évoluer de manière empirique dans des environnements complexes. Le chemin vers l’agile et de DevOps peut être long et complexe, voici quelques étapes à franchir en s’inspirant de l’échelle de Tuckman :

Forming – Démarrer du bon pied

Devops est une histoire de personnes et de compétences avant tout. La formation est nécessaire afin que l’ensemble des équipes adoptent l’état d’esprit et la philosophie portée par le DevOps.

Storming – Etre confronté à la réalité

Une fois sur le terrain, les équipes formées feront face aux vraies difficultés. Durant cette phase, les interactions devront se mettre en place et les rôles et responsabilités de chacun en découler.

Norming – Mettre de l’huile dans les rouages

Une fois les process éprouvés, chaque équipe DevOps devra :

  • Mettre en place des processus d’amélioration continue.
  • Mesurer pour mieux améliorer.
  • Adapter et simplifier les process devant l’être.
  • Être pragmatique. Les objectifs communs seront l’augmentation de la réactivité des équipes et la diminution du Lead Time à son minimum.

Performing – en route vers l’excellence

À ce stade, l’équipe tire les fruits des changements opérés dans l’étape Norming. Les processus d’amélioration continue tireront l’équipe DevOps vers l’excellence, à la fois technique et collaborative. L’objectif : Changer son métier pour plus d’innovation et de performance !

Exemples à suivre: Amazon, Netflix, Spotify

En conclusion, DevOps est une histoire de personnes avant tout ! Les process ne doivent pas en bloquer l’adoption. Ils devront être au cœur de la transformation et potentiellement adaptés grâce à l’expérience des équipes. Une vision long terme est déterminante dans le succès d’une transformation Agile et DevOps. Changez votre métier pour le meilleur !

Les 7 points clés de la réussite du DevOps

Beaucoup d’articles parlent de DevOps, des clés du succès de DevOps sur leur projet, dans leur contexte. Voici ma vision des 7 ingrédients principaux qui font pour moi le succès d’une approche DevOps réussie. Cette liste n’est pas exhaustive, le sujet est vaste, d’autres ingrédients pourront être ajoutés suite à vos commentaires

1. Une culture commune

La culture sont la clé de voûte du DevOps. On parle aussi de DevOps comme un mouvement culturel, une philosophie qui vise à rapprocher les Dev des Ops. La culture du DevOps est pour moi la culture d’entreprise, du métier qui induit le professionnalisme des équipes. Une culture similaire facilite les échanges et la communication entre les personnes et ainsi créé une bonne synergie pour accomplir de grands exploits !

2. Une communication ouverte et transparente

La transparence est un des pilier de Scrum et de l’Agile. L’ensemble des membres d’une équipe DevOps doivent communiquer le plus efficacement possible et de manière transparente avec un objectif de partage de connaissance maximale. C’est crucial pour assurer une bonne dynamique du projet. Cela réduit aussi le stress de l’équipe et partage le fardeau de la responsabilité  sur l’ensemble de l’équipe DevOps en réduisant considérablement le risque de syndrome du Héro. « Tout seul on va vite. Ensemble on va plus loin ! »

3. Des outils communs

Tout comme dans la mécanique, il faut avoir de bons outils pour travailler de manière professionnelle ! Les outils améliorent considérablement l’efficacité de l’équipe et réuni par nature les métiers nécessaire à la création d’un logiciel réussi. Ces outils peuvent travailler et doivent s’intégrer en toute ergonomie à l’environnement de travail de l’ensemble des membre de l’équipe DevOps.

La plateforme Visual Studio Team Services est un excellent exemple de plateforme DevOps. Via une interface intuitive, elle centralise l’ensemble des artefacts du projet et permet le suivi du déploiement continu sur les environnements cibles du projet. De plus, cette plateforme est extensible et peut s’élargir au besoin d’autre fonctionnalités à partir d’un market place bien fourni !

4. Partager les victoires et les défaites

Historiquement, les Dev et les Ops ne partagent pas la même culture et exercent des métiers très différents. Les uns cherchent à intégrer le plus de changement et d’innovation possibles dans un produit sur la base des besoins des utilisateurs. Les autres recherchent la stabilité, la sécurité et la performance de l’application en production. Il existe parfois des tensions ou des incompréhensions entre ces deux population qui sont la plupart du temps dues au manque de vision globale du projet. Le DevOps a pour but d’adresser ce problème en fournissant une vision plus large à l’ensemble des membre du projet. Tout comme en agile, les succès sont partagés et toute l’équipe doit être récompensée ou remerciée (c’est un minimum !). Il en est de même pour les défaites. Ensemble, l’équipe DevOps est bien meilleure dans la défaite et pourra en tirer les enseignements pour les futures version du produit !

5. Un budget partagé

C’est sans doute la point le plus difficile à adresser dans les grands groupes où les process des finances sont bien enracinées dans la culture traditionnelle. Il faudra donc s’adapter pour que l’équipe DevOps soit vue comme une équipe à part entière et non comme deux équipes distinctes. En DevOps, par définition, il n’y a pas de phase Projet et de phase de Run à proprement parler. On délivre une première version le plus rapidement en production (Minimum Viable Product) et on la fait évoluer le plus souvent possible avec une équipe polyvalente et compétente. Si possible la taille de l’équipe DevOps doit rester identique sur toute la durée du projet (Consistancy Removes Complexity). D’un point de vue budget, cela correspond un peu à un mode d’abonnement au mois où l’on va garder la même charge. En théorie, c’est plus simple à calculer. C’est un peu comme si l’on payait un forfait mobile avec un iPhone. Cela revient au même coût au final, mais on a pas besoin d’avancer le coût du téléphone à chaque nouvelle mise à jour.

Dans la pratique, c’est un peu plus compliquer à aborder, il faut donc s’adapter aux systèmes de facturation existants… (Inspect and Adapt !)

6. Une méthode commune et appliquée

Dans le cadre d’un projet DevOps, l’application d’un framework Agile doit être très rigoureuse et partagée par l’ensemble de l’équipe. En DevOps, tout le monde parle la même langue, utilise les mêmes outils et communique efficacement. Il est toujours plus facile de jouer à un jeu lorsque les règles sont clairement définies. Un Scrum Master veilleura à l’application de ces règles et à la suppression de tout obstacle (Impediment) empéchant l’évolution de l’équipe DevOps.

Je conseille vivement la mise en place d’un Framework Agile à la fois strict et simple à comprendre tel que Scrum pour que l’ensemble de l’équipe puisse connaitre et maitriser ces règles rapidement dès le début du projet.

7. Des objectifs communs

Cela va sans doute de soi mais lorsque l’on est sur l’autoroute du DevOps, tout le monde doit rouler dans le même sens ! Notre destination doit être commune et notre équipe doit évoluer de concert en visant un objectif commun à court terme et en partageant une vision commune du produit !

J’espère que ces quelques points vous ont permis de mieux comprendre les enjeux et la philosophie du DevOps. Je suis preneur de vos retours d’expérience.