DevOps ou le Lean appliqué aux activités IT du développement à la production

On a maintenant l’habitude de voir des principes du Lean Management derrière beaucoup des pratiques Agiles. Par exemple :

• Les tests unitaires et l’intégration continue, sorte de Andon et de Poka Yoke à la fois ;
• Les rétrospectives, support privilégié du Kaizen, sorte de cercle de qualité des équipes de développements ;
• Les taskboards, « kanban boards » et autres radiateurs d’information comme outil de management visuel ;
• etc.

Plus intéressant est l’exercice de voir les bonnes pratiques DevOps comme des instanciations du Lean Management aux activités de livraison, intégration, tests, déploiement, suivi du run.

Les analogies et principes sous-jacents du Lean pouvant alors nous aider à mieux comprendre la « magie » des pratiques DevOps ou même à en imaginer de nouvelles !

Les pratiques DevOps comme instanciation du Lean

Jidoka, l'autonomation

Le Jidoka est le premier pilier du Système de Production Toyota. C’est l’automatisation avec une touche humaine, ou comment automatiser les opérations simples et répétitives, tout en conservant un contrôle humain pour orchestrer tout cet outillage, et prendre en main les situations complexes. La légende veut qu’un fondateur Toyoda ait ajouté un système de détection d’anomalie et d’arrêt automatique sur des métiers à tisser.

En IT, DevOps poursuit la même démarche en poussant au maximum l’utilisation des robots d’intégration continue, de déploiement automatique, de configuration ou de supervision. Tools matter.

Just in Time, le juste à temps

Le Just in Time est le second pilier du Système de Production Toyota. C’est la mise en flux pour livrer juste à temps (ni avant ni après) le produit demandé, dans la quantité demandée. Les outils du Jidoka sont le lissage, la réduction de la taille des lots (livrer plus souvent de plus petits lots) et surtout la diminution du coût de traitement d’un batch avec SMED.

La comparaison avec DevOps saute aux yeux lorsqu’on cherche à mettre en production plus régulièrement de plus petits lots de fonctionnalité.

Une fois le principe du JIT saisi, nous avons entre nos mains les outils théoriques pour mieux comprendre nos problèmes de fréquence de livraison, notamment :

• débusquer les opportunités de « SMED » et de diminution du coût de traitement d’un lot dans notre process dev⇒prod afin de diminuer le coût d'un déploiement, pour tendre vers le déploiement en continu ;
• déterminer la taille de batch optimale, i.e. la taille de MEP optimale pour un niveau d’outillage et de process donnés (à optimiser par SMED en parallèle).

Kaizen, l'amélioration continue

Pilier du Modèle Toyota, le Le Kaizen, consiste à tirer des leçons des problèmes, enrichir notre « système » et ceci à travers une démarche structurée et des outils d’analyse éprouvés (PDCA, 5 pourquois, diagramme de Pareto etc). On a tous envie de s’améliorer, le Kaizen nous aide à structurer et rendre efficace ces efforts d'amélioration.

La communauté DevOps n’est pas en reste et reconnaît qu’elle fait face à des systèmes complexes qui échoueront tôt ou tard, les champions étant ceux qui tireront vite et bien les leçons des échecs petits et grands. A titre d’illustration, le livre Web Operations y dédie un chapitre entier : « How to Make Failure Beautiful: The Art and Science of Postmortems ».

L’autre aspect souvent négligé ou mal compris de l’amélioration continue en DevOps vient de la réduction de la taille des lots (i.e. l’augmentation des livraisons de plus petit « batch » de code). Le Lean prend l’image suivante : diminuer le niveau de l’eau fait apparaître les rochers entre lesquels ils faut naviguer. L’eau c’est le stock, dans notre cas tout ce qui n’est pas déployé, les rocher sont les problèmes. Quand on livre plus souvent on découvre plus souvent des problèmes. On peut dire qu’on met aussi en flux la découverte/résolution de problème ! Les problèmes sont plus fréquents, plus visibles, plus petits (moins de code), plus maitrisables.

Management de la performance

Le Lean Management, comme d’autres corpus de management insiste sur la pré éminence des métriques, les fameuses "KPI", pour factualiser la performance actuelle et l’écart à l’objectif et ainsi mieux piloter le navire. Gardons aussi à l’esprit la mise en garde de Deming qui nous explique que gérer une entreprise seulement par des métriques fait partie des 7 « maladies du management ».

DevOps insiste sur l’importance des métriques, aussi bien sur le système technique (utilisation des ressources, temps de réponse..) que sur le processus (« Time to Diagnose » d’incidents, Lead Time dev⇒prod etc). Mesurons plus nous disent les top performers du web.

Equipe pluridisciplinaire

Dans l’industrie Toyota a initié les cellules en U dans lesquelles un opérateur est multi compétent, passant d’un poste à l’autre, en suivant la pièce le long de la chaîne (à l’opposé du Charlot mono tâche des Temps Modernes). En Lean Product Development, Toyota a réduit à l’extrême ses délais de conception, notamment en rapprochant designers, motoristes et ingénieurs responsables de la production en série. DevOps : des dev plus ops, des ops plus dev, des dev et des ops qui binôment.

Conclusion

Il reste un dernier rapprochement entre devOps et le Lean. Womack et Jones ont inventé le terme « Lean » (« léger », « maigre » en anglais) car il trouvait la méthode japonaise plus légère que ses concurrentes occidentales (par exemple ISO), plus explicable, plus « maniable ». C’est ce même caractère de pragmatisme et d’utilisabilité qui frappe quand on compare DevOps à ITIL. Sur les problématiques communes DevOps/ITIL (notamment gestion des changements, gestion des alertes, capacity planning, amélioration continue...), les intentions sont identiques et les recommandations se recouvrent parfois. N’empêche : dans un cas le corpus de pratique est organique et actionnable, dans l’autre il est complexe et nécessite une expertise et une exhaustivité intimidante.

Redécouvrir et approfondir les principes et pratiques du Lean Management nous permet alors d'apporter des gains substantiels au traitement des problématiques DevOps.

Les gurus de la communauté Lean (par exemple Jez Humble, auteur de Continuous Deployment ou les top performers de Wealthfront ou IMVU) ne s’y sont pas trompés lorsqu’ils basent leurs réflexions DevOps sur des outils du Lean comme le Value Stream Mapping, placent la littérature Lean en bonne place dans leur bibliothèque, ou envisagent les problèmes DevOps avec les mots et les concepts du Lean.

Ces derniers mois, les consultants OCTO ont régulièrement pioché dans la "mallette Lean" afin de rendre encore plus efficaces leurs interventions touchant au domaine DevOps.

En définitive, on redécouvre l’étonnante réponse à la question « qu’est-ce que des techniciens de l’industrie automobile peuvent apprendre aux stars de l’IT ». Beaucoup.