Agitips – Framework – Lean Software Development

Lorsqu’on évoque Lean, la majorité des personnes pensent à Toyota. Savez-vous que les racines du Lean sont plus anciennes ? D’ailleurs le mot Lean n’a pas été créé par Toyota.

Tout commence officiellement avec Henry Ford. Ce que je trouve passionnant dans l’Histoire, c’est qu’à chaque fois qu’on parle d’une invention, nous nous rendons compte que l’inventeur s’est basée sur les idées d’une autre personne. Il y a intégré sa réalité et une nouvelle découverte est née. Nous pouvons remonter ainsi indéfiniment. Mais trêve de digressions, nous utiliserons Henry Ford comme point de départ.

De Henry Ford au Lean Manufacturing

Nous sommes dans les années 1920 et Henry Ford souhaite produire en masse le Model T.

Afin d’y arriver, il a développé un système sur le flux de production. Cette méthodologie se concentre sur le fait d’éliminer le gaspillage; les spécifications étaient strictes et les critères de qualité très élevés. Henry Ford a nommé cette méthodologie  » Manufacturing Strategy« . Grâce à cela, le temps d’assemblage d’une voiture est passé de 12h à 1h30. C’est ainsi qu’il est devenu l’un des hommes les plus riches au monde à cette période.
Ford avait construit son industrie dans un monde de précarité. L’économie s’est relancée et les besoins se sont diversifiés. Il n’a pas fait évoluer sa stratégie et c’est ainsi que le déclin a commencé.

Nous arrivons aux années 1950 et Taiichi Ohno qui faisant face à une crise chez Toyota décide d’aller aux USA trouver de nouvelles idées. Il est ébloui par le système de gestion des supermarchés. Il revient au Japon avec l’idée du Just-In-Time production, thème largement abordé dans l’article de Kanban.
Taichi Ohno révèle avoir été impressionné par le système de Ford et a intégré certaines des pratiques pour construire the  » Toyota way « plus connu sous le nom de Toyota Production System ou TPS.

En 1990, le livre The Machine That Changed the World de James P. Womack, Daniel T. Jones, et Daniel Roos, a donné un nouveau nom à ce qu’on appelait auparavant le Just-in-Time ou système de production Toyota. L’approche de Toyota en matière de fabrication deviendra connue sous le nom de Lean Production.
Au cours des années suivantes, de nombreuses entreprises ont tenté d’adopter le Lean Production, mais cela s’est avéré remarquablement difficile. Comme avec tous les nouveaux modèles industriels, la résistance de ceux qui ont investi dans l’ancien modèle a été féroce. Beaucoup de gens ont trouvé le Lean contre-intuitif et n’avaient pas une motivation profonde pour changer les habitudes établies depuis longtemps.
Très souvent aussi, les entreprises n’ont mis en place qu’une partie du système. C’est une erreur que nous retrouvons dans beaucoup de transformations. Les entreprises ne prennent que les principes qui leur « conviennent » en oubliant que la méthodologie est un tout.

Malgré les défis qu’ont posé la mise en œuvre d’un nouveau paradigme contre-intuitif, de nombreuses initiatives Lean ont connu un immense succès, créant des entreprises véritablement Lean qui ont invariablement prospéré. La pensée Lean est passée de la fabrication à d’autres domaines opérationnels aussi divers que le traitement des commandes, les ventes au détail et la maintenance des aéronefs. Les principes Lean ont également été étendus à la chaîne d’approvisionnement et au développement de produits.

 

Le Lean Software Development

Le framework « Lean software development » est né du livre du même nom, écrit par Mary Poppendieck et Tom Poppendieck en 2003 dans lequel ils appliquent les principes Lean manufacturing au développement logiciel. Ci-dessous les principes et éléments tirés du livre qui est excellent et que je recommande chaudement.

Les principes Lean et leur application au développement logiciel

Principe 1: Eliminer le gaspillage

Taiichi Ohno a qualifié le système de production Toyota de système de gestion pour « l’élimination absolue des déchets ». Lorsqu’on lui a demandé comment cela fonctionnait, il a répondu :

Tout ce que nous faisons, c’est examiner le calendrier à partir du moment où un client nous donne une commande jusqu’au moment où nous percevons l’argent. Et nous réduisons ce délai en éliminant les déchets à valeur non ajoutée.

Le Lean software a adopté le même principe.

Pour éliminer le gaspillage, il faut d’abord l’identifier.

Étant donné que le gaspillage est tout ce qui n’ajoute pas de valeur, la première étape de l’élimination du gaspillage consiste à développer un sens aigu de la valeur. Il n’y a pas d’alternative que de développer une compréhension profonde de ce que les clients apprécieront réellement une fois qu’ils commenceront à utiliser le logiciel.

La deuxième étape consiste à être capable de reconnaitre le gaspillage.

Par exemple: la fonctionnalité partiellement développée est l’un des plus grands gaspillages: il se perd, devient obsolète, cache les problèmes de qualité, et bloque les revenus.
En outre, une grande partie du risque dans le développement de logiciels réside dans le travail partiellement effectué.

Mais la plus grande source de déchets dans le développement de logiciels est de loin les fonctionnalités supplémentaires. Seulement environ 20% des fonctionnalités et des fonctions dans les logiciels sont utilisées régulièrement. Environ les 2/3 des fonctionnalités sont rarement utilisées.  Il y a un coût énorme à développer des fonctionnalités supplémentaires et qui n’étaient pas nécessaires au départ dans un logiciel. Cela ajoute de la complexité au code; ce qui fera grimper son coût à un rythme alarmant, le rendant de plus en plus coûteux à entretenir, ce qui réduira considérablement sa durée de vie utile.

Principle 2: Intégrer la qualité

Le but est d’intégrer la qualité dans le code dès le début, pas de le tester plus tard. On ne met pas l’accent sur les défauts lors des suivis de test, on évite de créer des défauts au départ. Il faut une entreprise très disciplinée pour le faire.

Si vous voulez vraiment de la qualité, vous n’inspectez pas après coup, vous contrôlez les conditions afin de ne pas permettre les défauts en premier lieu. Si ce n’est pas possible, alors vous inspectez le produit après chaque petite étape, de sorte que les défauts sont attrapés immédiatement après qu’ils se produisent. Lorsqu’un défaut est détecté, on arrête la ligne, on en trouve la cause et on le corrige immédiatement.

Shigeo Shingo – Toyota

L’objectif des tests, et des personnes qui développent et exécutent les tests, est de prévenir les défauts, pas de les trouver.
Une société axée sur la qualité devrait se faire le champion des processus qui intègrent la qualité dans le code dès le début. La vérification finale est une bonne idée. Si la vérification déclenche systématiquement des cycles de tests et de corrections, alors le processus de développement est défectueux.

Pour plus de qualité, écrivez moins de code. Pour écrire moins de code, nous devons trouver le 20% du code qui fourniront 80% de la valeur et écrire cela en premier.

Principle 3: Créer de la connaissance

Dans le cycle en V, on pense que les spécifications sont la base de la connaissance pour le produit. Néanmoins l’expérience montre que la connaissance se fait de manière quotidienne pendant le développement.

Il y a aussi le mythe que prévoir permet d’être prédictible. Ainsi beaucoup d’entreprises vont essayer de faire le design de tout le produit en amont. Ainsi l’entreprise prend des décisions quand on a le moins d’information car l’information s’acquiert au fur et à mesure de l’évolution du projet et des feedbacks.

Principle 4: Retarder la prise de décision

Il faut s’organiser afin de pouvoir prendre les décisions irréversibles le plus tard possible; c’est-à-dire à la dernière chance de prendre la décision avant qu’il ne soit trop tard. Cela ne veut pas dire que toutes les décisions devraient être reportées.
D’abord et avant tout, nous devrions essayer de rendre la plupart des décisions réversibles, afin qu’elles puissent être prises et facilement modifiées.

Mythe: La planification est un engagement

En préparant le combat, j’ai toujours trouvé que les plans sont inutiles, mais la planification est indispensable.

La célèbre citation de Dwight Eisenhower donne une bonne perspective sur la différence entre planification et engagement.
Selon Mary Poppendieck, la planification est un exercice d’apprentissage important, elle est essentielle pour développer les bons réflexes dans une organisation, et elle est nécessaire pour établir la conception architecturale de haut niveau d’un système complexe. Par contre, les plans sont surestimés. Et donc nous devrions planifier de façon réfléchie et nous engager avec parcimonie.

Principle 5: Livrer rapidement

Les entreprises qui se font concurrence en jouant sur la rapidité ont souvent un avantage financier important par rapport à leurs concurrents.
Avoir une vitesse reproductible et fiable est impossible sans une superbe qualité du produit. En outre, ces entreprises développent une compréhension profonde du client. Ils sont si rapides qu’ils peuvent se permettre d’adopter une approche expérimentale, d’essayer de nouvelles idées et d’apprendre ce qui fonctionne.

Il y a deux façons d’atteindre une grande qualité. Vous pouvez ralentir et être prudent. Ou vous pouvez former des gens qui améliorent continuellement leurs processus, intègrent la qualité à leur produit, et développent la capacité de répondre à leurs clients de façon constante et fiable beaucoup plus rapidement que leurs concurrents.

Principle 6: Respecter les personnes

Respecter les personnes signifie tenir compte du point de vue des gens qui font le travail de terrain.

Chef/Leader d’entreprise : Les gens aiment travailler sur des produits réussis, et les produits très réussis peuvent généralement être retracés à d’excellents leaders. Une entreprise qui respecte ses employés développe de bons leaders et s’assure que les équipes ont le genre de leadership qui favorise l’engagement, la réflexion des gens et concentre leurs efforts sur la création d’un excellent produit.

L’expert technique : Toute entreprise qui s’attend à conserver un avantage concurrentiel dans un domaine particulier doit développer une expertise technique dans ce domaine. Les entreprises qui achètent toute l’expertise dont elles ont besoin constateront que leurs concurrents peuvent aussi l’acheter. Celles qui ne voient aucun intérêt à l’expertise constateront qu’elles n’ont aucun avantage concurrentiel durable.

Le respect des personnes signifie que les équipes reçoivent des roadmaps modulables et des objectifs raisonnables. Cela signifie aussi qu’on leur fait confiance pour s’organiser pour atteindre les objectifs. Le respect signifie qu’au lieu de dire aux gens quoi faire et comment le faire, vous développez une organisation où les gens se servent de leur tête pour comprendre cela par eux-mêmes.

Principe 7 : Optimiser l’ensemble

Exemples de cercles vicieux tiré du livre de Mary et Tom Poppendieck:

Cercle vicieux No 1 (bien sûr, cela ne se produirait jamais dans votre entreprise) :
Un client veut de nouvelles fonctionnalités « hier. » Les développeurs entendent : fsaites-le rapidement et à n’importe quel prix!
Résultat :

  • Des changements négligents sont apportés à la base de codes.
  • La complexité de la base de codes augmente.
  • Le nombre de défauts dans la base de codes augmente.
  • On assiste à une augmentation exponentielle dans le temps pour ajouter des fonctionnalités au code.

Cercle vicieux No 2 (et cela ne se produirait pas non plus dans votre entreprise) :
Les tests sont surchargés de travail.
Résultat :

  • Le test a lieu longtemps après le codage.
  • Ce qui empêchent développeurs de faire un retour arrière rapidement si nécessaire.
  • Ainsi les développeurs créent plus de défauts.
  • Et par conséquent les testeurs ont plus de travail. Les systèmes ont plus de défauts.
  • Répéter le cycle.

Optimiser l’ensemble signifie optimiser tout le process. Ceci à partir du moment où elle reçoit une commande pour répondre aux besoins d’un client jusqu’à ce que le logiciel soit déployé et que le besoin soit comblé.

Le coeur de lean est dans la création de la valeur pour ses clients

 

 

Une organisation Lean optimise l’ensemble de la chaîne de valeur. La philosophie d’entreprise de Google en 2000, publiée sur son site Web, commençait par ces quatre points:

  • Concentrez-vous sur l’utilisateur et tout le reste suivra.
  • Il est préférable de faire une chose vraiment, vraiment bien.
  • La démocratie sur le Web fonctionne.
  • Il vaut mieux être rapide que lent.

Derrière chaque excellent produit, il y a une personne qui a beaucoup d’empathie pour le client, qui comprend ce qui est possible et qui est capable de voir ce qui est essentiel et ce qui est accessoire. Cette personne a une compréhension profonde du client ainsi que des capacités de ses propres équipes. Elle fonctionne à partir d’une base solide de connaissances et de confiance. Elle pense à offrir une valeur supérieure au marché, et elle définit de bons produits qui peuvent être exécutés avec un effort important.

Mary Poppendieck

LEAN OU AGILE

La méthodologie Lean est souvent appliquée pour améliorer les processus dans toutes les organisations. D’autre part, la méthodologie Agile est appliquée au sein d’une équipe, souvent composée d’au plus une douzaine de personnes.

L’ Agilité c’est construire. C’est un framework pour construire le bon produit avec un minimum de frais dans un environnement flou.

Le Lean est une pratique d’apprentissage pour développer les bonnes compétences afin d’offrir plus de valeur avec moins de déchets.

Régis Medina

 

 

C’est tout pour l’introduction à Lean. N’hésitez pas à jeter un coup d’oeil à l’introduction à l’AgilitéKanban et Extreme Programming.

N’hésitez pas à poster des questions en commentaire.

Références:

 

Share:

Facebook
Twitter
Pinterest
LinkedIn
Fanny Ndengue

Fanny Ndengue

Je travaille en tant que coach, formatrice et consultante pour aider les organisations à créer de meilleurs produits et les cadres à bâtir les cultures qui construisent de meilleurs produits.

Leave a Comment

Your email address will not be published. Required fields are marked *

On Key

Related Posts

Agitips – Frameworks agiles: Kanban

Aujourd’hui nous démarrons la série d’introductions aux frameworks agiles. Le premier de notre liste est Kanban, souvent cité et très souvent mal compris. Pour rappel,