Les principes du DevOps

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 :

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...

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.

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...

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 !

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...

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

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

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.

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