Élimination du « Gaspillage »

Photo de Sohrab Salimi
Sohrab Salimi
3 min. Temps de lecture
Ce contenu a été traduit par IA. Voir l'original

L'un des principes Lean est d'éliminer le « Waste » (en français : gaspillage). Ce concept a été développé à la fin des années 1940 dans l'industrie manufacturière par Toyota. À l'époque, la fabrication de véhicules était très coûteuse et les entreprises devaient demander des prix très élevés aux clients. La seule façon pour Toyota de réduire le prix des voitures était de diminuer les coûts de fabrication.

Que signifie « Waste » en Lean ?

Le « Waste » ou « Gaspillage » est fondamentalement le contraire de « Value », c'est-à-dire la « Valeur » (une capacité livrée au client qui lui apporte un avantage direct ou indirect). Par exemple, une réunion d'équipe sans motif concret est une pure perte de temps.

Voici les sept types de gaspillage identifiés dans le Système de Production Toyota (TPS) par Shigeo Shingo :

  1. Stocks : produits non finis (WIP : work in progress)

  2. Surproduction : produire plus que ce que la demande exige

  3. Traitement : étapes de travail supplémentaires dans le processus qui ne sont pas nécessaires

  4. Transport : transporter des marchandises d'un endroit à un autre

  5. Temps d'attente : intervalles entre les différentes étapes de traitement

  6. Mouvements : mouvements inutiles dans le processus

  7. Défauts : erreurs sur les produits qui affectent leurs caractéristiques et fonctions

Quels sont les types de gaspillage dans le développement logiciel ?

À partir des sept types de gaspillage dans l'industrie manufacturière, Mary et Tom Poppendiek ont défini les sept types de gaspillage dans le développement logiciel :

  1. Travaux inachevés : À chaque Sprint, les membres de l'équipe sont responsables d'un nombre défini de User Stories. Parfois, ils n'arrivent pas à toutes les terminer. Ils doivent alors comprendre pourquoi ils n'ont pas pu y parvenir, afin de réduire ce type de gaspillage.

  2. Fonctionnalités supplémentaires : Au tout début, le Product Owner a créé une vision, puis un Product Backlog avec des fonctionnalités priorisées qui apportent de la valeur au produit. Cependant, le principe de Pareto indique qu'il n'est souvent pas nécessaire de développer toutes les fonctionnalités, car beaucoup d'entre elles sont inutiles.

  3. Apprentissage continu : À chaque Sprint, on accumule de plus en plus de connaissances qu'on peut utiliser pour éviter de réinventer la roue en permanence.

  4. Passation : Ici, le travail est transmis à une autre personne dès que la première a terminé. Comment y remédier ? Le mieux est d'éliminer les dépendances entre les User Stories (et les fonctionnalités) ou de confier toutes les User Stories ayant des dépendances à une seule équipe pour atténuer le risque.

  5. Retards : C'est tout ce qui retarde la livraison ou le démarrage d'une activité créatrice de valeur. Comment l'éviter ? Il faut éliminer les goulots d'étranglement et repenser chaque processus lent pour les harmoniser.

  6. Changement de tâches : Cela se produit quand le Product Owner modifie ses priorités et que les membres de l'équipe doivent passer d'une User Story à une autre sans pouvoir terminer la précédente. La raison principale est souvent que le Product Owner n'a pas une vision claire du produit, ou qu'un concurrent a lancé un nouveau produit et qu'on souhaite adapter et sortir le sien le plus rapidement possible.

  7. Défauts : C'est l'un des plus grands problèmes dans le développement logiciel. Au bout d'un certain temps, on a accumulé une montagne énorme de dette technique, et à partir de là, il faut investir beaucoup de temps et d'efforts pour la réduire progressivement, Sprint après Sprint.

En conclusion, je peux dire que beaucoup de gens pensent que Lean n'est pas une bonne approche pour une équipe qui travaille avec Agile. Mais ils se trompent. En réalité, chaque entreprise devrait d'abord appliquer Lean, puis passer à Agile !!!

Ce texte provient du blog de Mario Lucero et a été traduit en français par nos soins.

Product Backlog Refinement

=> Voici comment se déroule un Backlog Refinement dans les équipes Scrum.

Comment se déroule une Sprint Review dans les équipes agiles ?

=> Découvre ici comment peut se dérouler une Sprint Review idéale.

Parle à notre assistant Parle à notre assistant