Congratulations! Your support has been sent to the author
# Les 5 courants ayant donné naissance à la culture DevOps

# Les 5 courants ayant donné naissance à la culture DevOps

Published Sep 12, 2022 Updated Sep 12, 2022
time 5 min
1
Love
0
Care
0
Wow
thumb 0 comment
lecture 68 lectures
3 reactions

On Panodyssey, you can read up to 10 articles per month without being logged in.
Enjoy 9 articles more articles to discover this month.

To have unlimited access, log in or create an account by clicking below, it's free! Sign in

# Les 5 courants ayant donné naissance à la culture DevOps

Le DevOps est apparu à la suite de mouvements convergeant dans le management et les technologies qui ont débuté en 1980 avec les principes Lean Management et qui s'est formalisé en 2009 avec l'émergence de la culture DevOps.

Le flux de production d'une chaîne logistique a été adapté au flux de production logiciel avec toujours le même objectif : convertir le plus efficacement possible et par étapes successives un besoin client en un produit. Dans notre cas un logiciel ou un ensemble de services apportant de la valeur au client.

Initialement mis en place dans l'industrie, les principes du Lean Management ont été appliqués à la technologie de 3 façons :

  • L'optimisation du flux de production
  • La culture du feedback
  • L'apprentissage continu et l'expérimentation

# Les principes Lean (1980)

Créés par Toyota en 1980, les principes du Lean ont été adaptés au flux de production de valeur technologique :

  • L'optimisation du flux de production avec la suppression des gaspillages pour apporter plus rapidement la valeur au client (produit)
  • La culture du Feedback avec la mise en place d'un environnement favorisant le leadership, la prise de responsabilité et le partage
  • L'apprentissage, l'amélioration continue et l'expérimentation

Le Lean a également apporté à l'agilité et au DevOps des outils de management visuel grâce à l'apport du "Value Stream Mapping" : la visualisation des flux de livraison d'un logiciel, plus connu sous le nom de tableau Kanban.

Enfin, il a contribué au remplacement du traditionnel cycle en V en démontrant, l'intérêt de livrer de plus petits incréments logiciels en limitant le nombre de feature. Cela a permis de rendre plus simple la détection et la correction des erreurs, le contrôle de la qualité et de la sécurité.

# La théorie des contraintes (1984)

La théorie des contraintes, également appliquée initialement dans l'industrie s'appuie sur le principe que : **le débit d'une chaîne de valeur (industrielle ou logicielle) est égal au débit de son goulot d'étrangement**. Ce goulot d'étrangement doit être l'objet de toutes les attentions.

Il s'agit, plus globalement, de s'attaquer à tout ce qui pourrait ralentir le flux de production :

Un manque de capacité : qui génère du retard

Les tailles de lots trop élevés : qui retardent la détection d'erreurs et le time to market (donc feedback client).

  • La complexité des flux : qui est inhérent à la traduction de tout besoin client en produit et pourtant ne délivre pas de valeur. Le flux d'enregistrement d'un besoin,
  • Le flux de validation, la transmission entre les équipes, le flux de contrôle et de mise sur le marché augmentent le WIP (Work in Progress) mais de délivre rien,
  • Le pilotage et l'optimisation des coûts de revient*t souvent difficiles à identifier dans la production logicielle.

En assurant des cycles de livraison plus courts comprenant les features demandées par le marché, en contrôlant plus régulièrement la vélocité des équipes (compétences et capacité à produire) et enfin, en automatisant les flux de validation, de contrôle sécurité et de la qualité (tests d’acceptance et de non-régression) plusieurs contraintes inhérentes au développement logiciel ont été réduites permettant d’accélérer le Time To Market.

# L'agilité (2001)

L'Agile Manifesto est le regroupement de l'ensemble des valeurs et principes de l'agilité. Il a l'avantage d'apporter une dénomination commune et de sacraliser le terme "agilité".

On retrouve l'apport du Lean et de la théorie des contraintes dans l'un des principes clés établie dans le manifeste : "Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois".

L'agile manifesto ne demandera que quelques minutes de lecture à l'adresse https://agilemanifesto.org/iso/fr/manifesto.html.

# Le Toyota Kata Mouvement (2009)

Le Kata Mouvement est un principe d'amélioration continue basée sur la répétition et la mise en place de changements progressifs, nécessitants peu d'effort. À l'image des Kata dans les Arts Martiaux, plus l'on enchaîne un même mouvement, plus il devient coutumier plus il se perfectionne et devient habituel. Le mouvement demande alors moins d'effort à produit, ce qui se traduit par un gain de temps et d'énergie (ressource).

Le Kata Mouvement comprend 4 étapes clés :

  • 1. Identifier et comprendre la vision : il s'agit généralement d'un défi permettant d'accomplir la vision (un axe d'amélioration par exemple) et de définir des objectifs à court terme
  • 2. Définir la condition actuelle de l'entreprise : l’enjeu est de posséder une compréhension claire de l'entreprise (processus, activités, organisation, produit, etc.)
  • 3. Établir la prochaine condition cible : il s'agit d'un objectif clair et mesurable à atteindre pour progresser dans l'accomplissement de la vision
  • 4. Expérimenter à l’aide du PDCA (Plan, Do, Check, Act) afin d’avancer et surmonter les obstacles de façon itérative.

Le Kata Mouvement vient ajouter au Lean management les notions de routines et d'amélioration continue journalière. Le rôle du coach est également introduit. Il accompagne les équipes afin d'améliorer leur capacité et compétences au travers de cérémonies centrées sur le feedback (ce qui était planifié, ce qui a été fait, les difficultés rencontrées, ce qui va être fait).

# Le Continuous Delivery Movement (2006-2009)

Le Continuous Delivery Movement a permis d'étendre les principes d'automatisation d'intégration des changements de code et de test aux Infrastructures afin que le logiciel et les infrastructures (serveurs / services) possèdent des états cohérents, permettant de passer en production n’importe quelle version d'un logiciel.

Le concept de pipeline de déploiement est né, complétant le pipeline d’intégration des codes et assurant ainsi le lien entre le Dev (le code) et l’Ops (l’Infra).

# En conclusion

Le DevOps n'est pas un mouvement purement technique. Il est global aux organisations et demande une bonne compréhension du métier et des enjeux business. Il est le fruit de 40 ans d'expérience dans l'optimisation des flux dans les supply chains et des chaînes de valeur technologiques. Le Lean, la théorie des contraintes, L'Agilité et le Kata mouvement en son ses pères, bien qu'il soit devenu un courant à part entier.

Empathec@IT-Metrics

[âpatèk] 
Capacité d'une personne possédant un savoir-faire technique à accompagner une tierce personne dans l'expression de son besoin en intégrant ses enjeux, ses problématiques et ses émotions afin d'en réaliser la mise en œuvre technique. L'empathec désigne par extension l'ensemble des savoir-être impliqué dans la démarche d'accompagnement et de formalisation du besoin dans le référentiel méthodologique souhaité.

lecture 68 lectures
thumb 0 comment
3 reactions
Share the article
copylink copylink

Comment (0)

Do you like Panodyssey articles?
Support their independent writers

Extending the travel in the universe Tech
Guillotine
Guillotine

Machine dangereuse qui bien à...

Bernard Ducosson
1 min
Paul O'Neill et la culture DevOps
Paul O'Neill et la culture DevOps

# Baisse des accidents chez Alcoa : les 2 principes DevOps appliqués par Paul O'Neill en 1987 J'aimerais imager l'importance de...

Fabrice Milon
2 min

donate You can now support your favorite writers on Panodyssey!