Kanban, ToC, 6 sigma, Lean : quand l’industrie inspire la gestion de projet agile

La gestion de projet web, et plus généralement le monde du logiciel, a tout un tas de particularités qui la rendent peu comparable avec l’univers de l’industrie classique. Dans une production manufacturière, un produit est en effet conçu, prototypé, testé, optimisé, puis passe en industrialisation. Dès lors que cette phase d’industrialisation a débuté, il s’agit de produire des articles identiques ou présentant de légères variantes en très grande quantité. Lors de la réalisation d’un logiciel, l’essentiel de l’activité de « fabrication » de celui-ci est confondu avec sa conception.

Dès lors, il paraît peu vraisemblable que des méthodes venues du monde de la production automobile – par exemple – fonctionnent pour améliorer la maîtrise d’un projet web. Et pourtant, plusieurs de ces méthodes fonctionnent plutôt bien avec quelques adaptations et peuvent compléter de manière très pertinente la vision agile d’un Scrum ou d’un XP.

Un petit tableau Kanban pas cher !

Un petit tableau Kanban pas cher ! (pioché chez Wikipedia)

Lean : la chasse aux gaspillages

Le « Lean Manufacturing » (littéralement « production maigre ») est une méthode d’élimination de différents gaspillages venue de chez Toyota. Après avoir conquis de nombreuses industries, le lean s’est immiscé dans le développement logiciel, en étant particulièrement relayé par quelques apôtres de l’agilité.

Mary et Tom Poppendiek, premiers promoteurs du LSD (Lean Software Development) insistent donc sur la détection de tout ce qui ne contribue pas directement à la valeur d’un logiciel. Ils reprennent ainsi la liste des 7 sources de gâchis (les « Mudas ») faite pas Shigeo Shingo pour l’industrie et en donnent des équivalents software :

Gâchis industriel Gâchis logiciel
Stocks Développements incomplets
Opérations supplémentaires Processus supplémentaires
Surproduction Fonctionnalités peu utiles
Transferts de pièces Changements de tâches
Attente Attente
Déplacements d’opérateur Déplacements
Défauts Défauts

Les Poppendieck livrent quantité d’astuces pour diminuer ces Mudas logiciels tout en s’inscrivant complètement dans un mode de pensée agile. Allez donc à la pêche dans leur trousse à outils, vous en trouverez sans doute un que vous pourrez mettre en oeuvre rapidement.

Kanban : un encours de production plus maîtrisé

Kanban est une méthode qui a quelque chose de magique pour qui a pu la mettre en oeuvre dans une usine : en limitant la quantité d’en cours à ce qui peut être identifié par un nombre bien choisi d’étiquettes « tournantes », on parvient à réduire de manière brutale les encours et à fluidifier de manière remarquable le cycle de production.

La transposition de Kanban dans une équipe de développement a la même déconcertante simplicité : limiter le nombre d’un type de tâches spécifiques pouvant être traitées à un moment donné. Derrière cette approche a priori simpliste se cache là aussi des gains de réactivité impressionnants dès lors que quelques défis ont été relevés : en particulier trouver les bonnes valeurs « limite » pour chaque type de tâche et déterminer de bonnes règles de priorisation.

Tout comme pour le Lean dont il est un proche parent, Kanban se marie particulièrement bien au mode agile. Je vous recommande par exemple la lecture de « Kanban et Scrum : tirer le meilleur des deux« , un livre libre (et aimablement traduit en français par quelques fans) qui explique par l’exemple comment mettre en oeuvre Kanban dans une organisation Scrum.

ToC : trouver le goulot d’étranglement

La Théorie des Contraintes et sa bible « le But », roman industriel génial d’Eliyahu Goldratt, restent, même dans le monde de la production, aujourd’hui encore trop peu connus. Son principe fondateur tient en quelques mots : « ce qui détermine la capacité de production de votre chaîne, c’est la production du goulot d’étranglement ». Imaginez des voitures roulant sur une route où il est impossible de dépasser, ce qui déterminera la vitesse de la file de voitures, c’est le rythme de la plus lente : inutile dans ce cas de gonfler le moteur des autres tant que rien n’aura été fait pour accélérer la plus lente.

Il est tout à fait possible d’adopter la ToC et sa méthode « Drum-Buffer-Rope » dans une chaîne de production logicielle. Il suffit pour cela de détecter la ressource goulot et d’optimiser son fonctionnement. Si vous identifiez par exemple que sur un projet, la ressource goulot est au niveau du process de recette, vous devrez faire en sorte que les chargés de la recette aient toujours quelque chose de « recettable » lorsqu’ils sont disponibles… vous pouvez même dans ce cas précis aller jusqu’à rythmer la production de chaque étape de réalisation du logiciel en fonction du processus de recette.

Bonus : en réduisant les encours et en synchronisant les équipes, la ToC s’accorde parfaitement avec l’Agile, Lean et Kanban !

6 sigma : qualité et prédictibilité

Le 6 sigma est une démarche qualité née chez Motorola dans les années 80 qui a véritablement connu son essor dans les années 90-2000 quand General Electrics l’a popularisée. 6 sigma est dans ses fondements proche des philosophies classiques de la qualité : l’amélioration permanente des processus via une mesure régulière de leur efficacité. Là où 6 sigma met l’accent, c’est sur la diminution de la variabilité des processus : si une manière de faire les choses obtient toujours des résultats proches, on évitera les imprévus et donc les défauts. Complémentaire des approches précédentes, la tendance des dernières années dans les industries est d’associer 6 sigma et Lean (le « Lean 6 sigma »).

6 sigma est une boîte à outils tellement volumineuse qu’il est facile de se fourvoyer en essayant d’emporter ses concepts dans un projet logiciel. Il vaut mieux donc faire un premier tri et regarder du côté du 6 Sigma pour la conception de nouveaux produits. On regardera alors en priorité les méthodes de recueil des attentes des clients afin de détecter ce qui est vraiment critique pour eux et donc pour la qualité de vos logiciels.

Par où commencer ?

Difficile de donner des règles génériques puisque chaque organisation aura des problèmes qui la feront bénéficier plus rapidement d’une approche que d’une autre. Je me risquerai quand même à avancer que Kanban est relativement simple à démarrer et permet rapidement de mettre en lumière les endroits qui posent problème : cela peut donc être un bon point de départ.

Advertisements

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s