ToyotaWay

Un article de Agora2ia.



Chaque année, la communauté XP organise 2 ou 3 XpDays dans différentes villes de par le monde.


Un XpDay se présente sous la forme de quelques journées consécutives, découpées en sessions d'une à 2 heures sur tous les thèmes relatifs à l'ExtremeProgramming. Le fond (technique, méthodologique, relationnel, retour d'expérience...) comme la forme (forum, atelier, présentation, débat, retours d'expérience...) sont variés.


Les 23 et 24 mars 2006, sous l'impulsion de l'association française XP-France, s'est tenue à Paris la première XP Day francophone.

La session que j'ai le plus appréciée est sans conteste celle du consultant Pascal Van Cauwenberghe concernant le ToyotaWay. Cette présentation a été l'occasion de structurer de manière différente et originale mes connaissances XP, acquises pendant les 4 ans où j'ai successivement travaillé au sein de 2 équipes « full XP ».


Je tiens à remercier Coach, Alex et Pascal lui-même, pour leurs relectures et leurs remarques.


Sommaire

Présentation

Encore quatrième mondial en 2002, Toyota est actuellement le premier constructeur automobile japonais, et le numéro deux mondial derrière General Motors.

Et l'écart continu de se réduire rapidement. Alors que le constructeur américain a subi de lourdes pertes au dernier trimestre 2005, Toyota enregistre chaque année depuis 2000 d'importants bénéfices, pour certainement devenir en 2006 le numéro un mondial.

Toyota c'est la voiture hybride Prius, une politique dynamique d’investissements en installations et en nouvelles technologies, 7,5 millions d'automobiles vendues par an, une augmentation annuelle des ventes de 10%, plus de 40% du marché japonais, une hausse de 54,8% de son bénéfice net en 2004, soit 9 milliards de dollars et la première société japonaise à atteindre le seuil de mille milliards de yens, un bénéfice consolidé de 16 milliards de dollars en 2005 pour une valorisation de 150 milliards de dollars...


Mais quel est leur modèle ?

Qu'est ce que ce modèle de production peut apporter au développement logiciel ?


Ce modèle, le ToyotaWay, est constitué de 14 principes de management regroupés en 4 groupes :

  1. Process,
  2. Personnes et partenaires,
  3. Résoudre les problèmes et apprendre,
  4. Philosophie.

Nous allons maintenant aborder un à un ces principes...


Les processus

Toyota est très orienté process comme l'indique un de ses slogans : Le bon process vous amènera au bon résultat.

C'est pour cette raison qu'une des obsessions permanente du ToyotaWay est l'élimination de toute source de gâchis, de gaspillage ou MUDA en japonais.


Flow : fluidité

Comme toute entreprise, Toyota a commencé petit. Pour que ses unités de production réduites parviennent alors à rivaliser avec la production de masse, elle a du éliminer toute source de gaspillage, de muda, tout le long de sa chaîne de production à savoir :

  • L' attente : une personne ayant besoin du travail d'une autre ne doit pas l'attendre.
  • Le transport : les personnes devant travailler ensemble sont à proximité les unes des autres.
  • Les mouvements excessifs : les pièces devant être assemblées sont proches les unes des autres et de l'assembleur.
  • Les défauts : faciliter le feedback ou retour utilisateur permettant d'identifier et de corriger les défauts. L'idée sous jacente est d'amener rapidement les problèmes à la surface.

Plus on raccourcit le temps et la distance entre l'assemblage/production (ou le développement) et la livraison au client, plus on raccourcis le délais jusqu'au paiement.


Et l'Extreme Programming

La war room (l' open space de l'équipe) et le client sur site facilitent la communication au sein de l'équipe d'une part, et entre le client et l'équipe d'autre part, permettant une meilleure fluidité.


La fluidité se retrouve également dans la durée restreinte des itérations qu'XP préconise : de l'ordre de 2 à 3 semaines.


Pull : production à la demande

Pour ce principe, Toyota s'est inspiré des supermarchés :

  1. Le client prend un article sur l'étagère,
  2. Le responsable du rayon rempli le rayon à partir des stocks,
  3. Le stock est alimenté par le fournisseur...

Cela permet de s'attaquer à un autre muda : la surproduction.


Pour cela, Toyoya utilise des KANBAN ou cartons bristol A3. Ces "jetons" ont pour objectif de limiter la taille des buffers entre les centres de travail. Par exemple, celui qui doit assembler une voiture avec 3 sièges aura 3 kanban. Il donnera alors ses kanban au responsable des sièges, qui produira exactement autant de sièges qu'il a reçu de kanban. Cet exemple indique qu'on a un buffer de 3 pièces. Dès qu'une pièce est consommée, un kanban est libéré et le producteur peut produire une nouvelle pièce.


Le renouvellement de matériel initié par la consommation est la base du principe "Just in time" et permet de supprimer un autre muda : les stocks. De petites quantités immobilisées et fréquemment renouvelées limitent le "work in process" et les inventaires.

Etre directement sensible aux variations dans la demande du client, plutôt que de compter sur des systèmes informatiques, permet de dépister un inventaire inutile.


Et l'Extreme Programming

On ne produit une fonctionnalité que si, et seulement si, le client la demande. Le kanban étant le TestRelease pour l'équipe, et la fiche bristol (où est décrite la tâche) pour le binôme.


La valeur XP « simplicité » et le principe associé « YAGNI » (You're NOT Gonna Need It) tendent vers cette notion de « production à la demande », à savoir qu'il ne faut développer que ce dont on a besoin, et uniquement ce dont on a besoin.

Le TestFirstDesign et surtout le TestDrivenDevelopment sont de très bons outils pour y parvenir : le TestUnitaire écrit en premier, avant le code applicatif, délimite le périmètre de ce que l'on a besoin. Dés que ce test passe avec succès, on s'arrête d'ajouter des fonctionnalités, on s'attaque au test suivant.


Heijunka : lissage de la production

Il faut travailler à effort régulier comme la tortue, et non pas comme le lièvre avec des pics et des creux.

Cela permettra d'éviter deux autres muda :

  1. MURI ou surcharge : les machines et personnes surchargées produisent des erreurs voire s'arrètent.
  2. MURA ou instabilité : l'alternance de marche/arrêt entraîne du gâchis.


Et l'Extreme Programming

Le Planning Game et les itérations permettent de lisser la fréquence et le contenu des livraisons. Pendant une itération on effectue toujours la même quantité de travail. En cas de tâche imprévue (pour corriger un bug bloquant en production par exemple), il faudra enlever une quantité équivalente de travail de la charge de travail prévue sur l'itération.


Jidoka : Machine à touche humaine

Il faut introduire à tous les niveaux de la chaîne de production la capacité à détecter le défaut et la possibilité de tout arrêter.

Détecter les erreurs le plus tôt possible permet de :

  1. Faciliter la correction,
  2. Limiter les impactes.

Chez Toyota chaque ouvrier se doit de détecter toute erreur et possède à portée de main un bouton d'arrêt de la chaîne de production en cas de problème.

Cela entraîne une baisse de productivité à court terme, mais une augmentation de la qualité sur le long terme, donc une augmentation de la productivité.


Mettre à disposition le "bouton rouge" n'est pas tout. Il est important de développer la culture de l'arrêt pour corriger le problème et avoir la bonne qualité la première fois. Cela va à l'encontre de certaines pratiques/politiques qui consistent à masquer tout défaut, tout problème, tout incident, considérés comme autant d'erreurs afin de produire de bons résultats. Pour valoriser cette pratique, il ne faut pas tenir pour fautif celui qui a tiré le signal d'alarme, au contraire. Il ne s'agit pas de mettre en évidence ses défaillances ou celles de la société, mais une piste d'amélioration...

En plus de cette capacité à arrêter le système, il faut que les dirigeants soient alertés lorsqu'une machine ou une personne à besoin d'assistance.


Et l'Extreme Programming

On peut retrouver ces principes dans l'association de diverses pratiques :

Conjointement, ces pratiques permettent de surveiller en continu la qualité du système. Mais il reste de la responsabilité du développeur de s'intéresser constamment à cette surveillance, et d' "appuyer sur le bouton rouge" en cas d'erreur.


Standardized Task

Il faut utiliser à tous les niveaux des méthodes stables que l'on peut répéter, afin d'assurer la predictabilité et maintenir des délais et des produits finis réguliers dans les processus. C'est la base des autres principes Flow et Pull. Cette standardisation nécessite de la discipline. Lors de tâches répétitives, un "boulon mal serré" par exemple, peut avoir de lourdes conséquences.

La contrepartie, est que cela donne plus de temps pour réfléchir à l'optimisation des processus standards. Une fois engrangée la connaissance accumulée sur les processus, il faut laisser la créativité s'exprimer pour améliorer ces processus maîtrisés. Puis intégrer cette amélioration au standard afin de pouvoir conserver et propager ce savoir si l'initiateur s'en va.

Tout le monde doit pouvoir exprimer son idée. On estime à 80 000 le nombre d'idées proposées par an par l'ensemble des ouvriers de l'usine Toyota de Georgetown (Kentucky, Etats Unis), dont +/- 99% sont développées. En effet, une source insidieuse, et souvent inconsidérée, de muda est la créativité inutilisée.

Il faut voir l'automatisation des standards comme laissant plus de temps aux salariés pour la réflexion et la créativité. Il faut également encourager et capitaliser leur expression.


Et l'Extreme Programming

La discipline et la rigueur sont élevées grâce au travail en binôme, même (et surtout) sur des tâches apparemment sans importances.

L' IntégrationContinue, les tests (unitaires et de recette), une conception simple, les conventions de code et sa propriété collective, assurent en plus la stabilité dans la façon de travailler et le produit livré.

Quand à la prédictabilité, l'aptitude à maîtriser les délais, elle est assurée par l'équipe. Les développeurs estiment les tâches au planning game, en se reposant notamment sur le travail préalable de rétrospective sur l'itération précédente : quelles tâches ont été mal estimées, pourquoi et comment mieux faire. Il existe même un rôle dédié pour améliorer la maîtrise de la prédictibilité : le tracker.

Quand à la réflexion et la créativité de chacun, elle peut être entendue durant le développement d'une tâche, quotidiennement durant le stand-up meeting, en début/fin de chaque itération au plannig game. Plus spontanément, lorsqu'un binôme en difficulté demande leurs avis à ses voisins ou qu'un développeur entend une conversation qui l'interpelle : tout cela est possible grâce à une disposition pertinente de la war room (l' open-space de l'équipe).


Visual Control : Des contrôles visuels

Il faut afficher des résultats compréhensibles, "visibles", pour mieux détecter d'éventuels problèmes.

Ces contrôles visuels simples ont pour but de mettre en évidence si l'on s'écarte ou non des conditions standard. C'est pour cette raison que, dans la mesure du possible, il faut privilégier un graphique tenant sur une feuille papier à un rapport de plusieurs (centaines) de pages.

On parle de ANDON du nom des lampes en papier japonaises.

Il est aussi difficile qu'important de produire des graphes sans bruits, capables de mettre en évidence un disfonctionnement.

Encore une fois, en plus de la compétence à produire ce genre de révélateur, cela implique d'inciter à cette pratique, de l'encourager et non pas réprimander celui qui viendrait de mettre en évidence un disfonctionnement ou une lacune.


Et l'Extreme Programming

Nous avons mis en œuvre ce genre de graphes sur les différents projets où j'ai travaillé en ExtremeProgramming...

Un premier graphe, fait sur un tableau blanc, mis à jour chaque matin, avec deux courbes qui se superposent. La première indique le nombre de fonctionnalités restant à implémenter en fonction du temps. Elle commence à gauche en haut de l'axe des ordonnées (Y). La seconde indique le nombre de fonctionnalités déjà implémentées en fonction du temps. Elle commence à gauche en bas de l'axe des ordonnées (Y), à zéro. L'unité de l'axe des abscisses (X) peut être l'itération (voire la semaine). Un pallié indiquerait une stagnation (aucune nouvelle fonctionnalité réalisée sur l'itération), ce qui est anormal !

Actuellement, dans mon équipe nous venons de mettre en place un autre indicateur : chaque scénario de l'itération est imprimé au format A5 et collé au mur selon une ligne horizontale, les prioritaires à gauche, et les moins importants à droite. Si un scénario imprévu est inséré en cours d'itération, il est marqué d'une croix rouge. Dés qu'un binôme est libre, ses 2 membres collent leurs noms en dessous du premier scénario à faire (le plus à gauche). Dés qu'un scénario est terminé et validé par notre serveur d'intégration continue, nous faisons une croix sur la fiche A5. Cela permet d'avoir à tout instant une idée de l'avancement, du taux de réalisation. En fin d'itération, si le nombre de scénarios non réalisés est important, alors qu'aucun scénario imprévu n'a été ajouté, on "appuie sur le bouton rouge".


Reliable technology : fiabilité

Un autre slogan Toyota : "It is never a people problem it is always a process problem".


Les personnes et les processus doivent passer en premier, et la technologie vient après. Cela signifie que l'attention doit se porter sur les personnes et les méthodes. La technologie n'est là que pour les servir, non pour les remplacer. De plus, il faut utiliser des technologies qui ont déjà fait leurs preuves, celles qui sont stables et testées, et laisser les autres payer les pots cassés sur les nouvelles technologies, souvent incertaines. Si une technologie entre en conflit avec la culture, il faut la rejeter ou la modifier afin de ne pas risquer d'entamer la stabilité, la fiabilité et la predictabilité des processus en place : un processus en place et validé est bien plus important et précieux que toute nouvelle technologie.


Dans les usines Toyota il n'y a pas ou peu de machines dernier cri, mais surtout des machines éprouvées.


Cependant afin de ne pas passer d'une technologie éprouvée à une technologie obsolète, il est tout aussi important de stimuler la recherche. Pour cela, il faut tester maintenant les nouvelles technologies que l'on adoptera demain. Et lorsque l'on change, il faut toujours garder une solution de rechange (l'ancienne). Il faut encourager les gens à considérer les nouvelles technologies. Une fois validées, on pourra les mettre en place ponctuellement si elles permettent d'améliorer la fluidité des processus (principe Flow).


Et l'Extreme Programming

Ce principe n'est pas directement repris par une des 5 valeurs ou des 13 principes XP. Concrètement, le choix des technologies utilisées est toujours fait très tôt, parfois avant la formation de l'équipe, et orienté, voire imposé, par un historique, le domaine de compétence de la société voire des considérations "politiques".

Pour ce qui est de l'incitation à la recherche, il n'est pas non plus explicitement exposé dans les principes XP. Par contre, sur les missions XP que j'ai réalisées, j'ai toujours été incité à passer du temps sur ce qui se faisait à côté, ce qui se faisait de nouveau. On m'impliquait dans les discussions, et lorsque je parlais d'une technologie, voire en proposait une, j'ai toujours été écouté. Se pose ici la problématique du temps à consacrer à cette exploration.


Les personnes

Grow leader : Faire grandir les responsables

Un autre principe Toyota est de faire grandir les leaders. Un des rôles de tout responsable Toyota est en effet d'amener ceux qui en ont la fibre, ceux qui comprennent le métier et la philosophie, à prendre des responsabilités. Le terme japonais pour cela est SENSEI. Un sensei est :

  • Un maître de l'Art,
  • Capable d'enseigner son Art.

Une des idées sous-jacentes, est qu'il vaut mieux accompagner un "interne" dans sa croissance jusqu'à un rôle de leader, plutôt que d'en "acheter" un à l'extérieur.


Evidemment, pour accomplir pleinement son rôle de "tuteur", un bon leader doit connaître le travail au quotidien dans ses moindres détails. De plus, il doit avoir un rôle exemplaire dans le respect de la philosophie de la société et sa façon de faire des affaires.


Et l'Extreme Programming

On retrouve cette notion dans le rôle de coach. Il permet en effet aux membres de l'équipe de se développer afin d'accompagner l'équipe vers une bonne auto-organisation.

A l'heure où j'écris ces lignes, je connais une personne qui est à mi-parcourt de sa mission de 6 mois. Son rôle : Coach XP dans une équipe de 7 personnes dont le projet va mal (livraisons boguées, donc quasi-quotidiennes, dépassement des budgets...). Sa mission : en 6 mois, 7 grand maximum, devenir inutile en ayant amené l'équipe à un degré de maturité suffisant pour qu'elle se passe de lui, tant au niveau de l'auto-organisation que de la qualité du travail produit.


Developp exceptional people : Développer les personnes exceptionnelles

Ce principe de développer des personnes d'exception se retrouve très tôt chez Toyota : dés l'embauche. En effet, il est très difficile de rentrer chez Toyota. Mais une fois entré, tout est mis en oeuvre pour valoriser la personne et la faire "grandir".


Pour cela, la formation continue tient une place importante chez Toyota. Entraîner des individus et des équipes exceptionnels amène des résultats exceptionnels. Par exemple, l'une des premières épreuves est de donner un travail trop difficile, pour forcer/apprendre à demander de l'aide. Cela va de paire avec la notion de sensei vue précédemment.


Une autre façon de faire progresser les personnes, et donc d'améliorer tant la qualité que la productivité, est de les faire travailler en équipe d'individus aux profiles et aux compétences fonctionnelles divers. Il faut produire un effort de tous les instants pour apprendre aux individus à travailler ensemble sur un but commun : le travail en équipe est une notion qui s'apprend et qui doit être apprise.


Tout cela doit se faire en respectant la culture de l'entreprise afin que cette culture d'entreprise soit perpétuée...


Et l'Extreme Programming

Pour ce qui est de la sélection d'un nouveau membre d'une équipe XP, les critères de sélection sont plus vastes que pour une équipe au mode de fonctionnement « traditionnel ». Par expérience, lorsqu'un membre de l'équipe pose problème, c'est très souvent (toujours) pour des raisons non techniques. Autant il est relativement aisé d'amener à un niveau correct (technique ou fonctionnel), un nouveau développeur, autant il est difficile d'amener au binômage ou à la propriété collective du code une personne sceptique. C'est pour cette raison que les responsables amenés à constituer ou étoffer une équipe XP sont bien plus attentifs et exigeants que bon nombre d'autres responsables. On retrouve ici l'exigence Toyota en terme d'embauche.


De plus, lorsque les membres d'une équipe binôment ensemble 8 heures par jour pendant un an, voire d'avantage, il est important d'être particulièrement vigilent au profile de ces membres lors du recrutement.

Pour ce qui est de la formation continue, la pratique du binômage est sans conteste la meilleure façon d'assurer une remise à niveau permanente, tant sur un plan technique, que du fonctionnel de l'application ou du domaine métier. Pour ce dernier point, le client sur site est un luxe inestimable.

En plus du travail quotidien dans la war room, le travail en équipe est régulièrement entretenu lors des planning game, c'est à dire à chaque début d'itération (toutes les deux semaines généralement). L'équipe fait alors une mini rétrospective de l'itération précédente, où chacun doit participer, afin d'identifier les problèmes et donc les pistes d'amélioration. Puis, l'appropriation du fonctionnel à réaliser et de l'existant de l'application pour estimer les nouvelles tâches à implémenter, implique la participation de chacun dans un travail d’équipe.


Enfin, concernant le développement des personnes, je comparerais le développeur XP à un heptathlonien. En effet, un bon développeur XP doit maîtriser, du moins pratiquer de façon régulière des disciplines variées : le développement pur, mais aussi les tests (unitaires et fonctionnels), la conception, l'estimation, la gestion du risque, le domaine métier sans oublier la communication...


Challenge, Respect, Help partners : Motiver, respecter et aider ses partenaires

Dés le début, il faut impliquer l'ensemble de l'équipe virtuelle, à savoir tous ceux qui sont impliqués de près ou de loin dans le projet. Un bon moyen est encore de constituer des équipes de membres aux compétences fonctionnels variées. Cela pourra se faire dans une grande salle ou OBEYA.


Un individu ne peut travailler efficacement sans un travail efficace des autres membres de l'équipe. Une équipe ne peut travailler efficacement sans un travail efficace des autres équipes de la société. De même, la société ne peut travailler efficacement sans un travail efficace de ses partenaires. Il est donc important de diffuser le Just in time (ou hijunka) chez ses partenaires. Les partenaires et fournisseurs doivent être vus comme une extension des affaires, de la société, et donc être considérés avec respect. Lancer des défis pertinents aux partenaires, et les aider à les atteindre, permettra à ces partenaires de croître et se développer, donc d'apporter d'avantage à la société.


Lisser la production chez Toyota implique de lisser la production chez ses partenaires, mais dans le respect de ces derniers.

Prenons un exemple polémique. Aux USA, si un constructeur automobile veut faire baisser le coût de ses fournisseurs, il les appelle et leur impose de baisser leurs tarifs de 5%. Toyota annoncerait à son fournisseur sa conviction que ce dernier est capable de baisser ses coûts de 10%. S'il accepte que des personnes de Toyota viennent l'aider pour atteindre cette baisse, alors :

  • Le fournisseur devra baisser ses tarifs Toyota de 5%,
  • Il empochera alors les 5% restant comme bénéfices,
  • Plus les 10% qu'il fera maintenant sur les ventes aux concurrents de Toyota,
  • Sachant que Toyota imposera en plus qu'il maintienne ses tarifs à la concurrence.


En effet, beaucoup de grands constructeurs (ou supermarchés) exigent de leurs fournisseurs des livraisons Just in time, sans qu'eux-mêmes soient lean ("épurés"). Ils ne lissent pas leur production et imposent donc une charge très difficile à prédire sur leurs fournisseurs, ce qui entraîne du muri.


Et l'Extreme Programming

Si on demandait les fonctionnalités une à une au client, cela nécessiterait de sa part un effort soutenu. On travaille donc en itérations, qui deviennent un juste milieu pour le client.

Le respect est justement la cinquième valeur XP qui est apparue dans la deuxième version. Cette valeur, qui doit être réciproque entre l'équipe et le client, est nécessaire pour un travail efficace sur le long terme. Le client respecte les annonces et les estimations de l'équipe qui en retour respecte ses priorités et ses attentes.

L'aide au partenaire/client tient souvent aux livraisons et à leur fréquence. Livrer fréquemment pour un retour aussi fréquent permet au client de juger de la pertinence de ses demandes. Parfois, ces livraisons permettent au client de se structurer d’avantage, de mieux cerner ses propres besoins.


L'amélioration

Genchi Genbutsu : Le même outil, la même place

Pour comprendre, identifier un problème, il faut utiliser le même outil à la même place.

Lorsqu'un disfonctionnement survient lors de la réalisation d'un besoin du client, il faut emprunter le chemin, suivre la chaîne, faire l'effort de se déplacer pour aller comprendre la situation sur place, identifier sur le terrain les vrais problèmes, les sources de muda.

Il ne faut pas théoriser sur ce que les personnes et les ordinateurs disent, mais attacher une attention toute particulière aux endroits où l'on ajoute de la valeur, ou GENBA qui en japonais signifie "lieu du crime". Genba est la place où l'on ajoute de la valeur, là où l'on dessine ou fabrique les voitures, pas dans les bureaux et salles de réunion.

On parle encore de Value Stream Mapping. Cela consiste à schématiser le processus et y indiquer à chaque étape combien de temps on passe à ajouter de la valeur. On voit souvent que le temps "valeur ajouté" ne représente que quelques pourcents du temps total de production. Bien sur on va sur place pour observer le processus. Les experts Lean vont souvent suivre le processus "à l'envers", de la fin au début, pour voir les possibilités d'introduire des systèmes "pull".


Afin de se prémunir de situations critiques, il faudra s'assurer que l'ensemble de la chaîne est respecté et ne pas présupposer de l'existence des maillons. Complément indispensable du Genchi Genbutsu, le HOURENSOU ("épinards" en japonais) regroupe ce que chaque dirigeant japonais attend de son équipe, à savoir :

  • Ce que j'ai fait (Report ou HOU KAKU),
  • Ce que je vais faire (Inform ou REN RAKU),
  • Comment le dirigeant peut m'aider (Consult ou SOU DAN).

Le hourensou, qui se pratique de haut en bas, s'adresse même aux cadres dirigeants de la société qui pourront ainsi acquérir plus qu'une vision superficielle de la situation.


Et l'Extreme Programming

Le stand-up meeting dans une moindre mesure mais au quotidien, et surtout le planning game, sont l'occasion de faire le point sur les disfonctionnements de la chaîne de développement.

Le fait d'avoir un client sur site facilite ce rapprochement entre les maillons de la chaîne.

Le tracker est un rôle désigné et dédié pour à l'identification des disfonctionnements dans les estimations et la perte de contrôle de la prédictibilité.

De façon pragmatique, le genchi genbutsu se retrouve dans les TestReleases. En effet, ils ont pour but de simuler les actions utilisateur afin d'identifier d'éventuels bugs avant l'utilisateur.


Nemawashi : Bien creuser autour de la plante pour la déplacer

Cela consiste à consulter l'ensemble des personnes impactées par une décision afin de recueillir un maximum d'alternatives et d'obtenir un véritable consensus.


Cette pratique est coûteuse en temps, mais sur le long terme, ce processus demeure cependant plus rapide que la confrontation ou les décisions en douce, et surtout satisfait d'avantage de personnes. Les décisions doivent être prises consciencieusement en considérant toutes les options, mais une fois prises elles doivent être implémentées rapidement et avec précaution.


De plus, les décisions les plus difficiles à changer doivent être prises à la fin afin de limiter l'impacte d'un changement éventuel. C'est ce que l'on nomme le Delay Commitment : on prend les décisions le plus tard possible, quand on a plus d'informations; on essaie de laisser les options ouvertes le plus longtemps.

Pour cela on peut s'appuyer sur le Set Based Design. Quand on dessine une nouvelle voiture, on prend en compte plusieurs conceptions de châssis, plusieurs moteurs... On teste et essaie les différentes combinaisons et on réduit graduellement le nombre de choix, jusqu'à ce qu'on arrive à la meilleure combinaison.


Et l'Extreme Programming

Les décisions fonctionnelles, la prioritisation des scénarios, sont la responsabilité du client. Par contre, l'équipe doit rester force de proposition et faire un feedback si une décision est absurde, trop coûteuse ou simplement non pertinente.

Au sein de l'équipe, les décisions techniques sont prises collégialement durant la phase d'estimation du planning game. En cours d'itération, si un doute apparaît, ou des questions se posent, une réunion spontanée est alors organisée entre les développeurs concernés (tous).

Encore plus en profondeur, dans le code, il est possible d'identifier les différentes parties de l'application concernées par une modification à venir grâce aux tests. Les TestUnitaires et les TestReleases qui échouent suite à une modification préalable du code permettent d'avoir une idée de l'importance et les impactes de la modification, donc d'estimer plus justement les coûts de la modification.

Une lacune d'XP par rapport au ToyotaWay serait ici la notion de communication entre l'équipe et les autres personnes/équipes du projet ?!...


Hansei & Kaizen : Réfléchir et optimiser

HANSEI signifie réfléchir à comment mieux faire. KAIZEN est synonyme d'optimisation continue.

Une fois qu'un processus est stable, un moyen de l'améliorer est la règle des "5 Pourquoi". Pour un processus donné, se demander pourquoi on fait ainsi. Une fois la réponse obtenue, la confronter à un autre pourquoi... Et ainsi de suite, 5 fois, afin de mettre en évidence la véritable raison, le besoin véritable.

Supposons, par exemple, qu'une machine se soit arrêtée de fonctionner.

  1. Pourquoi la machine s'est-elle arrêtée ? Parce qu'il s'est produit une surcharge et que les fusibles ont sauté.
  2. Pourquoi cette surcharge ? Parce que la lubrification des coussinets était insuffisante.
  3. Pourquoi la lubrification était-elle insuffisante ? Parce que la pompe de graissage ne pompait pas suffisamment.
  4. Pourquoi la pompe de graissage était-elle insuffisante ? Parce que l'arbre de la pompe était endommagé et vibrait.
  5. Pourquoi était-il endommagé ? Parce qu'il n'y avait pas de filtre, ce qui a entraîné l'inclusion de déchets métalliques.

En répétant à plusieurs reprises "pourquoi" comme dans cet exemple, chacun se met à même de pouvoir découvrir les problèmes réels pour ensuite y remédier.

Concevoir des processus qui ne requièrent quasiment pas d'inventaire permet de rapidement mettre en lumière les pertes de ressources et de temps. On peut alors demander aux employés de travailler à l'amélioration des processus afin d'éliminer toute source de muda.


Antoine de Saint-Exupéry pensait que "la perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever". La notion de POKA YOKE reprend cette idée : faire les choses tellement simple qu'il n'est plus possible de faire d'erreurs.

Pour illustrer cette notion, prenons l'exemple de connecteurs multimédia :

  • Le connecteur USB est simple : il n'y a pas moyen de mal le brancher, mais la prise rectangulaire mâle peut être mal présentée à la prise femelle (face supérieure différente de la face inférieure).
  • Par contre, une prise d'antenne TV, ronde et symétrique, est forcément bien branchée. Il n'y a aucun moyen de mal la présenter. Elle est poka yoke.


Lorsque l'on détecte un problème, afin de l'améliorer, il faut se poser les questions suivantes :

  1. Pourquoi les tests n'ont pas détecté l'erreur ?... Penser Indoka.
  2. Pourquoi on a fait cette erreur ?... Penser Poka Yoke.

Sur le long terme, on protégera la connaissance de l'entreprise en développant un personnel stable, de lentes promotions et un renouvellement prudent des systèmes.


Et l'Extreme Programming

En retrouve explicitement la notion de poka yoke dans les différentes strates de l'ExtremeProgramming:

  1. La simplicité est une des 5 valeurs XP.
  2. Faire la chose la plus simple qui puisse fonctionner (YAGNI) ou "T'en auras pas besoin" sont des principes XP.
  3. La conception simple est une des 13 pratiques XP.


La façon dont on traite un nouveau bug permet d'accroître la stabilité de l'application :

  1. Le client détecte une erreur
  2. On fait 1 TestRelease,
  3. On fait n TestUnitaires,
  4. Alors seulement on fait l'implémentation.

La stabilisation du système s'accompagne d'une couverture de tests accrue.


L'amélioration continue de l'équipe et de ses pratiques, est amenée par la rétrospective succincte que l'on fait en début de planning game sur l'itération qui vient de se terminer.


Implicitement, on retrouve la règle des « 5 Pourquoi » dans le développement en binôme. Lorsque l'on travaille à 2, de par les profiles, les compétences, l'expérience, l'humeur, etc..., de chacun il y a forcément (et heureusement) des façons de voir différentes dans la façon de faire, d'aborder les choses, et donc forcément (et heureusement) des questions qui surgissent. Pour entretenir cet état moteur, il est important de former intelligemment les binômes (lors du stand-up meeting), et aussi de les faire tourner fréquemment afin de ne surtout pas laisser s'installer un état de lassitude et de passivité. Lorsqu'un binôme s'enlise dans une tâche sans fin, le simple fait de renouveler un membre du binôme, obligera le « nouveau » à poser des questions élémentaires afin de rentrer dans la tâche. Ces questions, sur les élémentaires de la tâche, pouvant amener les bonnes réponses pour sortir du tunnel.


Les pratiques du binômage, du remaniement continue et des séances de rétrospective durant le planing game sont des pistes permanente d'auto-apprentissage et d'amélioration.


Mais surtout, le principe même d'une méthode itérative, est de s’appuyer sur le réalisé pour orienter ses choix futurs et donc s'améliorer.


Hansei et Kaizen résument à eux seuls les développements Agiles, car en appliquant ces 2 principes, on devient agiles, au fur et a mesure que l'on améliore la méthode de travail, et cela indépendamment de la méthode de travail que l'on utilise !


La philosophie

Long term philosophy : Longuement mais sûrement

Assurément le plus difficile à mettre en œuvre, ce principe prône l'investissement (dans tous les sens du terme) sur le long terme. S'il est bien un principe "infalsifiable", c'est celui là : soit on l'applique vraiment, soit on ne l'applique pas.


Cela va de paire avec la chasse au gaspillage : cette quête de la perfection est toujours plus bénéfique avec le temps et plus rarement à court terme. A tous les niveaux, il faut s'assurer que l'on génère de la valeur pour :

  • Le client,
  • La société,
  • L'économie.

Dans le cas contraire, on génèrerait du muda : donc on s'abstient. Il faut maintenir et améliorer ses compétences afin de produire de la valeur ajoutée. Chaque action de la société doit être envisagée et évaluée dans ce sens.


De plus, il faut rester maître de son sort, agir avec indépendance en faisant confiance à ses capacités, mais accepter en retour les responsabilités pour sa conduite. En 1948, au sortir de la Seconde Guerre Mondiale, Toyota licencie 1800 personnes pour manque d'argent. Le PDG de l'époque à commencer par se licencier lui-même, se considérant comme le premier responsable de cette crise en raison de ses choix.


Vous l'aurez compris, le maître mot est la Patience. Il faut 5 à 10 ans à Toyota pour mettre en place le ToyotaWay lorsqu'ils ouvrent une nouvelle usine ou un nouveau centre de distribution. Et il leur a fallu 50 ans pour en arriver là.

Faire croître la société vers une ligne de conduite commune, un même but, est plus important que de générer de l'argent. Si l'on y parvient, générer de l'argent sera alors un effet de bord inévitable ;o)

C'est l'Agilité de bas en haut.


Et l'Extreme Programming

La valeur de simplicité est nécessaire pour résister au temps et éviter que l'application ne s'effondre sous le poids d’une architecture trop complexe.


La valeur de courage est quand à elle nécessaire pour soutenir l'effort indispensable à une amélioration continue sur le long terme, et ne pas s’user face à l'inertie, la lourdeur de certaine structure, certaines hiérarchies.


Plus concrètement, les pratiques d' intégration continue et de tests, de métaphore (pour la connaissance qu'elle propage) et des conventions de code, participent à la stabilité sur le long terme.


Sur le court terme, certaines pratiques, binômage en tête, peuvent être perçues uniquement comme un doublement des coûts.

Mais dés le moyen terme, et encore plus sur le long terme, ces pratiques (binômage, rythme soutenable, conception simple, propriété collective du code, convention de code...) assurent un partage, une homogénéisation des connaissances, une meilleure résistance de l'équipe et favorise ainsi la stabilité et la pérennité du système. XP mise donc sur le long terme, où le surcoût initial devient un investissement rentable.


Conclusion

J'aurais également pu aborder le ToyotaWay sous l'angle des 7 types de gaspillage : surproduction, temps d'attente, transports, stocks inutiles, gaspillages dans les processus de fabrication, mouvements inutiles et pièces défectueuses. J'ai choisi cette orientation car elle permet de mieux souligner le parallélisme avec l'ExtremeProgramming.


Ainsi, il semble que le ToyotaWay inclut dans ses pratiques la rétrospective et le travail collaboratif entre les différentes équipes du projet, de la société. Notions moins évidentes dans les pratiques XP

L'intérêt du ToyotaWay est qu'il s'agit d'une méthode qui est appliquée dans toute l'entreprise, et avec succès au regard des chiffres.


Au final, on pourrait prendre le raccourci de résumer le ToyotaWay par la tendance maniacale à la perfection sur le long terme. Pour atteindre cette perfection, Toyota met en oeuvre une séquence que l'on retrouve dans les Art Martiaux :

  1. Apprendre en mimant machinalement le modèle,
  2. Comprendre une fois le modèle maîtrisé,
  3. Alors seulement innover pour améliorer.

Ce principe de comprendre pour améliorer s'inscrit assurément dans la durée.

On retrouve cette notion en ExtremeProgramming, où il est nécessaire d'accroître la maturité de l'équipe avant d'arriver à un niveau d'auto-organisation satisfaisant...


Le ToyotaWay, comme l'ExtremeProgramming, tire son succès de la synergie de pratiques dont la plupart sont issues du bon sens. Ces principes, issus du monde de la production, ont été adaptés au monde du développement logiciel et exposés dans un livre : Lean Software Development. Au delà, il serait intéressant de voir comment on développe des logiciels chez Toyota ?!...

Maintenant que les règles gagnantes sont clairement exposées, on peut se demander quelle société deviendra, au prix d’efforts durables, le Toyota du développement ?... Saperlipopette... Charlie Poole nous a pourtant mis en garde à l'XP-Day d’adapter notre langage au monde des décideurs. Reposons donc la question différemment : Quelle société d'informatique veut peser 150 milliard de dollars ?

;o)

Ressources

En plus de la page ExtremeProgramming, je vous conseille l'excellent livre de Dominic Williams, Regis Medina et Laurent Bossavit, ré-edité chez Eyrolles sous le titre « Gestion de projet : EXtreme Programming »


Le livre Toyota Way: 14 Management Principles from the World's Greatest Manufacturer et un extrait sur http://books.google.fr


Concernant le LeanDevelopment :


Le livre « Project Retrospectives: A Handbook for Team Reviews » de Norman L. Kerth., que l’on peut retrouver sur le site http://www.retrospectives.com .