Au cours de ma carrière de consultant puis plus récemment de coach DevOps, j’ai souvent constaté l’incompréhension qui règne entre les différentes parties prenantes de la fourniture d’un service informatique.
Les intérêts et les objectifs des uns vont parfois à l’encontre de ceux des autres. L’antagonisme souvent mis en avant entre Dev et Ops est, à ce titre, emblématique.
Entre des Dev qui veulent aller plus vite jusqu’à la mise en production qu’ils estiment parfois qu’ils sont en mesure de maîtriser et des Ops soucieux de la prise en compte anticipée des exigences techniques et des normes et standards de la production.
Ceci ne doit pas nous faire oublier qu’il y a, au cœur de toute initiative DevOps qui se respecte, un travail sur la culture, l’organisation Agile et l’outillage et qu’une grande partie des objectifs du DevOps est source de motivation pour l’ensemble de ses parties prenantes.
Cet article propose une analyse des profils types des principaux acteurs impliqués dans le DevOps sous forme de personas. Nous proposerons, ensuite quelques moyens de concilier les motivations des uns et des autres pour donner toutes les chances de succès à la mise en place progressive de nouveaux modes de fonctionnement.
Les Parties prenantes
Dans cette partie, je propose une descriptions des acteurs du DevOps avec l’aide des « personnas » qui permettent de présenter chaque profil comme s’il s’agissait d’une personne dont on décrit les principales caractéristiques.
Commençons par l’ingénieur de développement. Dans de nombreuses structures, il intervient au sein d’une équipe agile de 4 à 8 personnes. La mise en œuvre des principes Agile et leur appropriation par les équipes est une des conditions nécessaires au DevOps.
Je vous présente Franck, il est sysadmin, ingénieur de production, on l’appelle plus simplement l’Ops. Il est notamment le garant des règles de la production, du respect des normes et standards techniques et de la traçabilité de ce qui est fait en production.
Amélie est middle Manager dans L’IT. Depuis l’avènement des équipes agile, son rôle change. Elle a parfois du mal à trouver sa place dans ce nouvel écosystème.
Paul est directeur informatique. Qu’il soit CIO, CTO ou CDO, il doit composer avec un SI historique qui ne peut évoluer qu’à grand renfort d’investissements importants et l’avénement (et l’urgence) du digital. Il sent bien que ces histoires d’Agilité et de DevOps ont quelque chose de bon mais il a souvent du mal à le quantifier.
Représentante ultime des utilisateurs et de la raison d’être de l’entreprise, Françoise est à la tête d’une direction métier. Elle ne cherche pas particulièrement à comprendre l’IT mais voit d’un assez bon œil l’implication directe de ses équipes dans les projets informatiques.
Et après ?
Alors que faire avec tout cela ?
Cela peut ressembler de prime abord à un champs de contraintes…
Mais à y regarder de plus près et en allant au-delà de la mise en place d’un pipeline de distribution (qui est bien souvent la partie immergée de l’iceberg DevOps), il y a pas mal de choses à faire pour alimenter la motivation des parties prenantes et avancer résolument sur le chemin :
- Accorder une place à l’Ops au sein de l’équipe intégrée
- Se doter d’une structure permettant de définir et faire évoluer les normes et standards
- Adosser l’initiative DevOps à une démarche Cloud volontaire
- Identifier, mesurer et suivre des indicateurs alignés avec les objectifs du DevOps
- Faciliter le design et la mise en place de communautés par practice
Allons voir chacun de ces points d’un peu plus près…
Accorder une place à l’Ops au sein de l’équipe intégrée
De quoi s’agit-il ?
De faire en sorte qu’un Ops puisse prendre part à tout ou partie des rituels de l’équipe intégrée
Pour quoi faire ?
- Prendre en compte le plus tôt possible les exigences non fonctionnelles liées notamment à la sécurité, la disponibilité, la continuité et les intégrer au backlog produit…
- Guider l’équipe dans le respect des bonnes pratiques de production et la bonne utilisation des normes et standards
- Permettre d’apporter un éclairage sur la faisabilité technique de certains développements et sur les capacités d’évolution des normes en cours
- Faciliter la compréhension des outils orientés Ops du pipeline DevOps
Gains pour l’ensemble des parties prenantes :
- Time To Market accéléré par l’anticipation des enjeux techniques et un meilleur respect des normes
- Standardisation progressive du SI en évaluant mieux et plus en amont le coût du « non standard »
- Accélération de l’adoption des outils du pipeline
Accorder à l’Ops sa juste place au sein de l’équipe intégrée est, à mon sens, un des fondements de la démarche DevOps.
Se doter d’une structure permettant de définir et faire évoluer les normes et standards
De quoi s’agit-il ?
De standardiser et de normaliser les environnements techniques mis à disposition pour héberger les applications informatiques
Pour quoi faire ?
- Maintenir et faire évoluer le référentiel des normes et standards en prenant en compte les nouveaux besoins techniques des équipes
- Proposer et faire connaître les règles et le processus de gestion du référentiel
- Permettre aux évolutions et innovations de s’inscrire plus harmonieusement dans l’existant
Gains pour l’ensemble des parties prenantes :
- Connaissance et bonne utilisation des normes et standards
- Gain de temps et d’énergie pour maîtriser les environnements
- Maîtrise du processus de soumission d’une évolution ou d’une innovation
DevOps et automatisation riment nécessairement avec standards connus et appliqués.
Adosser l’initiative DevOps à une démarche Cloud volontaire
De quoi s’agit-il ?
De mettre à disposition de façon rapide et fiable les environnements standards
Pour quoi faire ?
- Disposer d’environnements de façon prédictible
- Bien maîtriser le provisioning / dé-provisioning
- Pouvoir distinguer différentes qualités de service (sécurité, disponibilité, résilience,…) selon les besoins
Gains pour l’ensemble des parties prenantes :
- Accélération du Time To Market à tous les stades du cycle de vie
- Le juste environnement au juste prix pendant la durée qui convient
- Garantie du standard
- Adaptation possible au niveau infrastructure, Plateforme ou Applicatif
Pas de DevOps sans provisioning d’environnements automatisé donc pas de DevOps sans Cloud.
Identifier, mesurer et suivre des indicateurs alignés avec les objectifs du DevOps
De quoi s’agit-il ?
De disposer de métriques qui permettent de mesurer le succès de l’initiative DevOps
Pour quoi faire ?
- Légitimer la démarche
- Motiver les troupes
- Renforcer l’alignement des objectifs et des moyens nécessaires pour les atteindre
Gains pour l’ensemble des parties prenantes :
- Gagner en confiance
- Accueillir et célébrer les succès
- Se fixer de nouveaux objectifs encore plus ambitieux
Les équipes n’agissent pas uniquement dans le sens de ce qui les motivent mais aussi par rapport à ce qui est évalué/mesuré.
Faciliter le design et la mise en place de communautés (par métier, domaine business, rôle, type d’outils…)
De quoi s’agit-il ?
De permettre de structurer la connaissance collective et de faire en sorte qu’elle se diffuse
Pour quoi faire ?
- Structurer la documentation et les binaires utilisés
- Permettre un accès et une contribution simple à la connaissance
- Fournir assistance et partage de bonnes pratiques
Gains pour l’ensemble des parties prenantes :
- Possibilité d’avoir accès à de la documentation et l’expertise pour mettre en place et utiliser certains outils du DevOps
- Ré-utilisation accrue de l’intelligence de l’organisation
- Enrichissement mutuel des membres des communautés et recensement des compétences.
Le DevOps implique de nombreux corps de métier. Il serait illusoire de penser tous les maîtriser au sein d’une entité centralisée.
En conclusion
Une initiative DevOps qui atteint ses objectifs commence le plus souvent par du « bien travailler ensemble ».
Intégrer les Ops au sein de l’équipe agile est, de ce fait, LA priorité qui va permettre une bonne acculturation Agile/DevOps et de favoriser la compréhension mutuelle des cultures, enjeux et objectifs. Ce faisant, les équipes apprennent à travailler efficacement ensemble et l’osmose entre le fonctionnel et le technique peut se faire. Disponibles en production plus tôt et avec une meilleure qualité, les développements sont également plus pertinents par rapport au socle technique de l’entreprise et l’émergence de nouveaux besoins permet de moderniser et de standardiser le SI.
Découvrez aussi notre vidéo sur le rôle du coach DevOps