Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Passez au DevOps
  3. Les principes du DevOps
Extrait - Passez au DevOps Votre nouvelle façon de travailler
Extraits du livre
Passez au DevOps Votre nouvelle façon de travailler
1 avis
Revenir à la page d'achat du livre

Les principes du DevOps

Être centré sur le besoin client

1. La démarche agile

Le chapitre Pourquoi le DevOps et contexte d’apparition a pu mettre en évidence le fait que le DevOps est apparu comme une nécessité pour compléter la démarche agile sur le volet opérationnel. Le chapitre Le mur de la confusion a également montré que l’objectif premier est de permettre aux équipes de développement et de production de travailler ensemble, dans un même mouvement, pour un même objectif, au-delà des silos.

Cet objectif est à la fois simple à comprendre et demande une vraie remise en question dans sa mise en œuvre. Il s’agit, pour aller droit au but, de se concentrer uniquement sur la valeur apportée au client, en satisfaisant à ses besoins le plus efficacement et le plus rapidement possible. C’est le crédo agile.

Pour le démontrer, remontons un peu en arrière afin de comprendre en quoi cette pratique est construite sur un changement de perception du besoin qui amène à un changement sur la façon de concevoir les projets :

images/03EI01.png

Ce schéma montre qu’en premier lieu on inverse la pyramide définissant le triptyque [Périmètre/Fonctionnalités, Coût/Ressources, Délai], où le périmètre fonctionnel n’est plus l’élément fixe sur lequel s’ajustent le coût et le délai, mais devient l’élément variable, et par voie de conséquence fige le coût des ressources et le délai de déploiement.

La raison est simple : il s’agit de se donner la possibilité d’adapter le périmètre fonctionnel en fonction du vrai besoin, sans que cela nécessite davantage d’investissement. 

Ensuite, il montre le passage...

Construire en étant conscient de l’objectif

1. Le problème des objectifs intermédiaires

Dans une entreprise organisée en domaines d’expertise, la vision du produit détenue par chaque équipe se limite à l’engagement de ce qu’elle réalise pour les autres équipes. La vision d’ensemble de l’objectif est comprise au mieux par le chef de projet, qui détient une vue opérationnelle apportée par le cahier des charges ou par le donneur d’ordre du métier. En réalité, le vrai objectif business n’est souvent connu que des services marketing ou commercial qui déterminent un objectif en fonction des données à leur disposition. Ces données ne sont malheureusement pas toujours récentes, peuvent être partielles, ou déjà préinterprétées selon le canal qui les procure. Ce qui a été compris de l’objectif va ensuite être décliné dans les équipes opérationnelles.

images/03EI02.png

Dans le schéma précédent, il apparaît clairement que l’objectif est décliné du haut (le management ou les sachants), vers le bas (les équipes opérationnelles). À chaque déclinaison, l’objectif perd en cohérence et en vision d’ensemble, pour finalement être découpé en tranches techniques. C’est ici la pure application du taylorisme, avec une spécialisation des équipes techniques qui construisent des bouts de produits, sans savoir exactement ce qui sortira de leur assemblage, cette vision étant contrôlée par le management de haut niveau. 

On voit que dès la première déclinaison, la vision d’ensemble est découpée en besoins sur plusieurs produits...

Une responsabilité collective de bout en bout

Le fait de partager la vision et l’objectif global permet de gagner en maturité sur la chaîne de responsabilité. En effet, dans un système d’organisation structuré en silos par domaine d’expertise, la responsabilité de chaque silo se limite à l’objectif intermédiaire qui lui est assigné :

images/03EI04.png

Dans ce schéma, le découpage de l’objectif global en objectifs intermédiaires a finalement également impliqué le découpage des responsabilités. Dès lors, qui porte le résultat global ? Qui s’en sent véritablement responsable dans sa totalité aux yeux des clients et même de l’entreprise (à part le dirigeant) ?

Là encore, le DevOps apporte une vision différente et structurante en prônant la responsabilité collective de l’ensemble et de chacun des acteurs impliqués dans la réalisation, face au client et face à l’entreprise. Ce principe est complètement aligné avec l’idée de devoir apporter à chacun la vision sur l’objectif global. À partir du moment où il est partagé avec tous, chacun comprend les conséquences des décisions prises sur le résultat final.

Mais plus que cela, cette responsabilité collective implique une nécessaire coopération, et même une intrication, entre toutes les compétences qui contribuent au résultat. Comme le montre le schéma suivant, il n’y a qu’une seule équipe au sein de laquelle chacun porte la responsabilité du résultat final.

images/03EI05.png

Le DevOps va également plus loin dans la portée de la responsabilité. En effet, il amène l’idée d’une...

Des équipes cross-fonctionnelles et autonomes

1. L’équipe cross-fonctionnelle

Au regard de ce qui a été mis en évidence sur le partage de l’objectif global et sur la responsabilité collective, une question évidente se pose : comment fait-on pour organiser une responsabilité collective ?

La réponse est à la fois simple et perturbante dans nos contextes organisationnels habituels. Il s’agit de mettre en place une équipe cross-fonctionnelle pour chaque produit, ou portefeuille de produits. Ce que l’on entend par cross-fonctionnelle c’est qu’elle dispose de toutes les compétences nécessaires pour construire le produit "from concept to grave".

Plus précisément, elle devra disposer des compétences dédiées et nécessaires à la réalisation du produit : un représentant du métier, marketing ou opérationnel, un product owner, un Scrum Master, un architecte, des développeurs, testeurs, et des ingénieurs système pour le déploiement et la production. Cela fait beaucoup de monde, mais l’idée n’est pas d’enfermer les membres de l’équipe dans leur domaine d’expertise, bien au contraire !

images/03EI06.png

Une équipe cross-fonctionnelle qui se limiterait à additionner simplement les expertises ne ferait que reproduire à petite échelle le problème qu’elle est censée résoudre à plus grande échelle : le fractionnement de la responsabilité. En cas de problème, il serait alors facile, et humain, de rejeter la faute sur l’autre au prétexte de ne pas se sentir concerné par le sujet.

Comme l’a longuement répété le père fondateur du DevOps, Patrick Dubois...

S’améliorer en continu

1. Un outil systémique au cœur de l’équipe

Le management classique et pyramidal repose sur deux principes clés :

  • La rétention de l’information, du haut vers le bas. Plus nous descendons dans l’échelle de l’organisation, plus cette information est reçue partiellement et amène à ne se concentrer que sur une petite partie de la production de valeur de l’entreprise.

  • Le contrôle du travail réalisé. Ce point est complètement lié au précédent car les équipes opérationnelles ne disposant que d’une vision parcellaire de l’objectif final, il devient alors nécessaire de contrôler le résultat de leur travail afin de s’assurer qu’il concourt bien à l’objectif. Autant dire qu’avec 8 projets sur 10 qui échouent, l’efficacité de ce contrôle managérial paraît très relative !

Dans la mesure où le DevOps transgresse ces fondements managériaux en rendant l’équipe autonome, il devient alors essentiel de mettre en place un dispositif qui permet à l’équipe d’évaluer son résultat. Ce dispositif lui permettra de mener les actions de correction pour s’améliorer et faire face aux problèmes rencontrés.

Il ne s’agit pas d’un simple vœu reposant sur la bonne volonté de l’équipe, mais d’un dispositif systémique, ritualisé et au cœur du fonctionnement du DevOps. Le DevOps reprend ainsi l’un des piliers du Lean en systématisant l’amélioration continue, un principe popularisé par la fameuse roue de Deming.

images/03EI10.png

La notion de "check", la phase de vérification de la roue de Deming, ne doit...

Automatiser tout ce qui peut l’être

Les principes d’amélioration continue vus précédemment sous-tendent presque inévitablement le besoin d’automatiser le maximum d’actions possibles. Quelle que soit la plateforme technologique utilisée, le fait d’intégrer et de déployer des solutions applicatives impliquent des actions redondantes d’installation, de configuration, de retraitement des données. Toutes ces actions sont aujourd’hui complètement automatisables (l’ensemble de ces principes seront abordés plus loin dans ce livre).

L’automatisation est l’outil indispensable à l’amélioration de la qualité et à l’application de ces principes. Il sera ainsi possible d’automatiser l’intégration du code venant des développeurs, les tests unitaires et d’intégration, le montage des éléments systèmes nécessaires à l’exécution de l’application, même chose pour le réseau, etc. Par ailleurs, le Cloud et les technologies de conteneurisation permettent littéralement de coder le déploiement de l’application, de la réservation de ressources système jusqu’à la configuration des composants applicatifs.

Enfin, l’automatisation est un accélérateur puissant du flux d’activités nécessaires à la construction d’un produit. Le principe itératif incrémental de l’agilité implique la réalisation par petit pas, chaque pas, et même chaque changement ou évolution requérant la réalisation de toutes ces activités.

images/03EI16.png

Sans automatisation, la réalisation de chacune des étapes aurait un coût trop important qui empêcherait de finaliser...