… à l'Ecole de la V.I.E …

Les 12 pratiques de XP (eXtreme Programming)

La méthode XP s’appuie sur 12 pratiques.

Les 12 Pratiques XP

– Planning Game

– Petites Releases

– Utilisation de métaphores

– Conception simple

– Tests unitaires et tests unitaires (fonctionnels) / TDD (Test Driven Development)

– Refactoring

– Programmation en binôme

– Appropriation collective du code

– Intégration continue

– Pas de surcharge de travail

– Client sur site

– Standard de code (compréhension partagée)

Bien sûr il ne faut pas oublier les Tests Client qécoulent de ces 12 pratiques XP.

Planning Game

Cette pratique a pour but de planifier uniquement les releases. La planification se fait sous forme de jeu auquel participent les développeurs et le client. Pendant une première phase dite d’exploration, le client exprime ses besoins en termes de fonctionnalités. Pour cela, il les écrit sous forme de « user stories », c’est à dire sous forme de courtes descriptions du comportement qu’il attend du système, exprimées avec un point de vue utilisateur. Au cours de cette même phase, les développeurs attribuent à chaque user story un nombre de points, fonction du temps qu’ils estiment nécessaire au développe- ment des fonctionnalités contenues dans chaque user story. S’il s’avère que les user stories nécessitent un temps de développement trop long, elles sont découpées en scénarios élémentaires. Dans une deuxième phase dite d’engagement, les user stories sont triées en fonction de la valeur qu’elles apportent au client et des risques encourus lors de leur développement. Ceci permet d’aboutir à un classement des user stories par ordre de priorité. En fonction de la vélocité de l’équipe, les développeurs et le client s’entendent sur la quantités de user stories qui seront développées au cours de l’itération à venir et qui constitueront la prochaine release. La vélocité évoquée ci-dessus est un indicateur du nombre de points qui peuvent être développées au cours d’une itération (elle se calcule en faisant le rapport du nombre de points développés au cours de l’itération précédente et du produit du nombre de développeurs par la durée de l’itération). Enfin la phase de direction permet de mettre à jour le planning de la pro- chaine release. Cette pratique permet de combiner les priorités du client avec les estimations des développeurs afin de convenir du contenu de la prochaine release et de la date à laquelle elle devra être prête.

Petites Releases

Pour une bonne gestion des risques, la sortie des releases doit intervenir le plus souvent possible. En conséquence, d’une version à l’autre, l’évolution doit être la plus petite possible, tout en s’efforçant d’apporter le plus de valeur ajoutée et des fonctionnalités dans leur intégralité.

Cycles de développement courts (entre 1 et 4 semaines) pour livrer souvent, produire de la valeur ajoutée à chaque livraison, intégrer les nouvelles fonctionnalités de façon continue et obtenir un retour rapide sur le travail effectué pour corriger le tir très rapidement si quelque chose ne va pas.

Utilisation de métaphores

XP recommande d’utiliser des métaphores pour décrire l’architecture du système. De telles images permettent à tout le monde (y compris les commerciaux qui n’ont pas forcément de grandes compétences techniques) d’avoir une vision globale du système et d’en comprendre les éléments principaux ainsi que leurs interactions.

Conception simple

La simplicité est une des valeurs fondamentales d’XP. Il faut toujours développer la solution la plus simple possible et éviter de développer plus que ce dont on a besoin. Ceux qui pratiquent XP résument cela sous la phrase YAGNI (« You ain’t gonna need it », « vous n’en aurez pas besoin »). Les seules exigences sont de satisfaire tous les tests, de ne jamais dupliquer une logique et d’utiliser le moins possible de classes et de méthodes. Dans ce même ordre d’idées, la documentation produite lors d’un projet XP se réduit au minimum vital, c’est à dire la documentation demandée par le client.

Tests unitaires et tests unitaires (fonctionnels) / TDD (Test Driven Developpement)

Les tests unitaires sont écrits et effectués par les développeurs pour vérifier le bon fonctionnement et la non régression des méthodes ou des constructeurs. Pour une qualité de code encore meilleure, il est recommandé d’écrire les tests avant le code de l’application. Les tests fonctionnels sont conçus par le client et lui permettent d’une part de vérifier le fonctionnement global du système, de contrôler l’évolution du projet, et d’affiner l’expression de ses besoins.

Xp recommande l’utilisation de tests automatisés pour assurer la qualité et la stabilité du code produit.

TDD (Test Driven Development) :

Le TDD est une des composantes essentielles de XP car c’est elle en grande partie qui permet la mise en place et le maintient des tests automatisés. Le principe même du Test Driven Development est de commencer sa démarche d’écriture de programme par l’écriture des tests qui permettront de tester les fonctions à implémenter puis de mettre en place ces fonctions « pas à pas » en vérifiant toujours que les tests écrits pour la fonction « passent » (la fonction de test obtient le résultat attendu en utilisant le code fourni, l’aspect du code testé est implémenté et se comporte comme souhaité) une fois que ce qu’ils doivent tester a été implémenté. L’urgence absolue à traiter en priorité dans un tel type de développement est un test qui ne « passe » plus (régression) alors qu’auparavant il ne posait pas de problème. Résoudre le problème à la source de la régression est bien plus important que n’importe quoi d’autre dans un tel contexte.

Refactoring (remaniement) du code

Les développeurs d’un projet XP doivent s’habituer à retravailler un peu chaque jour du code existant et fonctionnant parfaitement pour le maintenir propre, le rendre plus lisible et plus robuste.

Le but de cette pratique est de simplifier le code, tout en faisant en sorte que tous les tests soient satisfaits. D’un point de vue purement fonctionnel, cette simplification n’est pas nécessaire puisqu’elle intervient sur du code qui fonctionne parfaitement. En revanche, le refactoring du code assure que l’ajout de fonctionnalités supplémentaires sera facilité. Le refactoring tend à produire un code mieux pensé, plus modulaire, sans duplications de code et donc plus facile à maintenir.

Xp prone le refactoring régulier pour assurer la qualité et la stabilité du code produit.

Le fait de livrer si régulièrement permet de toujours disposer d’une base « saine » de code au cas ou des changements seraient à inclure.

Programmation en binôme (Pair Programming)

Toute l’écriture du code se fait à deux personnes sur une même machine, avec une seule souris et un seul clavier. On distingue deux rôles : le pilote (« driver »), celui qui a le clavier, cherche la meilleure approche sur une portion de code bien précise tandis que l’autre développeur, le « partner » peut observer avec beaucoup plus de recul et ainsi suggérer d’autres solutions ou soulever des problèmes d’ordre plus général. Au premier abord, cette pratique peut sembler être une perte de temps, mais il s’avère que le travail se fait plus vite, que le code est de meilleure qualité (moins d’erreurs de syntaxe, meilleur découpage, etc.), avec une meilleure compréhension du problème.

Pour les développeurs, le travail est moins fatiguant. Les binômes ne doivent pas être statiques : chacun change de partenaire relativement souvent. Ceci pour un meilleur partage des connaissances et pour permettre à chacun d’avoir une relativement bonne vision sur l’ensemble du code.

Travail en binômes (« deux cerveaux mais un clavier »), pour éviter les erreurs et favoriser l’amélioration continue et la maintenabilité d’une application (si deux personnes ont travaillé sur une portion très particulière de code et qu’une s’en va, il en reste toujours une qui sait très bien de quoi le code parle sans avoir à le reparcourir). Le pair programming est aussi utile en ce sens que les 2 personnes qui travaillent sur un même « bout de code » ne réfléchissent pas aux mêmes choses selon qu’elles sont au clavier ou pas. La personne au clavier va avoir tendance à se concentrer sur le « comment » (aspects purements techniques) et son binôme sur le « pourquoi » (voir l’image d’ensemble et empêcher son binôme de dévier).

Appropriation collective du code

Toute l’équipe est sensée connaître la totalité du code (plus ou moins dans le détail selon les parties, évidemment). Cela implique que tout le monde peut intervenir pour faire des ajouts ou des modifications sur une portion de code qu’il n’a pas écrit lui même si cela s’avère nécessaire.

Intégration continue

Après chaque fin de tâche, c’est à dire plusieurs fois par jour, le code nouvellement écrit doit être intégré à l’existant de manière à avoir à tout moment un existant fonctionnel qui passe avec succès tous les tests. Ainsi, quand une tâche est démarrée, elle peut se fonder sur la version la plus à jour de ce qui a déjà été fait.

Pas de surcharge de travail

L’objectif est de ne pas dépasser 40 heures de travail par semaine pour les développeurs. Il ne s’agit pas de chercher à travailler peu, mais les spécialistes d’ eXtreme Programming ont pris conscience du fait que la surcharge de travail, en plus d’être désagréable, est néfaste. En effet, le code devient moins bien pensé, le refactoring est laissé de côté, ce qui conduit à une baisse de la qualité et à une recrudescence des bugs. En vertu de ce principe, une équipe ne doit jamais être surchargée de travail plus de deux semaines consécutives. Si cela devait toutefois se produire, l’équipe se doit de réagir en redéfinissant la quantité de user stories à implémenter au cours de l’itération ou en modifiant sa manière de procéder.

Client sur site

L’implication forte du client passe par la présence sur site d’une personne minimum à temps plein pendant toute la durée du projet. Cette personne doit avoir à la fois le profil type de l’utilisateur final et une vision plus globale du contexte pour pouvoir préciser les besoins, leur donner une ordre de priorité, les transcrire sous forme de user stories, et établir les tests fonctionnels. La présence du client sur site est dictée par des impératifs en matière de réactivité. En effet, au fil de la programmation, les développeurs soulèvent fréquemment des questions sur des points non abordés ou restés obscurs. En étant sur place, le client peut ainsi apporter immédiatement des réponses à ces questions, évitant ainsi que les programmeurs commencent à développer certaines fonctionnalités sur la base de ce qu’ils supposent être les désirs du client. La présence à temps plein du client sur site n’implique pas forcément que cette activité occupe la totalité de son temps : il est tout à fait envisageable pour le client de continuer une partie de son activité tout en étant délocalisé auprès de l’équipe de développeurs.

Standard de code (compréhension partagée)

Il est nécessaire de disposer de normes de nommage et de programmation pour que chacun puisse lire et comprendre facilement le code produit par les autres. Ceci est d’autant plus essentiel que la propriété du code est collective et que les programmeurs sont amenés à changer de binôme régulièrement. En général, les conventions adoptées lors des projets XP sont assez intuitives et résultent de pratiques plutôt naturelles chez les développeurs.

Mise en pratique :

– Conventions de nommage

– Appropriation collective du code

– Conception simple

– Utilisation de métaphores

Justification des pratiques XP

Voici donc les 12 pratiques XP. Chacune d’entre elle est suivie d’une justification provenant de la définition de Kent Beck :

1. Le jeu de planification permet à toutes les personnes impliquées dans le projet de prendre des décisions. En plus, cela sert à la création d’une planification de livraison.

2. La livraison constante de petites versions permet d’obtenir les réactions de la part du client et influence le développement du système pour qu’il ne prenne pas une mauvaise tangente.

3. Les métaphores set à avoir un vocabulaire commun et une vue d’ensemble du système à développer.

4. La conception simple favorise la capacité de compréhension et de modification du code.

5. Les tests unitaires et de régressions sont plus importants que la documentation et doivent être fait avant l’implémentation du code.

6. L’amélioration constante du code simplifie et rend les modifications futures de plus en plus facile à maintenir.

7. La programmation en paire permet de repérer les erreurs tôt dans le cycle de vie de développement du logiciel.

8. La propriété collective consiste à dire que le code appartient à tout le monde et que chaque développeur est responsable du bon fonctionnement du code.

9. Une intégration continuelle doit se faire. De préférence, plusieurs fois par jours et en roulant tous les tests unitaires à chaque itération.

10. Un horaire de 40 heures par semaine permet une bonne condition physique et mentale.

11. Le client doit être sur le site où être disponible en tout temps pour permettre aux développeurs d’avoir des réponses à toutes leurs questions. Cela permet aussi de résoudre les incompréhensions.

12. Des standards de code doivent exister et ils doivent mettre l’emphase sur la communication au sein de l’équipe.

XP utilise les « best practices » et tente de les mettre en pratique. Travailler avec une telle méthodologie permet de mettre l’emphase sur les développeurs et sur le code source.

Les 4 valeurs de XP (eXtreme Programming)

XP met en avant quatre valeurs prenant en considération à la fois les enjeux commerciaux et les aspects humains des projets de développement d’applications.

Les 4 valeurs :

– communication

– simplicité

– feedback

– courage

Ainsi les 4 valeurs de XP sont la communication, la simplicité, la rétroaction et le courage.

La communication chez XP propose d’utiliser des conseillers permettant de favoriser la communication.

La simplicité consiste à implanter dans le système des choses simples et auxquelles nous sommes sûr qu’elles seront utilisées dans le futur.

La rétroaction se fait à l’aide de tests unitaires qui doivent être écrient avant même de commencer à coder. Ainsi, tant que les tests unitaires ne fonctionnent pas, le travail n’est pas fini.

Finalement le courage est valorisé par la méthode XP du fait qu’elle :

1. Donne plus d’audace ;

2. Permette de choisir des bonnes solutions plus risquées ;

3. Permet de faire des conceptions plus simples.

Communication

L’absence de communication est certainement l’un des défauts les plus gra- ves qui mettent en péril un projet. Diverses pratiques XP tendent à rendre la communication omniprésente entre tous les intervenants : entre développeurs (programmation en binôme), entre développeurs et managers (tests, estimations), entre développeurs et clients (tests, spécifications). Toutes ces pratiques qui forcent à communiquer ont pour but de permettre à chacun de se poser les bonnes questions et de partager l’information.

Simplicité

Cette valeur de simplicité repose sur le pari qu’il coûte moins cher de développer un système simple aujourd’hui quitte à devoir engager de nouveaux frais plus tard pour rajouter des fonctionnalités supplémentaires plutôt que de concevoir dès le départ un système très compliqué dont on risque de n’avoir plus besoin dans un avenir proche. XP encourage donc à toujours s’orienter vers la solution la plus simple qui puisse satisfaire les besoins du client.

Feedback

Le retour est immédiat pour les développeurs grâce aux tests unitaires. Pour les clients, le retour se fait à l’échelle de quelques jours grâce aux tests fonctionnels qui leur permettent d’avoir une vision permanente de l’état du système. Un feedback permanent est positif pour le client qui a une bonne vision du projet, peut détecter tout écart par rapport au planning et à ses attentes de manière à les corriger rapidement. Pour les développeurs, un feedback permanent permet de repérer et de corriger les erreurs beaucoup plus facile- ment. Cette notion de feedback est indispensable pour que le projet puisse accueillir le changement.

Courage

Du courage est nécessaire aussi bien chez le client que chez les développeurs. Pour mener à bien un projet XP, le client doit avoir le courage de don- ner un ordre de priorité à ses exigences, de reconnaître que certains de ses besoins ne sont pas toujours très clairs. De son côté, le développeur doit avoir le courage de modifier l’architecture même si le développement est déjà bien avancé, de jeter du code existant et d’accepter qu’il est parfois plus rapide et efficace de réécrire une portion de code à partir de zéro plutôt que de bricoler du code existant.

Respect et valeurs

Enfin, ces quatre valeurs interagissent entre elles et découle tous d’une valeur primordiale qui est le respect.

Agile et l’eXtreme Programming (XP)

XP (eXtreme Programming)  a été créé en 1996 par Ward Cunningham et Kent Beck

Historique de XP

Kent Beck fait plusieurs promesses aux développeurs, aux responsables et aux clients :

– Promesses aux développeurs
1. Travailler sur ce qui compte vraiment pour le client ;
2. Aucune décision à prendre pour lesquelles la personne n’est pas qualifiée ;
3. La possibilité de faire tout ce qui est possible pour que le système fonctionne.

– Promesses aux responsables et aux clients
1. Recevoir le maximum de valeur pour chaque semaine de travail ;
2. À chaque semaine le système comportera de nouvelles fonctionnalités ;
3. Une flexibilité leurs permettant de changer de direction rapidement sans que les implications financières soient exorbitantes.

But de XP

La suppression des risques existants sur un projet représente la philosophie d’XP.

En introduisant cette méthode, ses créateurs veulent en finir avec la dérive de délais, l’annulation des projets, la non-qualité, la mauvaise compréhension du métier du client et l’impossibilité de suivre les changements.

Les 4 valeurs de XP

XP met en avant quatre valeurs prenant en considération à la fois les enjeux commerciaux et les aspects humains des projets de développement d’applications :

– communication

– simplicité

– feedback

– courage

Les 12 Pratiques XP

– Planning Game

– Petites Releases

– Utilisation de métaphores

– Conception simple

– Tests unitaires et tests unitaires (fonctionnels) / TDD

– Refactoring

– Programmation en binôme

– Appropriation collective du code

– Intégration continue

– Pas de surcharge de travail

– Client sur site

– Standard de code (compréhension partagée)

Les  5 piliers de XP

– Communication

– Simplicité

– Feedback

– Respect

– Courage

Les Principes de base

– Feedback rapide

– Assumer la simplicité

– Changements incrémentaux

– Accueillir le changement à bras ouverts

– Un travail de qualité

– Apprendre à apprendre

– Faible investissement au départ

– Jouer pour gagner

– Communication ouverte et honnête

– Travailler avec et non contre les instincts de chacun

– Responsabilités acceptées

– Adaptation aux conditions locales

– Voyager léger

– Mesures honnêtes

Cycle de vie d’un projet XP

Les grandes lignes du cycle de vie d’un projet XP :

– Exploration

– Planning

– Itérations jusqu’à la 1ère release

– Mise en production

– Maintenance

– Mort

Les Rôles dans XP

– Développeur

– Client

– Testeur

– Tracker

– Coach

– Consultant

– Big boss

Pilotage de projet XP

– Importance du client
Encadre
Spécifie
À plein temps
User stories

– Réunions
Scénario
Estimation
Plan de développement

Forces et faiblesses

– Avantages
Rapidité
Réactivité
Productivité
Compétence
Légereté

– Inconvénients
Maintenance
Blocage culturel
Limite de taille

Quand choisir XP?

Choisir la méthode XP en fonction de :

– Expérience

– Dynamisme

– Culture

– Taille

– Criticité

Si vous voulez en découvrir davantage, vous pouvez consulter aussi :

Les 4 valeurs de XP (eXtreme Programming)

Les 12 pratiques de XP (eXtreme Programming)

Les principes de base de XP (eXtreme Programming)

Le cycle de vie de la méthode XP (eXtreme Programming)

Les rôles dans la méthode XP (eXtreme Programming)

Avantages et inconvénients de la méthode XP (eXtreme Programming)

Agile et le Feature Driven Development (FDD)

Feature Driven Development est une méthode agile développée par Jeff de Luca et Peter Coad en 1997 pour mieux gérer les risques existants dans les projets de développement.

L’idée de base de la méthode est de procéder par itérations très courtes, de deux semaines, avec production à la fin de chaque itération d’un livrable fonctionnel.

Les spécifications sont découpées le plus possibles en caractéristiques simples : les « features » que l’on peut regrouper en « feature sets ».

Intérêt

– pour le client

Les clients ont une vue claire sur le planning et les différentes étapes du projet. Ils ont aussi des résultats concrets qui leur prouvent l’avancée du projet.

– pour les managers

Du point de vue des managers, cette façon de procéder permet de connaître facilement l’état d’avancement du projet et d’avoir du concret à montrer au client à chaque fin d’itération. Le fait de délivrer fréquemment des composants fonctionnels permet aussi une bonne gestion du risque.

– pour les développeurs

Pour les développeurs, procéder par itérations est très motivant puisqu’ils doivent être capables de livrer toutes les deux semaines des composants qui sont utiles au client, qui fonctionnent et sont porteurs de valeur pour lui.

Bénéfice

Cette pratique encourage la créativité, l’innovation et l’exploration et conduit à la découverte de nouvelles fonctionnalités qui apporteront un avantage concurrentiel.

Notions de   » Feature  » et  » feature set « 

– Feature

Feature désigne une fonctionnalité porteuse de valeur pour le client, susceptible d’être implémentée en deux semaines ou moins.

Le formalisme utilisé pour les décrire est le plus simple possible : <action> the <result> <by, for, of, to> a(n) <object> (ex : calculate the total of a sale).

Ce découpage en fonctionnalités simplissimes permet au client d’exprimer ce qu’il attend de manière très simple.

– Feature set

Ces features sont regroupées en groupes qui participent à une même fonction plus globale.

Le formalisme utilisé pour décrire les feature sets est alors : <action><-ing> a(n) <object> (ex : making a product sale to a customer).

En pratique, les 5 phases d’un projet FDD

Phase 1 : Développer un modèle global

Phase 2 : Établir une liste détaillée de features classées par priorité

Phase 3 : Planifier à partir des features

Phase 4 : Concevoir à partir des features

Phase 5 : Construire à partir des features

Forces et faiblesses de FDD

FDD présente les avantages des méthodes agiles, à savoir gestion des risques, flexibilité par rapport au changement, rapidité, livraisons fréquentes, etc. FDD a déjà été utilisé avec des équipes de taille conséquente pouvant aller jusqu’à une vingtaine de développeurs. Le facteur limitant cependant la taille d’une équipe est le nombre de développeurs seniors à disposition. La propriété du code revenant aux propriétaires de classes a l’avantage de ne permettre des modifications que par une personne qui a une vision globale d’une classe. On peut opposer à cela le principe de propriété collective du code en vigueur dans eXtreme Programming qui nécessite une plus grande discipline mais peut s’avérer plus rapide si un développeur a besoin de modifier du code écrit par un autre membre de l’équipe. L’inspection du code permet d’apporter un regard neuf sur chaque portion du code et permet ainsi de produire un code de meilleur qualité. Cependant, la personne qui inspecte le code ne le connaît pas a priori et il lui faut donc un minimum de temps pour se familiariser avec ce code. Encore une fois, il peut s’avérer plus judicieux de passer à la programmation en binôme pour éviter cette perte de temps et faire la révision du code en même temps que son écriture. FDD n’est d’ailleurs par fermée à ce genre de pratiques qui poussent l’agilité encore plus loin.

Agile et le Test Driven Development

Le TDD est une des composantes essentielles de XP (Exteme Programming) car c’est elle en grande partie qui permet la mise en place et le maintien des tests automatisés.

Le principe même du Test Driven Development est de commencer sa démarche d’écriture de programme par l’écriture des tests qui permettront de tester les fonctions à implémenter puis de mettre en place ces fonctions « pas à pas » en vérifiant toujours que les tests écrits pour la fonction « passent » (la fonction de test obtient le résultat attendu en utilisant le code fourni, l’aspect du code testé est implémenté et se comporte comme souhaité) une fois que ce qu’ils doivent tester a été implémenté.

L’urgence absolue à traiter en priorité dans un tel type de développement est un test qui ne « passe » plus (régression) alors qu’auparavant il ne posait pas de problème.

Résoudre le problème à la source de la régression est bien plus important que n’importe quoi d’autre dans un tel contexte.

Agile et le Test Driven Requirement (TDR)

Le Test-Driven Requirement ou spécification dirigée par les tests, propose :

• de centrer la description et la rédaction des besoins utilisateurs sur des exemples qui constitueront autant de futurs cas de tests de recette,

• de centrer la collaboration entre les équipes du projet sur la compréhension et l’enrichissement de ces exemples.

Dans une démarche TDR, il faut privilégier la description concrète plutôt que la modélisation :

– la description des fonctionnalités est affinée de façon collaborative tout au long du processus de développement

– les tableaux utilisés pas à pas, suite à différentes actions opérateur, permettent de visualiser concrètement les changements d’état successifs. Ils facilitent à la fois la compréhension du fonctionnel mais également l’identification des scénarii de tests les plus pertinents.

Agile et Crystal Clear

Plus qu’une méthodologie, Crystal est un cadre méthodologique très fortement adaptable aux spécificités de chaque projet.

Crystal ou plus précisément la famille de méthodologies Crystal  a été créé en 1997 par Alistair COCKBURN.

Le principe est de sélectionner la méthode applicable en fonction de la criticité du projet et du nombre de personnes à coordonner.

Nous nous intéresserons ici à une des déclinaisons de Crystal, Crystal Clear, qui s’ntéresse aux petites équipes Agile (6 personnes maximum).

Les valeurs partagées

Les valeurs partagées par l’équipe Crystal Clear sont :
– communication
– releases fréquentes
– souplesse

Communication :
La communication est omniprésente dans une équipe qui travaille avec la méthode Crystal. Ceci est une condition sine qua non pour réussir le « jeu coopératif » qu’est le projet. En effet, Alistair Cockburn écrit : « Software development is a cooperative game, in which the participants help each other in reaching the end of the game – the delivery of the software » La communication est tellement cruciale que le nombre de membres d’une équipe est limité à 6 personnes pour que l’équipe puisse fonctionner. Il est recommandé que tous les membres de l’équipe soient placés dans la même pièce ou, au pire, dans deux pièces voisines afin de faciliter la communication par la proximité. Toujours dans l’idée que la communication et la collaboration produisent un travail de meilleure qualité, les schémas de modélisation sont généralement faits en groupe sur un tableau blanc. Enfin, la collaboration avec les clients / utilisateurs est très serrée. Ce sont les utilisateurs qui expriment leurs besoins en écrivant des cas d’utilisation très sommaires. Toutes les précisions seront apportées par la suite au cours de conversation entre utilisateurs et développeurs.

Releases fréquentes :
Dans un souci de souplesse fac e au changement, il est très important d’es- pacer au minimum les releases. Cette pratique permet en outre au client d’avoir au moins une partie utilisable de son application sans attendre la fin du projet. Les livraisons fréquentes contraignent toutefois à réduire les livraisons au strict minimum utile : le code source commenté et le manuel d’utilisation.

Souplesse :
Crystal est une méthode très souple, tant au niveau des procédures à suivre que des normes à utiliser. Par exemple, les normes de codage et de nommage sont très peu contraignantes voire inexistantes pour certains points : ceci n’est pas problématique dans la mesure où la taille de l’équipe reste inférieure à 6 personnes et où ces personnes ont l’habitude de travailler ensemble, d’aider les autres à revoir leur code ce qui rend les normes quasi naturelles. L’équipe est relativement libre de s’organiser à sa guise : parmi les développeurs par exemple, on peut distinguer deux types d’approche. Certains commenceront par prendre une feuille de papier et un crayon pour essayer de schématiser la manière dont ils vont construire et organiser leur code avant de démarrer réellement la programmation. D’autres au contraire fonceront tête baissée dans l’écriture du code ce qui implique pour eux de consacrer plus de temps par la suite au refactoring du code. La méthode Crystal n’est pas directive sur la manière de procéder : les personnalités de chacun sont prises en compte et tant que le travail résultant est le même à la fin, la méthode reste d’une grande souplesse.

Le processus Crystal

Le processus Crystal se décline de la façon suivante :
– spécifications
– conception et planning
– itérations

Spécifications :
Une première phase consiste à interroger le client et les utilisateurs pour qu’ils expriment leurs besoins. Une pratique assez répandue consiste à observer les utilisateurs dans leur travail pour mieux connaître leurs besoins et leur environnement. Les spécifications sont collectées sous forme de cas d’utilisation sommaires : il s’agit de décrire en une phrase une interaction entre l’utilisateur et le système. En collaboration avec les utilisateurs, les différents cas d’utilisation sont classés par ordre de priorité ce qui permet de savoir quelles fonctionnalités ont le plus de valeur et quelles fonctionnalités sont à développer en premier.

Conception et planning :
Une première ébauche de conception est faite dans cette phase, c’est à dire au tout début du projet. Cela inclut le choix des technologies qui seront utili- sées pour la réalisation et une première ébauche de l’architecture pour se donner une vision globale. Enfin, juste avant d’entrer dans la phase itérative, il convient de planifier les itérations qui vont suivre. Crystal recommande des itérations d’une longueur d’environ 2 ou 3 mois, chacune produisant un livrable fonctionnel.

Itérations :
C’est au cours de cette phase que se fait la réalisation proprement dite de l’application. Le premier travail consiste à clarifier et préciser les spécifications au cours de discussions plutôt informelles entre utilisateurs et développeurs. Ensuite, les développeurs font tous ensemble un travail de conception pour déterminer la manière dont ils vont mettre en place les objets de base sur lesquels va s’appuyer le système. Les développeurs se répartissent les différentes parties. Dans les deux se- maines qui suivent le début d’une itération, il convient de mettre en place une maquette qui permettra de faire une démonstration aux utilisateurs. Cette pratique permet bien souvent de déceler des incompréhensions dans les besoins exprimés. Les développeurs sont ensuite libres de procéder comme ils l’entendent pour développer la partie dont ils ont la charge. Les tests sont omniprésents dans le processus de développement : l’architecture est conçue de manière à pouvoir supporter des tests régressifs et des tests automatiques. Les classes de tests font partie intégrante du code et sont souvent écrite avant le code lui même. Le refactoring du code est lui aussi permanent. Il se fait en général en binôme pour optimiser la qualité du code.
Deux ou trois fois par itérations, des démonstrations sont faites aux clients / utilisateurs ce qui permet de toujours bien recadrer le projet en conformité avec les exigences du client. L’écriture du manuel utilisateur est effectuée soit juste avant la livraison d’une release, soit dès le début de l’itération ce qui force les développeurs à définir plus précisément dès le début ce vers quoi ils s’engagent. L’itération se termine par l’intégration et la mise en production de l’application qui est testée une fois de plus avant d’être livrée au client.

Les pratiques Crystal

Les pratiques Crystal sont au nombre de 10 :
– petite équipe
– livraisons fréquentes
– aménagements permanents
– communication osmotique
– confiance, liberté d’expression et sécurité personnelle
– focus sur l’objectif et disponibilité
– contact permanent avec les utilisateurs
– environnement de travail approprié
– collaboration étroite
– réflexion constante

Les avantages de Crystal Clear

Crystal Clear présente tous les avantages des méthodes agiles : flexibilité par rapport au changement, rapidité, livraisons fréquentes, etc.
Par contre, dans la version que nous avons décrite ici, elle reste limitée à des équipes de taille inférieure à 6 personnes, en raison de l’absence d’une personne ou d’un groupe chargé de la coordination.
Les processus et pratiques de Crystal sont très souples et conviennent parfaitement pour des petites structures.

En fait, les approches Crystal et eXtreme Programming sont très proches, à ceci près qu’eXtreme Programming nécessite beaucoup plus de discipline et est plus contraignante. D’un côté, cette particularité rend eXtreme Programming certainement un peu plus productive que Crystal Clear, mais d’un autre côté, tout le monde n’est pas forcément prêt à en accepter les principes alors que Crystal Clear sera certainement acceptée plus facilement.

Agile et les bases du Lean Software Development

Les bases du Lean Software Development :

– Pratiquer l’amélioration continue, dans le respect des collaborateurs et partenaires, pour la recherche de l’excellence

– Challenger sa performance tous les jours

– Voir les problèmes

– Résoudre les problèmes

– En tirer les bons enseignements

Ceci est décliné dans Lean Software Development par les principes suivants :

• éliminer les gaspillages,

• favoriser la connaissance,

• construire la qualité intrinsèque,

• reporter la décision,

• livrer rapidement,

• respecter les personnes,

• optimiser le système dans son ensemble.

• accentuer l’apprentissage

• donner du pouvoir à l’équipe

• optimiser le système dans son ensemble

• améliorer votre système de développement car la plupart des erreurs sont systémiques

• améliorer le système en respectant les personnes

En conclusion, vous prendrez de meilleures décisions en étudiant votre flux de développement qu’en maximisant l’utilisation de vos ressources.

Le Lean Software Developement est basé sur les pincipes qui ont fait le succès de Toyota et de son fameux TPS (Toyota Production System).

Lean Software Development considère toutes les méthodes Agiles comme valides pour appliquer le « Lean Thinking » au monde du logiciel, et en particulier le déploiement de la méthode Scrum.

Agile et le but de Lean

Le but de Lean est le toit de la maison Lean.

But de Lean : livrer la valeur métier à un rythme rapide et durable.

Cela consiste en un Lead time le plus court et le plus durable possible, une valeur et une qualité maximales (pour les personnes et l’entreprise), une satisfaction maximale du client, des coûts les plus faibles, un moral élevé,une  sécurité accrue.

Globalement, le but de la pensée Lean est de livrer rapidement des choses de valeur (au client et à l’entreprise) avec des temps de cycle de plus en plus courts sur tous les processus, tout en atteignant de hauts niveaux de qualité et de moral, et sans prendre de retard dans le flux de valeur vers le client. Toyota s’efforce de réduire les temps de cycle, mais sans faire d’économies de bouts de chandelle, réduire la qualité ou sur un rythme risqué et insoutenable ; mais plutôt par une amélioration continue incessante, qui exige une culture d’entreprise axée sur un fort respect des personnes, lesquelles se sentent suffisamment en sécurité pour ne pas hésiter à remettre en cause et changer les règles établies.

 » Tout ce que nous faisons, c’est observer la ligne de temps, entre le moment où le client passe commande et celui où nous sommes payés. Et nous réduisons cette ligne de temps en réduisant les gaspillages générateurs de non valeur ajoutée.  » (Taiichi Ohno)

Le Lean se concentre donc sur le témoin, et pas sur les coureurs de relais, en supprimant les goulets d’étranglement pour accélérer la production de valeur vers les clients plutôt que d’essayer d’optimiser le système localement en tentant de maximiser l’utilisation des travailleurs ou des machines.

L’accent est mis sur les 2 principaux processus : développement et production.

Développement : Apprendre mieux et plus vite que la concurrence, en générant plus de connaissances utiles tout en les utilisant et s’en souvenant efficacement.

Production : S’améliorer mieux et plus vite que la concurrence, en se focalisant sur des cycles courts, par petits lots et files d’attente, en s’arrêtant pour trouver et corriger les causes racines des problèmes, en éliminant sans relâche tous les gaspillages (attentes, boucles, …).

Agile et les 14 principes Lean

Les 14 principes Lean constituent le ciment de la maison Lean et sont à l’origine du Lean Management.

Le Lean permet :

– de déterminer ce qui crée de la valeur pour le client

– d’identifier le flux de valeur

– de le rendre continu

– de rechercher la perfection

– de travailler en flux tendu

– d procéder à l’élimination de la variation, des gaspillages et de la surcharge

– de construire la qualité

– de faire l’intégration de la qualité dans les processus

– d’utiliser le management visuel

– de faire de la standardisation créative

– d’accompagner par la formation et le mentoring

Les 14 principes Lean constituent les fondations de la pensée Lean et de sa philosophie basée sur le long terme.

Les 14 principes Lean :

– 1. Penser sur le long terme : fondez vos décisions sur une philosophie à long terme, même au détriment des objectifs financiers à court terme. Les bons processus donneront les bons résultats.

– 2. Fluidité : organisez les processus en flux pièce à pièce pour mettre au jour les problèmes.

– 3. Flux tirés : utilisez des systèmes tirés pour éviter la surproduction.

– 4. Production constante et lissée : lissez la production (heijunka).

– 5. Automatisation avec une touche humaine : créez une culture de résolution immédiate des problèmes, de qualité du premier coup.

– 6. Tâches standardisée : la standardisation des tâches est le fondement de l’amélioration continue et de la responsabilisation des employés.

– 7. Contrôles visuels : utilisez le contrôle visuel afin qu’aucun problème ne reste caché.

– 8. Technologies et méthodes fiables : utilisez uniquement des technologies fiables, longuement éprouvées, qui servent vos collaborateurs et vos processus. Apporter de la valeur à l’organisation en développant les personnes.

– 9. Cultiver les leaders : formez des responsables qui connaissent parfaitement le travail, vivent la philosophie et l’enseignent aux autres.

– 10. Faire monter en compétence les personnes de qualité. Formez des individus et des équipes exceptionnels qui appliquent la philosophie de votre entreprise.

– 11. Respecter et motiver ses partenaires. Respectez votre réseau de partenaires et de fournisseurs en les encourageant et en les aidant à progresser. La résolution continue de problème est un moteur d’apprentissage pour l’organisation .

– 12. Aller toujours sur le terrain : allez sur le terrain pour bien comprendre la situation (genchi genbutsu).

– 13. Prendre les décisions en consensus : décidez en prenant le temps nécessaire, par consensus, en examinant en détail toutes les options. Appliquez rapidement les décisions.

– 14. Amélioration continue : devenez une entreprise apprenante grâce à la réflexion systématique (hansei) et à l’amélioration continue (kaizen).

Les 14 principes Lean se divisent en 4 catégories :

« Favoriser la connaissance », « Reporter la décision », « Livrer rapidement » peuvent se traduire par la segmentation en itérations courtes des projets Agiles, ce qui apporte aux entreprises clientes la prédictibilité dont elles ont besoin sur la disponibilité des fonctionnalités en cours de développement. Elles peuvent ainsi planifier l’intégration continue des nouvelles fonctions à leur rythme et en fonction des ressources disponibles, sans surcoût ni surcharge de travail qui induisent de nombreuses sources d’erreur (Concept Lean « Just in time »).

Un exemple concret de la mise en oeuvre du principe « Construire la qualité intrinsèque » (découlant du principe « Rechercher la perfection ») peut se traduire par la technique TDD (Test driven Development) associée à l’automatisation des tests, qui constitue une approche efficace d’amélioration de la qualité au plus tôt dans le cycle de développement. Cela permet de savoir immédiatement si ce qui est produit possède le bon niveau de qualité et de corriger les défauts au plus tôt.

Nous répondons également au concept Lean « Stop the line », en corrigeant les anomalies dès qu’elles sont détectées, ce qui évite de gaspiller des ressources en poursuivant le développement de l’application sur des bases non fiables à 100%. En effet, la priorité de correction des anomalies doit être supérieure à celle d’ajouter de nouvelles fonctions au logiciel. Enfin un important concept Lean est le « Visual Management », axe largement soutenu dans les méthodes Agiles par une organisation de l’espace de travail, qui permet à toutes les parties impliquées (développeurs, testeurs, chefs de projets, représentants du métier) de visualiser instantanément l’état d’avancement du projet, et ceci en termes simples. Grâce aux méthodes Agiles, les développeurs sont en mesure de générer quotidiennement une version compilée de l’application en cours de développement, afin de détecter au plus tôt les anomalies potentielles. Le résultat de la compilation est visible (par exemple par l’allumage d’une lampe, un avertisseur sonore ou un écran coloré bien situé en fonction du résultat) et permet de réagir au plus vite. L’ensemble des informations de suivi de projet sont affichées grâce à des codes couleurs, sur un ou plusieurs tableaux à la vue de tous (nombre de fonctions testées et validées, nombres d’anomalies en cours de résolution, etc…).

L’ensemble des pratiques citées ci-dessus répondent également au premier principe « Eliminer les gaspillages » : réduire les retards (itérations courtes), se concentrer sur les défauts (TDD), mieux comprendre les exigences (TDR, Test Driven Requirement), etc…

L’esprit Lean souffle sur les méthodes Agile car un des principes des méthodes Agiles est de se focaliser sur le produit plutôt que sur la documentation.

Agile, Lean et le développement Lean de produit

Le développement Lean de produits

Lean Product Development (LPD) : le Développement Lean de Produits tire partie de cette connaissance et ne gaspille pas le fruit des efforts produits en oubliant ce qui a été appris.
Les deux piliers et les 14 principes sont au coeur de la pensée Lean. Cependant, il y a d’autres principes et pratiques – pour apprendre mieux et plus vite que la concurrence – qui sont spécifiques au développement Lean de produits. Les gens de Toyota exécutent très bien deux processus clés, (1) le développement de produits et (2) la production. Les chercheurs de l’Université du Michigan ont étudié et comparé pendant trois ans l’efficacité – en matière de développement de produits – de Toyota et des sociétés nord-américaines. Quels sont les résultats ? …
Par exemple, le délai moyen pour concevoir et fabriquer une matrice29 était de cinq mois pour les ingénieurs de Toyota et de douze mois pour la concurrence. Tout cela en raison de l’efficacité de leurs pratiques de développement, et dans le même temps ils ont réussi à maintenir le ratio [coûts de développement / ventes] le plus bas dans le monde des grandes entreprises automobiles. Comment ont-ils fait ? Sur quoi se concentre le développement Lean de produits ? Réponse : « Apprendre mieux et plus vite que la concurrence ».
Apprendre mieux et plus vite que la concurrence en se basant sur les 6 principes : valeur de l’information, apprendre à partir du feedback, réutiliser les connaissances, coût de l’information, piloter par les données, nouvelles connaissances.

Notion de cadence :

Travailler avec un rythme régulier – ou cadence – est un principe Lean, tant dans la production que le développement. Un battement de coeur régulier. Dans la production Lean, on l’appelle le takt time. Dans le développement, on l’appelle cadence. La cadence est un principe puissant dans le développement Lean de produits, nous allons donc examiner le sujet en détail… Il y a quelque chose de basique et de très humain à propos de la cadence : les gens apprécient ou souhaitent des rythmes dans leur vie et leur travail, ils apprécient ou souhaitent participer à des rituels au sein de ces rythmes. La plupart d’entre nous travaillent sur une cadence de sept jours par semaine. Il y a le rituel hebdomadaire de la réunion du mardi. Et ainsi de suite. En fait, la cadence de travail améliore simplement la prédictibilité, la planification et la coordination. À un niveau plus profond, elle reflète les rythmes sur lesquels nous vivons nos vies.
Notez que réduire le coût du retard des informations dans le développement de produit exige presque toujours de construire et tester quelque chose. On utilise le mot Takt qui veut dire battement en rythme dans la langue allemande.
Une approche populaire pour améliorer le rythme est le timeboxing, un temps de cycle du développement fixe – et généralement court – (par exemple une timebox de deux semaines). On attend des équipes qu’elles livrent ou fassent la démonstration de quelque chose à la fin de cette durée fixe, idéalement quelque chose de petit et de bien fini plutôt que grand et partiellement réalisé. La durée ne peut pas changer, mais le périmètre des travaux peut varier pour s’adapter à la taille de la timebox. Le timeboxing n’est pas la solution miracle pour tous les problèmes d’ingénierie des connaissances, mais il a des avantages :  Le timeboxing renforce le rythme.  Le développement est un travail souvent flou et sans limite (ou faiblement borné). Lorsque l’équipe sait que la timebox se termine le 15 mars, elle limite le travail flou et augmente son pouvoir de convergence. Ainsi, le timeboxing limite les changements de périmètre, limite le peaufinage inutile et augmente le pouvoir de convergence.  Le timeboxing réduit le phénomène de paralysie de l’analyse.  Supposons que vous êtes à l’université et que vous avez un devoir à remettre lundi. Quand commencez-vous ? Pour beaucoup, la réponse est : « Un peu avant lundi ». C’est ce qu’on appelle le Syndrome des étudiants et le timeboxing est un contrepoids.  Si les équipes doivent fournir quelque chose de bien fait dans exactement deux semaines, les gaspillages et l’inefficacité des méthodes actuelles de travail deviennent douloureusement évidents. Le timeboxing crée un changement, une force pour s’améliorer, l’effet du « lac et des rochers ».  Le timeboxing simplifie la planification.  Les humains sont probablement plus sensibles aux variations de temps qu’aux variations de périmètre : on se souvient beaucoup plus de « C’est trop tard » que de « Il y a moins que ce que j’avais demandé ». Le timeboxing réduit l’érosion de la confiance quand les gens disent encore et toujours : « … peut-être qu’avec encore une semaine de plus, tout sera fait ».

Réutiliser les informations ou la connaissance :

En plus de l’évolution à long terme vers une culture de mentorat par les ingénieursexperts et les managers-formateurs pour réutiliser l’information, un outil simple de partage de l’information peut vous aider. Lors de nos missions de coaching, nous avons vu un modèle ressortir qui est que l’outil le plus réussi ou créant le plus de fidèles est le wiki. Un modèle hypertexte centré simplicité et « Web 2.0 » semble l’emporter sur d’anciens outils centrés sur les documents.

Bureau de l’équipe et management visuel :

Le Développement Lean de Produits incite à être dans un seul bureau (ou une « grande salle », assez grande pour une équipe), sans murs ou cloisons intérieures, là où une équipe pluridisciplinaire travaille et se voit, et où l’ingénieur en chef – qui a l’esprit d’entreprise – s’assoit. Les murs sont couverts d’affiches de grande taille donnant des informations sur les activités du projet, pour renforcer le côté management visuel. Ce concept de bureau d’équipe est en contraste avec les personnes qui travaillent dans des bureaux séparés avec des cloisons entre les membres de l’équipe, donc des barrières à la communication.

Apprentissage de plus grande valeur et à moindre coût :

Les nouvelles connaissances ou informations ne sont pas toutes de grandes valeurs ; l’idéal est de créer de nouvelles informations économiquement utiles. C’est difficile parce que c’est un processus de découverte, vous gagnez parfois, vous perdez parfois. Une stratégie Lean globale, basée sur une idée simple de la théorie de l’information, est d’augmenter la valeur des informations créées et de diminuer le coût de création des connaissances.
Plusieurs idées peuvent aider. Par exemple :  Se concentrer sur les choses incertaines. Choisir d’implémenter et de tester des choses peu claires ou risquées très tôt. La valeur du feedback est élevée, précisément parce que les résultats sont moins prévisibles, les choses prévisibles nous donnant peu de renseignements.  Se concentrer sur les tests et les feedbacks au plus tôt. Les informations ont un réel coût du retard, qui est l’une des raisons pour lesquelles mener des tests uniquement à la fin d’un long cycle séquentiel – motivés par l’illusion de l’optimisation locale consistant à croire que les coûts des tests seront plus faibles – est presque toujours maladroit. Cela peut être très coûteux de découvrir lors de tests de performance, après 18 mois de développement, que la décision clé de l’architecture a été imparfaitement mise en oeuvre. En matière de développement Lean, des cycles courts avec des boucles de feedback au plus tôt sont essentielles ; en mettant en oeuvre très tôt les choses les moins prévisibles et dans des cycles courts incluant les tests, le coût du retard est réduit.
En fait, on peut globalement considérer que ces méthodes réussissent en abaissant le coût du changement en jouant sur l’agilité ou la flexibilité. Ce qui inclut de réduire le coût de l’apprentissage. Par exemple :  Concentrez-vous sur des tests automatisés à grande échelle : afin d’en apprendre davantage sur les anomalies et les comportements. Le coût de réexécution des tests automatisés est généralement insignifiant en comparaison du premier feedback de valeur.  Concentrez-vous sur une intégration continue ou tout au moins à intervalles fréquents : afin d’en apprendre davantage sur les anomalies et manque de synchronisation. De plus, en intégrant souvent par petits lots, les équipes feront baisser la moyenne des coûts de fonctionnement grâce à l’effet « lac et rochers ».  Concentrez-vous sur le mentorat par des experts et la diffusion des connaissances : afin de réduire le coût de la redécouverte.

Un ingénieur en chef qui a l’esprit d’entreprise et qui maîtrise le métier :

Il y a deux domaines principaux dans la création de produits : marketing et technique. Dans la plupart des organisations que nous visitons, le leadership sur ces domaines est divisé. Par exemple, un groupe produit est responsable des objectifs métiers et de la sélection des fonctionnalités, ses membres ne sont pas des ingénieurs-experts. Toyota fait les choses différemment. La société associe le leadership technique et marketing en la personne d’un ingénieur en chef qui a l’esprit d’entreprise, qui a une « véritable excellence technique », qui est aussi à l’écoute et responsable de la réussite commerciale du nouveau produit, et qui comprend le marché.

Ingénierie simultanée :

L’ingénierie simultanée est aussi appelée conception simultanée, et est différente. Par exemple, chez Toyota, plutôt que d’avoir un ingénieur ou une équipe créant un système de refroidissement, plusieurs solutions pourront être explorées en parallèle par différentes équipes et ainsi de suite pour d’autres composants. Toutes ces alternatives sont explorées et combinées, progressivement filtrées dans des cycles, pour converger vers une solution qui était au départ un grand ensemble de choix, puis un ensemble plus petit, et ainsi de suite. Les équipes apprennent plus et mieux que la concurrence en augmentant le nombre de choix et en les combinant. Un pas dans cette direction est d’explorer au moins deux alternatives pour éviter de découvrir des éléments de conception sans valeur au cours des ateliers de conception. Par exemple, plutôt que de tous se rassembler autour d’un mur de tableaux blancs et élaborer la conception comme une seule équipe, divisez-vous en deux groupes et travaillez sur deux tableaux blancs géants aux extrémités opposées du bureau de l’équipe. Toutes les 30 minutes, visitez les murs de conception des uns et des autres pour « montrer et raconter », collectez des idées.

Les leçons de production Lean peuvent-elles aider le développement ?

Le développement de nouveaux produits (NPD) ou la recherche et développement n’est pas une production (fabrication) prévisible répétitive, et l’hypothèse selon laquelle ces activités seraient similaires est une des causes de la mauvaise utilisation des pratiques d’ « économies d’échelle » dans la fabrication au début des années 1900 ; par exemple, le développement séquentiel et les transferts par lots tels que les spécifications. Pourtant, certains des principes et des idées appliquées dans la production Lean – y compris les cycles courts, les lots de petite taille, arrêtez et réparez, le management visuel et la théorie des files d’attente – sont appliquées avec succès dans le développement Lean des produits. Pourquoi ? La production Lean moderne est différente, les lots de petite taille, les files d’attente et les temps de cycle reflètent en partie la théorie des files d’attente (parmi d’autres sources de connaissance), une discipline qui fut créée pour étudier le comportement variable des réseaux et qui s’apparente beaucoup plus au développement de produits qu’à la fabrication traditionnelle. L’ironie dans certaines organisations, c’est que les ingénieurs de fabrication ont révolutionné et adopté la production Lean, en s’éloignant des « économies d’échelle » pour aller vers un mode flux, plus de flexibilité avec des lots de petite taille et sans gaspillage. Mais ces leçons, qui s’adaptent bien au développement de nouveaux produits, demeurent inutilisées par le management qui continue à appliquer des pratiques fondées par d’anciennes logiques d’économies d’échelle dans la fabrication.
Ceci étant dit, une mise en garde quand même : le nouveau développement de produits n’est pas de la fabrication, et les analogies entre ces deux domaines sont fragiles. Contrairement à la production, le nouveau développement de produits est (et doit) être rempli de découvertes, de changement et d’incertitude. Une certaine variabilité est à la fois normale et souhaitable dans le développement de nouveaux produits ; sinon, rien de nouveau n’est réalisé. Par conséquent, la pensée Lean inclut des pratiques uniques pour le développement de nouveaux produits.

La partie du travail la plus intéressante dans le développement de produits est l’approche centrée valeur.

Les piliers de la maison Lean :

La maison Lean a 2 piliers :

– le respect des personnes

– l’amélioration continue

Pilier n° 1 : le respect des personnes

Le respect des personnes peut paraître flou, mais représente en fait des actions bien concrètes et une véritable culture chez Toyota. Ces actions reflètent grandement un respect et une sensibilité à la morale, n’entraînant pas les personnes à produire du gaspillage, un vrai travail d’équipe, guidant le développement de personnes compétentes, humanisant le travail et l’environnement, un environnement propre et sécurisé, en interne et en externe de Toyota, et une intégrité physique parmi les membres du management.

Pilier n°2 : l’amélioration continue

L’amélioration continue avec ses 4 idées fortes (Allez et Observez, Kaizen, L’enjeu de la perfection, Travaillez en mode flux en s’appuyant sur les 14 principes)

Idée n°1 – « Allez et Observez » :

« Allez et Observez » n’est pas un principe courant dans nos modes de management. Ce principe est décrit comme critique et fondamental. Dans le livret interne Toyota Way 2001, il est noté comme le premier facteur de succès de l’amélioration continue. Il est mis en avant à plusieurs reprises dans les déclarations des managers, dans la culture et les habitudes Toyota, dans la formation à la Méthode Toyota, et dans la recherche faite par les analystes japonais sur la pensée Lean.

Cela étant dit, il reste absent de quelques descriptions dérivées du Lean et malheureusement, certains ne sont pas conscients de son rôle vital. Dans la culture de la pensée Lean, toutes les personnes, spécialement les managers, même les plus seniors, ne doivent pas passer leur temps dans des bureaux séparés ou en réunion, ne recevant l’information qu’au travers de rapports, d’ordinateurs, d’outils de reporting et de réunions de suivi. Au lieu de cela, pour comprendre ce qui se passe et aider à s’améliorer, tout en éliminant les distorsions provenant d’informations non reçues directement, le management doit se rendre fréquemment là où le travail se fait réellement, pour voir et comprendre de lui même. Ce « lieu de travail véritable » (« Gemba ») ne signifie pas à proximité de l’immeuble où le travail s’effectue, ni d’aller voir d’autres managers. Il nécessite la présence physique sur site autant que possible. Pas assis dans la pièce d’à côté, mais « respirer le même air ». Le « travail » en Lean ne signifie pas les activités transverses ou secondaires, mais bien le travail produisant la valeur ajoutée attendue du client : ingénierie, conception d’une voiture, production des choses, fourniture de services aux clients. Un exemple du « Allez et Observez » consiste pour les managers, à régulièrement rendre visite et s’asseoir à côté des ingénieurs ou des personnes du service client pendant leur travail, avec pour objectif de comprendre leurs problèmes et découvrir des opportunités d’amélioration. Ce qui ressemble beaucoup à une pratique qui s’est malheureusement perdue chez certaines entreprises : « le management en mouvement autour des gens ».
« Ne regardez pas avec vos yeux, regardez avec vos jambes… les gens qui regardent uniquement les chiffres sont les pires. » (T. Ohno)
Le terme japonais pour « Allez et Observez », « genchi genbutsu », a également été largement répandu et expliqué comme consistant à résoudre les problèmes à la source plutôt qu’en restant derrière son bureau. « Allez et Observez » n’implique pas seulement de marcher jusqu’à la source du problème pour observer les faits réels et prendre une décision pertinente basée sur ces faits ; cela signifie également qu’une fois que vous êtes sur place, vous devez trouver un point d’accord sur les objectifs et les expérimentations à mener. Cette implication exigée par la pratique « Allez et Observez » concerne les gens – plus particulièrement les managers – qui doivent passer beaucoup de temps à l’endroit même où se crée la valeur, construire des relations de confiance avec les gens sur place et les aider à résoudre les problèmes.

Idée n°2 – Kaizen :

Améliorer les améliorations, sans cesse. Le « Kaizen » est souvent simplement traduit par « amélioration continue », cela prête à confusion avec le concept plus large, pilier du Lean, d’ « amélioration continue » et il n’en représente qu’une partie. Nous nous en tiendrons donc au terme japonais. Le « Kaizen » est à la fois une mentalité et une pratique. En tant que mentalité, cela suggère « Mon travail est de faire mon travail, et d’améliorer mon travail » et « de continuellement me soucier de l’améliorer ».

Plus concrètement, le « Kaizen » implique de pratiquer en 3 étapes :

– Etape 1 : choisir et pratiquer des techniques que l’équipe a décidé d’essayer, jusqu’à ce qu’elles soient bien comprises, c’est-à-dire, qu’elles deviennent un standard de travail

– Etape  2 : expérimenter jusqu’à trouver une meilleur solution

– Etape 3 : répéter sans fin

Idée n°3 – L’enjeu de la perfection

Lors d’une visite chez Toyota, un ingénieur à la retraite à été invité à dîner à Nagoya. Après plusieurs tournées de saké, il lui a été demandé : « Qu’est-ce qui vous manque depuis que vous ne travaillez plus chez Toyota ? ». Il a répondu : « Le fait de ne plus discuter de la perfection avec les autres ». Nous avons parfois visité des organisations pour discuter de l’adoption du Lean et chaque fois quelqu’un contestait la démarche en opposant généralement l’argument : « Nous gagnons beaucoup d’argent et nous avons mis en place nos processus. Pourquoi devrions-nous changer ? ». Nous ne pensons pas que vous entendrez cette question chez Toyota. Ils sont loin d’être parfaits et nous ne suggérons pas de simplement les copier, mais leur culture est d’avoir un état d’esprit « Kaizen », d’avoir des niveaux élevés d’exigence et de se remettre en question eux-mêmes, les membres de l’équipe ainsi que les partenaires sur leurs niveaux de compétence, de maîtrise, de réduction des gaspillages et de voir au-delà du statu quo. C’est puissant.

Idée n°4 – Travailler en mode flux

La notion de flux suggère de générer un flux continuel de valeur vers le client. Contreexemple : une demande client attend dans une file d’attente d’être approuvée, analysée, implémentée, remaniée ou testée. Ce n’est pas du flux. Au contraire, si de la valeur est créée – en termes de produits, logiciels, informations, décisions, services – elle doit immédiatement s’écouler vers le client. C’est évidemment en rapport avec la métaphore du passage de témoin et avec l’objectif de réduire le délai du « concept au revenu financier ». Le flux représente un enjeu de perfection ; zéro gaspillage dans le système et un flux continuel de livraison de valeur sont de gros défis, que vous n’atteindrez probablement jamais. Le voyage consiste généralement à passer progressivement vers le mode flux. Dans le schéma de la « maison » Lean (Figure 1.1), la notion de flux est incluse dans les 14 principes et les éléments clés de l’amélioration continue. Pourquoi ? Parce que pour passer progressivement vers le mode flux, il est nécessaire de réduire la taille des lots, le temps de cycle, les retards, le WIP et d’autres gaspillages. Et cela a pour effet bénéfique secondaire de révéler plus de points faibles et de gaspillages, de fournir de nouvelles opportunités pour l’amélioration continue. C’est un sujet important mais subtil, détaillé dans le paragraphe suivant. Passer progressivement en mode flux est lié à la théorie des files d’attente, les flux tirés, etc. En comprenant cela, les gens peuvent progressivement passer le système en mode flux avec de plus petits lots de travaux, de plus petites files d’attente et avec la réduction de la variabilité.
Pourquoi travailler avec de petits lots de travaux et avec de nombreux cycles courts ? Estce que cela n’augmente pas vos coûts en raison des coûts de transaction induits par chaque cycle ? Les gens qui posent cette question n’apprécieront peut-être pas les avantages liés à de petits lots de travaux dans des cycles courts :  La réduction globale du temps de cycle de la release qui peut être obtenue en supprimant les files d’attente et en appliquant la théorie des files d’attente pour que la plupart des cycles soient plus courts.  L’élimination des retards de lots, où une partie de la solution est inutilement retenue parce qu’elle s’écoule à travers le système en étant rattachée à un grand lot d’autres solutions. Éliminer cette situation offre un autre degré de liberté pour l’entreprise pour déployer un produit plus petit plus tôt avec les solutions les plus prioritaires.  Pour finir et ce n’est pas le moindre, il y a des avantages indirects dus à l’effet « lac et rochers » décrit ci-après.
Une métaphore célèbre dans la formation au Lean : le lac et les rochers. La profondeur de l’eau peut représenter le niveau des stocks, la taille des lots ou le temps de cycle. Lorsque le niveau de l’eau est élevé (grand lot, gros stocks ou temps de cycle long), de nombreux rochers sont cachés. Ces rochers représentent des faiblesses. Par exemple, considérons un cycle séquentiel de livraison de dix-huit mois avec un transfert par lots massifs ; l’inefficacité des tests et de l’intégration, la médiocrité de la collaboration sont cachées sous la surface par un cycle et une taille de lots aussi importants. Mais si nous travaillons avec ce groupe et que nous lui demandons : « S’il vous plaît, livrez un petit ensemble de solutions toutes les deux semaines », alors soudain, toutes les pratiques inefficaces deviennent douloureusement évidentes. Dit autrement, le coût de transaction (coût de fonctionnement) de l’ancien cycle devient inacceptable. Cette douleur devient alors une véritable force pour s’améliorer, parce que les gens ne supporteront pas de revivre cette situation sur chaque cycle court, et en effet il sera simplement impossible d’atteindre les objectifs du cycle avec les pratiques anciennes et inefficaces. Cette dynamique a été au centre de l’approche d’amélioration continue chez Toyota.
Astuce : tous les « rochers » ne sont pas gros ou immédiatement visibles. Le voyage Lean doit commencer avec les plus gros rochers qui sont le plus douloureusement évidents mais aussi déplaçables, et s’attaquer au fur et à mesure aux plus petits obstacles.

Agile, Lean et notion de flux

Lean utilise des systèmes à flux tirés qui fonctionnent en 7 étapes :

– Tirez plutôt que poussez

– Exposez les problèmes

– Décidez le plus tard possible

– Éviter la fausse dichotomie

– Arrêtez et réparez

– Management visuel simple radiateurs d’information, kanban, andon et travail autogéré

– Management visuel pour les files d’attente dans l’ingénierie des connaissances

Etape n°1 – Tirez plutôt que poussez

Considérez un processus de fabrication et de stockage d’ordinateurs portables. Dans un pur système à flux tirés, aucun ordinateur portable n’est construit ou stocké tant qu’il n’y a pas eu une commande du client. Le zéro stock est un objectif, et le travail se fait uniquement en réponse à un signal « tiré » de la part du client. C’est la signification principale du flux tiré : une réponse toute faite à un signal du « client », sinon on se repose ou on s’améliore. Des exemples de systèmes à flux tirés ? Imprimez-juste une commande de vingt livres ou préparez juste un plat au restaurant. Mais un système à flux tirés va plus loin que cela, le « client » n’est pas uniquement un client final. Au contraire, dans un processus multi-étapes avec une équipe amont qui réalise un travail partiel avant une équipe avale, l’équipe avale est le client de l’équipe amont. Dans un pur système à flux tirés, l’équipe amont ne crée rien à moins d’être tiré par une demande avale.
D’autre part, dans un système à flux poussés, on construit et on stocke spéculativement des ordinateurs portables en espérant des commandes, puis on tente de les pousser à la clientèle. Dans un processus multi-étapes, les équipes amonts créent un stock de travaux partiellement réalisés à destination des équipes avales. N’importe quel stock spéculatif – pizzas, grands plannings détaillés, livres, conception de nombreuses fonctionnalités dont la valeur métier est incertaine – est lié à des systèmes à flux poussés. Les stratégies de gestion des ressources qui se concentrent sur l’utilisation intensive des employés – c’est-à-dire qui observent les coureurs plutôt que d’observer le témoin – créent un environnement dans lequel les gens vont créer un grand stock de choses (documents d’analyse, conceptions, …) selon un modèle de système à flux poussés.
Le flux tiré est lié à un système Juste-à-Temps – le JIT met en oeuvre le flux tiré. Dans les systèmes à flux tirés pour le développement, un faible stock voire un stock nul signifie moins de stock de spécifications détaillées, plannings, conceptions non vérifiées, et ainsi de suite.

Etape n°2 – Exposez les problèmes

Si vous créez une seule chose en réponse à une demande tirée par un « client » (dans ce contexte, votre client est n’importe qui en aval) et que ce client la consomme rapidement, tout problème lié à cette chose – créé soit par accident soit par la conception – est rapidement découvert. Cela peut conduire à de nouvelles améliorations systémiques si les gens ont l’esprit « arrêtez et réparez ». D’autre part, dans les systèmes à flux poussés, les problèmes sont cachés dans un stock non consommé (de documents, …). Par exemple, pousser un grand lot de décisions de conception va retarder
la découverte de malentendus ou de problèmes, parce que c’est trop en avance par rapport au moment de leurs implémentations et de leurs validations par un client.

Etape n°3 – Décidez le plus tard possible

Dans les systèmes à flux tirés, vous ne prenez pas de décisions trop tôt, bien au contraire, vous « décidez le plus tard possible » et « vous vous engagez au dernier moment responsable ». De cette manière, vous disposez du maximum d’informations pour prendre une décision éclairée. Vous ne gaspillez pas vos ressources en créant des stocks inutiles ou en prenant des décisions trop tôt qui vont – ou tout au moins devraient – être remises en cause lorsque de nouvelles choses vont émerger.
Des lots de petite taille peuvent conduire à une amélioration radicale. Donc, à plusieurs égards, les systèmes à flux tirés encouragent le passage à un mode flux.

Etape n°4 – Éviter la fausse dichotomie

Affirmer catégoriquement que le flux tiré est bon et que le flux poussé est mauvais serait une fausse dichotomie. Habituellement, en raison de contraintes très difficiles (par exemple, l’absence de rapidité du transport), le stock et le flux poussé peuvent se révéler utiles, en fait un besoin temporaire de gaspillages. Les concessionnaires Toyota (en dehors du Japon) détiennent des stocks de véhicules parce que les clients étrangers veulent voir, acheter et repartir avec une voiture immédiatement.

Etape n°5 – Arrêtez et réparez

Les employés de Toyota sont coachés par des managers-formateurs pour apprendre à marquer une pause lorsque des anomalies ou des problèmes surgissent. Plutôt que de se contenter de trouver une solution miracle (ou pas de solution du tout), une équipe animera un événement kaizen pour déterminer les causes racines et amorcer une démarche en vue d’une solution pérenne qui, idéalement, empêchera l’anomalie ou le point faible de réapparaître, donc de construire la qualité intrinsèque. Par exemple, Toyota est célèbre pour sa pratique « arrêtez la ligne de production » dans laquelle n’importe qui peut tirer un cordon quand il voit une anomalie et arrêter tous les travaux en cours sur la ligne de production. C’est la première étape dans une démarche systématique pour construire la qualité intrinsèque. Un autre exemple : Toyota encourage la fabrication et l’usage d’appareils conviviaux qui détectent eux-mêmes automatiquement une défaillance, provoquent un arrêt automatique et alertent les gens sur le problème. Ceci fut inspiré par Sakichi Toyoda qui fit d’abord fortune en concevant un métier à tisser qui détectait automatiquement une défaillance et s’arrêtait. C’est la pratique Lean du jidoka.

Etape n°6 – Management visuel simple radiateurs d’information, kanban, andon et travail autogéré

Les radiateurs d’information : Toyota insiste sur l’emploi d’outils visuels simples et GROS pour signaler les problèmes, pour communiquer et coordonner un système à flux tiré. Il y a de grands écrans lumineux sur les murs et de grandes cartes avec un code couleur que les gens peuvent toucher et déplacer, et ainsi de suite. Les thèmes clés sont faciles à voir de loin, des signaux concrets (tels que les cartes), la couleur et la simplicité. Ce qui est à l’opposé d’afficher de nombreux éléments d’information de petites tailles ou très détaillés sur de petits écrans d’ordinateur basés sur des logiciels ; cependant, un écran d’ordinateur simplement rempli avec un gros pâté de couleur rouge pour indiquer un build cassé reste dans l’esprit du management visuel. Ces radiateurs d’information du management visuel sont applicables au développement de produits, aux prestations de service, ou tout autre domaine qui souhaite rendre l’information facilement accessible.

Kanban : un « kanban » (kan – signal visuel, ban – carte ou tableau) est utilisé pour signaler un événement tiré (une demande de réapprovisionnement) dans un système à flux tirés. L’exemple classique est un magasin avec quelque chose à vendre sur une étagère, par exemple une tarte. Derrière la tarte sur l’étagère, il y a une carte orange étiquetée « une tarte », le « kanban » (carte) de retrait. Lorsque la tarte est finalement retirée de l’étagère par un client, le « kanban » de retrait est dévoilé et apporté à la boulangerie pour obtenir une autre tarte et remplir à nouveau l’étagère. Ceci est possible car il y a une tarte finie en stock dans la boulangerie et en attente de ce type d’événement. C’est également à ce moment qu’un « kanban » de création est envoyé au boulanger pour préparer une autre tarte. Donc une unique tarte est tirée de l’étagère par le « kanban » de retrait, plutôt que de pousser plein de tartes.

Andon : un écran d’erreur (« andon ») est, chez Toyota, une aide visuelle pour signaler les anomalies.

Travail autogéré : c’est un thème que l’on retrouve dans les équipes de recherche efficaces. Notez que le management visuel encourage le travail autogéré parce que les gens peuvent facilement voir ce qui se passe et se coordonner. En outre, le travail porté par une carte « kanban » est explicite, par exemple « une tarte » ou « changer le style de la page web ».

Etape n°7 – Management visuel pour les files d’attente dans l’ingénierie des connaissances

Les files d’attente de choses matérielles sont faciles à percevoir par les gens, et à percevoir comme un problème… Mon Dieu, il y a une pile gigantesque de choses qui s’entassent là-bas ! Allons-nous générer de l’argent avec cette pile ? Y a t-il des anomalies cachées à l’intérieur ? Avons-nous besoin de la combiner avec autre chose avant de la livrer ? Avons-nous besoin de – et allons-nous faire de l’argent avec – chaque élément de cette pile ? Mais qu’en est-il des files d’attente en ingénierie des connaissances ?
Les files d’attentes invisibles sont plus difficiles à identifier. Dans de nombreux domaines basés sur l’ingénierie des connaissances (et certains autres sur les services), il y a aussi des files d’attente, mais parce qu’elles sont invisibles (comme des octets sur un disque informatique), elles ne sont pas considérées comme des files d’attente mais plutôt vivement ressenties comme des problèmes. Un homme d’affaires, qui a investi dix millions d’euros pour créer une pile gigantesque de Choses sans valeur à moitié finies, est assis sur le sol, peut la voir et ressentir la douleur et l’urgence de tout mettre en mouvement. Mais les ingénieurs de la connaissance ne le voient pas vraiment et ne ressentent donc pas la douleur de leurs files d’attente. Pourtant, elles sont bien là. Ces files d’attente de WIP gâché ou d’informations en cours de conception, des documents et des octets sur un disque. Des files d’attente invisibles. Les gens de Toyota apprennent à développer « leur vision du gaspillage ». Ils apprennent à voir les choses comme des gaspillages qu’ils n’avaient pas auparavant considérés ainsi, tels que les stocks, des files d’attente de choses sans valeur. De même, les ingénieurs de la connaissance ont besoin d’une leçon pour développer « leur vision des files d’attente » afin qu’ils puissent commencer à percevoir ce qui se passe, à développer un sentiment d’urgence concernant la réduction de la taille des files d’attente.
Des signaux concrets pour voir les files d’attente : pour développer « la vision des files d’attente » dans  n’importe quel domaine (services, ingénierie, …) ainsi qu’un sens de l’urgence pour prêter attention aux files d’attente et au WIP, mettez en place un management visuel avec des signaux concrets, tels que des cartes sur un mur. Pourquoi concret ? Enfouir ces tâches dans les ordinateurs d’aujourd’hui dessert l’objectif recherché, parce que ces files d’attente doivent être facilement et clairement visibles à tout moment, et elles doivent également être grandes. Le stockage dans les ordinateurs d’aujourd’hui (par exemple, dans les feuilles d’un tableur) les rend petites, et pas toujours visibles. Et les humains – dont l’instinct pour travailler avec des choses concrètes a évolué pendant de très longues périodes – ont besoin de voir et ressentir de façon tangible les files d’attente.
Les signaux concrets sont un aspect essentiel du management visuel Lean qui n’est pas toujours apprécié. Certaines personnes créent des logiciels pour le « management visuel » et passent complètement à côté du besoin viscéral et dynamique d’utiliser des signaux concrets. Un jour, ces affichages feront la taille du mur et on pourra déplacer des objets informatiques en faisant des gestes, afin de stimuler cette réponse viscérale ; la technologie sera donc à ce moment-là au point.
Management visuel pour voir et limiter le WIP : l’un des gaspillages Lean est le WIP ; tout comme avec les files d’attente, il est difficile de percevoir le travail en cours dans l’ingénierie des connaissances et des services parce qu’il est souvent intangible avec des artefacts cachés à l’intérieur des ordinateurs (tels que des documents). Essayez plutôt de baptiser « WIP » une partie de votre mur et placez vos items de travail sur cette surface. Les personnes ou les groupes pourront établir des règles pour limiter le WIP, telles que « pas plus de 2 items de WIP en parallèle ». Le visuel aide à maintenir les règles.

Agile, Lean et Kaizen

Le « Kaizen » est un terme japonais issu du Système Toyota, c’est à la fois une mentalité et une pratique. En tant que mentalité, cela suggère « Mon travail est de faire mon travail, et d’améliorer mon travail » et « de continuellement me soucier de l’améliorer ».

Plus concrètement, le « Kaizen » implique de pratiquer en 3 étapes :

– Etape 1 : choisir et pratiquer des techniques que l’équipe a décidé d’essayer, jusqu’à ce qu’elles soient bien comprises, c’est-à-dire, qu’elles deviennent un standard de travail

– Etape  2 : expérimenter jusqu’à trouver une meilleur solution

– Etape 3 : répéter sans fin

Etape 1 :

Choisir et pratiquer des techniques que l’équipe a décidé d’essayer, jusqu’à ce qu’elles soient bien comprises (Standard de travail). L’idée est pour un groupe de trouver, ou du moins de chercher, des pratiques de base intéressantes et d’apprendre à bien les faire. Les personnes apprennent à faire <X> de façon standardisée, avec beaucoup de pratique, d’accompagnement et une bonne formation. La première étape du « Kaizen » nécessite d’avoir de la patience durant la phase d’apprentissage et de ne pas abandonner trop vite. Les gens ont besoin d’une base solide pour s’améliorer. Dans la terminologie de Deming, ils ont besoin de comprendre qu’une cause commune ou une cause spécifique peut avoir des effets différents. Cette première étape du « Kaizen » est nécessaire pour qu’une personne ou une équipe puisse sentir avec précision le besoin d’améliorer une pratique ou de la changer tant qu’elle n’en a pas stabilisé les bases, y compris les subtilités et qu’elle ne l’a pas exécutée correctement. Avez-vous déjà vu les commentaires du style « Oh, <X> ne marche pas », du fait d’une manque de compétence, de pratique ou de formation ? Ça n’a aucun sens de se baser sur l’incompréhension pour améliorer ou rejeter une pratique.
Dans la méthode Lean, un standard de travail ne signifie pas de se conformer aux standards centralisés. La plus grosse erreur d’interprétation de la méthode Lean est de penser qu’un standard de travail doit respecter des standards définis de façon centralisée. C’est une erreur si grave du point de vue Lean, si facile à faire, que cela mérite une attention particulière. L’idée est plutôt qu’une équipe puisse avoir des éléments de base afin de comparer les effets d’un essai d’amélioration. Cette référence, ou standard, est créé par l’équipe elle-même, pas par une équipe transverse, et évolue constamment. Comme l’a dit Ohno : « J’ai dit aux gens qu’ils ne toucheraient pas leurs payes s’ils laissaient les standards actuels de travail inchangés pendant plus d’un mois.  » L’idée était de leur faire comprendre qu’ils étaient responsables de l’amélioration constante de leurs procédures de travail et par conséquent de la mise à jour de ces standards de travail.

Dans la méthode Lean, un standard de travail ne signifie pas de se conformer aux standards centralisés. La plus grosse erreur d’interprétation de la méthode Lean est de penser qu’un standard de travail doit respecter des standards définis de façon centralisée. C’est une erreur si grave du point de vue Lean, si facile à faire, que cela mérite une attention particulière. L’idée est plutôt qu’une équipe puisse avoir des éléments de base afin de comparer les effets d’un essai d’amélioration. Cette référence, ou standard, est créé par l’équipe elle-même, pas par une équipe transverse, et évolue constamment. Comme l’a dit Ohno : « Partagez au lieu d’imposez les pratiques. Je le répète, les standards de travail ou les normes de l’équipe ne doivent pas être interprétés comme une pratique déterminée à suivre « jusqu’à notification d’avis contraire » ou comme un système centralisé imposé aux personnes, c’est contraire aux idées du pilier Lean de l’amélioration continue. »

Les gens de Toyota ont mis en avant le « yokoten », c’est-à-dire la diffusion horizontale des connaissances qui peuvent ensuite évoluer à part, comme une greffe à partir d’un arbre. « Yokoten » signifie littéralement déplier ou ouvrir latéralement. Diffuser les connaissances implique une culture qui met l’accent sur le partage horizontal des connaissances, mais sans être forcé de se conformer au système centralisé11. Quelques citations de personnes de Toyota : Si vous tentez simplement de faire adhérer les gens aux standards actuels, vous ratez l’opportunité de vous améliorer. Vous ne tenez pas compte de la manière dont les choses évoluent. Il faut faire preuve de beaucoup de souplesse pour permettre la créativité tout au long du chemin… Les standards ne doivent pas être développés puis communiqués du siège vers toutes les usines. Des standards rigides ne feront que tuer le « kaizen »… Vous devez tout le temps faire « yokoten », partagez les bonnes pratiques… Nous devons laisser les employés des usines décider par eux-mêmes comment résoudre les problèmes et combler les lacunes. Quelqu’un du siège ne peut pas dire aux gens qu’ils doivent faire X, Y, Z parce que c’est contraire à la philosophie de résolution des problèmes chez Toyota. Nous recommandons les Communautés de pratiques, elles ont été créées pour diffuser horizontalement les connaissances.

Étapes 2 et 3 :

Faire des petits ajustements incessants et progressifs. Le « Kaizen » est une activité permanente menée par tous les gens, y compris les managers, pour changer et améliorer les pratiques sans relâche et progressivement, généralement par de petites expérimentations, même si le « Kaizen » à grande échelle peut rester une option. Presqu’aucune pratique, aucun processus ou aucune politique existante n’est sacrée, tout peut changer. « N’hésitez pas à tout remettre en cause », selon les propres mots de Convis, président de Toyota. En outre, une culture « Kaizen » ne consiste pas uniquement à faire lancer par des experts en processus de gros projets d’amélioration. C’est plutôt chaque équipe qui le fait régulièrement par elle-même. Apprenez l’amélioration des processus en le faisant. Le « Kaizen » implique, par d’incessantes répétitions et du coaching, que les gens apprennent par eux-mêmes à rendre visibles les problèmes, à en analyser les causes racines, et à améliorer les choses par l’expérimentation. « Rater » une expérimentation n’est pas un échec. Le seul échec en « Kaizen » est de ne pas continuellement expérimenter. Kaneyoshi Kusunoki, un autre étudiant de Taiichi Ohno, et vice président chez Toyota, dit à propos du « Kaizen » et du management : « Une caractéristique intrinsèque de la culture d’Entreprise Toyota c’est que les managers ne vont pas vous gronder d’avoir pris des initiatives, saisi une opportunité et de vous être trompé. » Au contraire, ils vous en voudront de ne pas avoir essayé quelque chose de nouveau, de n’avoir pas saisi d’opportunités. Les leaders ne sont pas des juges. Ils sont là pour encourager les gens. C’est ce que j’ai toujours essayé de faire. Essayer et perdre, c’est le principe ! Dans « Kaizen » de Masaaki Imai, celui-ci partage le point de vue suivant : L’essence du Kaizen est pure et simple : Kaizen signifie amélioration. Mais au-delà, Kaizen signifie amélioration en cours impliquant tout le monde, managers et travailleurs. La philosophie du Kaizen prend en compte le fait que notre style de vie, professionnelle, sociale, ou familiale, freine la possibilité de constamment s’améliorer. Le « Kaizen » reflète le cycle d’amélioration de Shewhart Plan-Do-Check-Act (PDCA), aussi connu sous le nom de roue de Deming. En fait, beaucoup de gens chez Toyota connaissent parfaitement le cycle PDCA et décrivent souvent leur façon de faire en un cycle « PDCA de Deming sans fin ».

Le « Kaizen » s’opère le plus souvent au travers d’événements kaizen ; à intervalles fréquents et réguliers, quotidiennement ou hebdomadairement. Globalement, un événement kaizen couvre les étapes (1) d’analyse de quelques situations courantes jusqu’à leur bonne compréhension, et (2) de conception des moyens d’amélioration. Durant l’analyse et la conception, l’accent doit être mis sur des activités plutôt que parler autour d’une table. Utiliser des activités créatives sur un tableau blanc, un paper board , …. Attention aux événements kaizen inutiles, où les gens font du bruit mais passent leur temps à analyser sans prendre de décisions et d’engagements. N’essayez pas d’en faire trop, une bonne amélioration vaut mieux que plusieurs inefficaces.

Les 5 Pourquoi :

Les Cinq Pourquoi (généralement écrit Les 5 Pourquoi) est un outil simple et largement utilisé dans le « Kaizen ». Il contribue à développer les compétences en résolution de problèmes et en analyse des causes racines. En réponse à un problème ou une anomalie, une équipe se pose au minimum cinq fois la question « pourquoi ? . Ces questions peuvent avoir plusieurs réponses liées entre elles, si bien que certaines équipes en viennent à créer un « graphe des 5 pourquoi» pour visualiser les différentes branches de réponse, ou avec une approche plus structurée avec un diagramme en arêtes de poisson (Ishikawa). Le point important des 5 Pourquoi n’est pas la technique ou le chiffre 5, mais le fait que cela fasse partie intégrante de la culture omniprésente chez Toyota et de la démarche « Arrêtez et Réparez » → Résolution de problèmes → Analyse des causes racines. Les gens sont formés pour apprendre à résoudre les problèmes en profondeur ; pas à vivre avec les problèmes, mais à y réfléchir profondément. Il y a également un lien entre « Allez et Observez » et les « 5 Pourquoi » : il est facile pour les gens de proposer de mauvaises ou piètres réponses sauf s’ils se déplacent pour observer les faits sur le lieu réel du problème.

Valeur et gaspillage :

Que peut-on améliorer durant « Kaizen » ?

Dans la pensée Lean, la réponse nécessite une compréhension des notions de valeur et de gaspillage.

Valeur : les moments d’action ou de pensées que vous passez à créer le produit que le client est prêt à payer.

En d’autres termes, la valeur est définie dans les yeux du client externe.

Imaginez qu’un client observe le travail dans votre bureau. À quel moment serait-il prêt à mettre la main dans sa poche, en tirer de l’argent et vous le donner ?
Gaspillage : tous les autres moments ou actions qui n’ajoutent pas de valeur mais qui consomment des ressources. Les gaspillages proviennent de travailleurs surchargés, des goulots d’étranglement, des temps d’attente, des transferts, des voeux pieux, de la dispersion de l’information… entre autres. Un axe d’analyse dans la pensée Lean est d’estimer l’ensemble des moments de gaspillage et de valeurs en allant « de l’idée au flux financier ». En partant de cette ligne de temps, on peut totaliser le temps pris par les activités qui créent de la valeur et le Lead time (de l’idée au flux financier), puis calculer : Ratio valeur = temps total pris par les activités qui créent de la valeur / lead time total Nous avons fait de nombreuses lignes de temps avec des groupes de développement de produits et nous n’avons pas vu de ratio valeur dans ces organisations qui soit supérieur à 7%. En d’autres termes, 93% ou plus du temps de développement est du gaspillage.

S’améliorer en éliminant les gaspillages. Après avoir défini la valeur et le gaspillage, nous arrivons à une différence notable dans l’amélioration Lean. D’autres systèmes se concentrent sur le raffinage des activités existantes générant de la valeur ; par exemple, améliorer les compétences en matière de conception. Un objectif louable sans aucun doute. Cependant, puisqu’il y a généralement peu de moments de valeur ajoutée dans la ligne de temps, peut-être 5%, ces améliorations n’apportent pas grand-chose. Mais avec une montagne de gaspillage dans le processus, il y a de grandes opportunités pour améliorer le ratio valeur en éliminant les gaspillages. Par exemple, un gaspillage courant dans le développement de produits est la surproduction, la création de solutions ou de fonctionnalités dont le client ne veut pas vraiment. Cela n’a pas beaucoup de sens de se concentrer sur la mesure et l’amélioration de 2% de l’efficacité des pratiques d’ingénierie s’il y a une montagne de gaspillages liés à des fonctionnalités non utilisées en raison de mauvaises décisions prises dans la gestion du produit. Un autre exemple de gaspillage est le temps d’attente ou le retard, les clients ne payent pas pour cela. Avez-vous déjà vu le gaspillage lié à l’attente…

Avez-vous déjà vu le gaspillage généré lorsque vous attendez…  des précisions  une validation  qu’une équipe finisse sa partie.

Catégories d’actions ne produisant pas de valeur ajoutée : chez Toyota, on forme les gens à améliorer « leur vision pour repérer les gaspillages ». Pour les aider à apprendre, des listes d’actions ne produisant pas de valeur ajoutée (NVA) ont été établies. Il n’y a pas de liste correcte, le plus important ce ne sont pas les catégories, c’est d’apprendre à voir et à éliminer les gaspillages du point de vue du client. Les catégories suivantes d’actions NVA dans le développement produit sont tirées des livres Toyota Way, Implementing Lean Software Development et Lean Product and Process Development.

Actions NVA (Non Value Added), sans réelle valeur ajoutée :

– Surproduction de solutions ou de fonctionnalités, ou d’éléments pour l’étape suivante ; duplication, fonctionnalités ou services dont le client ne veut pas réellement, gros documents, conceptions détaillées plus que nécessaires pour une mise en oeuvre rapide, duplication des données.

– Attente, retard.
… pour obtenir des précisions, des documents, des validations, des composants, des tâches terminées par d’autres groupes.

– Transfert, transport, déplacement.
Donner la spécification d’un analyste à un ingénieur.
Donner un composant à un autre groupe pour les tests.

– Traitements supplémentaires (ainsi que les processus supplémentaires), réapprentissage, réinvention.
Conformité imposée à des check-lists centralisées de tâches « qualité » pour contrôler la bonne application des processus.
Refaire quelque chose qui est déjà fait.

– Travail partiellement fait, travail en cours (WIP, Work In Process) ou conception en cours (DIP, Design In Process).
Conceptions documentées mais non implémentées.
Choses construites mais pas intégrées ou testées.

– Changement de tâches, mouvement entre les tâches ; multitâches basées sur les interruptions.
Interruption.
Multitâches sur 3 projets en même temps.
Affectation partielle d’une personne sur plusieurs projets.

– Anomalies, tests et corrections après la création du produit.
Les tests et les corrections à la fin pour trouver et supprimer les anomalies ne constituent pas des actions produisant de la valeur ajoutée ; cela peut être un gaspillage temporairement nécessaire.

– Sous-estimation du potentiel des gens, de la diversité de leurs compétences, de leur perspicacité, de leur créativité et de leur force de proposition.
Les gens ont-ils uniquement une seule spécialité dans le cadre de leur intitulé de poste ?
Les gens ont-ils l’opportunité de changer ce qu’ils considèrent comme étant du gaspillage ?

– Perte ou dispersion des connaissances et de l’information.
Les informations sont diffusées au travers de plusieurs documents séparés.
Barrières de communication telles que des murs entre les gens ou qui sont carrément dans des lieux distincts. Voeux pieux (par exemple, que les plannings, les estimations et les spécifications soient « correctes » par nature).
« L’estimation ne peut pas augmenter ; l’estimation de l’effort est ce que nous voulons qu’elle soit, et non pas ce qui est proposé à un instant donné. »
« Nous sommes en retard, mais nous allons nous rattraper plus tard. »

S’améliorer en éliminant les NVA :

L’insistance à fournir de la valeur à travers l’élimination des gaspillages mène l’organisation à suivre le témoin plutôt que les coureurs. Notez que la stratégie d’amélioration consiste à enlever des choses plutôt qu’à en ajouter. Autrement dit, plutôt que de se dire (par exemple) : « Que pouvons-nous demander aux employés de faire en plus ? », la question est « Que pouvons-nous supprimer ou arrêter de faire ? ». Lors de nos missions de conseil, nous avons constaté qu’il s’agissait d’un véritable changement de mentalité pour les gens qui pratiquent une assurance qualité plutôt traditionnelle dans les grandes organisations et qui se concentrent sur la conformité à des check-lists et sur le fait d’ajouter des activités pour « s’améliorer ».

Le gaspillage temporairement nécessaire par rapport au pur gaspillage : on ne peut pas gagner toutes les batailles contre le gaspillage compte tenu de nos capacités et de nos contraintes actuelles. Par exemple, il est cruellement difficile, voire presque impossible de créer un produit qui n’a jamais aucune anomalie lorsqu’on commence à l’utiliser. De plus, il y a de nombreux cas où il est moins coûteux de résoudre les anomalies par des boucles de feedback avec des tests tout à la fin, en petits lots sur des cycles courts, d’autant plus que les techniques et outils de tests réduisent les coûts et le temps de cycle d’un test. Soyons clair : nous ne recommandons pas d’attendre et de tester à la fin du développement. Cependant, de nombreux cycles courts et peu coûteux avec de petits lots et des tests automatisés peuvent – mais pas toujours – constituer une solution peu onéreuse pour répondre au problème de « construction de la qualité intrinsèque ». Il est donc parfois prudent ou nécessaire, étant donné nos possibilités actuelles, de tester et corriger – une fois un petit élément créé sur un cycle très court – les gaspillages et les anomalies. Même Toyota réalise cette étape de « gaspillage », mais uniquement sur des cycles courts avec des lots de petite taille afin que les anomalies ne subsistent pas, ne se reproduisent pas ou ne s’entassent pas.
C’est pour cette raison que Toyota reconnaît deux types de gaspillage : 1. les gaspillages nécessaires temporairement… une bataille à venir ; par exemple, tester à la fin d’un cycle court 2. les purs gaspillages… qui peuvent et doivent, en principe, être éliminés dès aujourd’hui. Les stocks sont-ils toujours des gaspillages ? Une vision communément partagée par ceux qui découvrent le mode de pensée Lean est que les stocks sont uniquement du gaspillage et doivent systématiquement être éliminés. Les stocks matériels ou les WIP immatériels – comme des spécifications – impliquent des investissements sans bénéfices et des anomalies cachées. Ce n’est pas bon. Pourtant, une pratique courante dans le Lean est de créer un flux tiré, de supprimer la variabilité (l’une des sources de gaspillage) dans une étape avale du processus en insérant un petit stock d’éléments de haute qualité et de « taille égale » juste avant cette étape.

Mura, muri, muda :

3 sources de gaspillage fréquent : variabilité, surchage, actions NVA
Les termes japonais couramment utilisés sont mura (variabilité), muri (surcharge de travail) et muda (activités n’apportant pas de valeur ajoutée).
Concentrez-vous sur la variabilité, la surcharge de travail et les activités n’apportant pas de valeur ajoutée. En plus des activités qui ne génèrent pas de valeur ajoutée, la Méthode Toyota enseigne aux gens trois sources de gaspillage. Les gens de Toyota – qui observent les tentatives des entreprises extérieures pour adopter le Lean – remarquent généralement une mauvaise formation des personnes sur les gaspillages ; une mauvaise formation consistant à uniquement se concentrer sur l’élimination des activités NVA. Chez Toyota, on donne la même importance à ces trois sources de faiblesse, et en fait, la variabilité et la surcharge de travail sont considérées comme des causes racines qui génèrent souvent des activités.

En 2001, Toyota a créé un livret interne « Toyota Way » résumant les principes du Lean. En entendant le titre proposé, le président Toyoda a suggéré de le renommer en « Toyota Way 2001 ». Pourquoi ? Afin de souligner qu’il n’y a pas de processus final chez Toyota (qui étoufferait le « Kaizen »), mais plutôt, l’amélioration continue et le changement.
Les implications du « Kaizen » et d’une large diffusion latérale des connaissances font qu’il n’y a pas de processus final ou « définitif » applicable partout et qui serait communiqué à partir d’un groupe de travail centralisé. « Kaizen » inclut l’apprentissage et la maîtrise des accords de travail, mais ces principes évoluent et se propagent par un modèle de diffusion latérale des connaissances. Les gens qui pensent « définissons (ou achetons) le système, écrivons-le, puis nous nous concentrerons sur sa conformité » ne seront pas à l’aise avec la pensée Lean. Pour citer le PDG de Toyota : « Les racines de la Méthode Toyota consistent à être insatisfaits du consensus ; vous devez en permanence vous demander : « Pourquoi faisons-nous cela ? ». Dans Toyota et dans la pensée Lean, l’idée est de sans cesse répéter des cycles expérimentaux d’amélioration.

Les fondations de la maison Lean :

Commençons tout d’abord par les fondations : des managers-formateurs formés à la pensée Lean

Le management applique la pensée Lean, éduque et base toutes ses décisions sur cette philosophie pérenne.

Des interviews chez Toyota au Japon, pour mieux comprendre leur mode de management et leur système d’apprentissage nous ont appris que la plupart des employés suivent pendant plusieurs mois une formation avant de démarrer un autre travail. Pendant cette période, ils apprennent les fondations de la pensée Lean, ils apprennent à reconnaître un « gaspillage », un sujet sur lequel nous reviendrons plus tard, et ont pratiqué dans différents domaines chez Toyota.

Ils apprennent :

– à résoudre les problèmes par des exercices pratiques d’amélioration

– à comprendre comment la pensée Lean est utilisée dans différents domaines

– à s’imprégner de la mentalité « Kaizen » (amélioration continue)

– à évaluer le principe fondamental chez Toyota appelé « Allez et Observez / Gemba » .

Allez et Observez / Gemba :

« Allez et Observez » signifie que les gens, en particulier les managers, sont sensés aller voir sur le terrain de leurs propres yeux plutôt que de rester derrière leur bureau en pensant que la vérité n’est que dans les chiffres et les rapports. C’est lié à la croyance dans le « Gemba » : allez sur le terrain où sont les vrais travailleurs qui produisent la valeur.

Vous ne pouvez pas générer un kaizen (amélioration) utile en restant assis à votre bureau… Aujourd’hui, il y a beaucoup trop de gens qui ne comprennent pas ce qu’est un lieu de travail… Ils réfléchissent beaucoup, mais ils n’observent pas. Je vous encourage fermement à faire de réels efforts pour observer ce qui se passe sur le lieu de travail. « C’est là où se passent réellement les choses. »(Michikazu Tanaka)

il a été également constaté que des managers ont gravi les échelons au fil des années en transmettant les pratiques de la pensée Lean et en coachant les autres.

Lorsque Eiji Toyoda était président, il déclara à l’équipe de management : « Je veux que vous vous engagiez à former les personnes à penser par elles-mêmes ». Notez bien que ce n’était pas le même message que « laissez les personnes penser par elles-mêmes ».

La culture du management doit plutôt être que les managers doivent agir comme des formateurs permettant d’apprendre aux personnes à penser par elles-mêmes.

Les managers de Toyota sont formés à la pensée Lean, à l’amélioration continue, à l’analyse des causes racines, aux statistiques de variabilité, à l’étude des systèmes, … et coachent les autres sur ces outils.

Good Thinking, good products : la devise interne des employés de Toyota est « Bien Réfléchir pour avoir de Bons Produits ».

Comment ont-ils faits pour apprendre cette compétence du « bien réfléchir », qui est le fondement de leur succès ?

A travers une culture du coaching. On attend des managers qu’ils sachent transférer leur expertise dans leur domaine de travail (le dicton est « mon manager peut mieux faire le travail que moi »), qu’ils comprennent le mode de pensée Lean et qu’ils consacrent du temps à enseigner et coacher les autres.

C’est une philosophie pérenne :

– plusieurs personnes de l’entreprise sont formées au mode de pensée Lean via des formations et le coaching des managers-formateurs. 

– en pratique, tout le management, y compris la direction, doit avoir une solide compréhension des principes du Lean, l’avoir expérimenté pendant plusieurs années et l’avoir enseigné aux autres. 

– les managers-formateurs ont cultivé des compétences dans l’étude des systèmes, la résolution des problèmes, l’amélioration des processus et l’ont enseigné aux autres. La culture est imprégnée d’une mentalité et d’un comportement qui disent que la politique des ressources humaines chez Toyota incluait l’analyse du temps passé par le manager à former les gens.

-en bref, les managers sont moins directifs et plus formateurs aux principes de la pensée Lean, au « arrêtez et réparez » et à la mentalité kaizen. C’est de cette façon que l’ADN de Toyota s’est propagé. Atsushi Niimi, président de Toyota Amérique du Nord, dit que le plus grand défi lorsqu’on forme les managers étrangers à la méthode Toyota c’est qu’« ils veulent être managers, mais pas formateurs ».

Plus on apprend sur le Lean, plus on apprécie que les fondations portent sur le manager-formateur qui le vit et l’apprend en ayant une grande expérience du terrain. Les fondations ne sont pas les outils ou la réduction du gaspillage. Toute équipe dirigeante qui veut profiter pleinement de la pensée Lean devra faire attention à ce principe de base : ils ne pourront pas « téléphoner » à leur support pour « faire du Lean ».