Approche Lean

Définition de l'approche Lean

Lorsque SAFe fait référence à l'agilité, c'est le terme " lean-agile " qui apparaît dans toute sa documentation [SAFe 2021-21]. En effet, l'agilité trouve ses racines dans le Lean, dont le terme a été popularisé par [Womack 1990], qui retrace le succès de Toyota [Poppendieck 2002].

Jeff Sutherland, le co-daddy de Scrum, a basé ce cadre sur son étude du Lean [Sutherland 2007] et a même trouvé le nom du cadre [Sutherland 2011] dans un article du fondateur du Lean Management intitulé "The New New Product Development Game" [Takeuchi 1986].

Aussi, les pratiques Lean sont une grande source d'inspiration pour enrichir les pratiques agiles car elles sont mieux comprises et limitent l'effet " Cargo Cult " [Moustier 2019-1] [Wikipedia 2021] qui consiste pour une équipe à se croire agile simplement parce qu'elle a Jira ou des post-its collés sur un mur.

Parmi les pratiques Lean que l'on retrouve dans l'industrie et qui peuvent être transposées au développement logiciel, on peut citer [Moustier 2019-1] :

• éliminer les déchets grâce aux 3M (Muda, Mura, Muri) [Monden 2011].
• l'optimisation du flux du cycle de vie des logiciels grâce à la cartographie de la chaîne de valeur (VSM) [Poppendieck 2006].
• la vitesse d'adaptation d'un outil à un changement de besoin avec le SMED [Shingo 1985], dont l'agilité se traduit par une adaptation rapide de l'équipe aux changements [Beck 2001].
• le principe de chronométrage du travail avec le Takt Time [Monden 2011], que la pratique du timeboxing facilite [Schwaber 2020].
• Kanban [lundi 2011] [Poppendieck 200].
• Travaux en cours (WIP) [Monden 2011]
• le juste-à-temps (JIT) [Monden 2011], qui consiste par exemple à ne remplir le carnet de commandes qu'au moment opportun
• Poka Yoke [Monden 2011] en mettant en place des mécanismes qui empêchent les erreurs de se produire.
• les 5S [Monden 2011] pour éliminer le superflu, systématiser, faire briller/nettoyer, localiser/étiqueter et suivre tout type d'élément tel qu'un arriéré, un code source, bugs, etc.
• Andon [Monden 2011] pour lever et gérer les alertes, par exemple au moment de la mêlée ou de la gestion des alertes dans SRE [Beyer 2016].
• Jidoka [Monden 2011] pour traiter automatiquement les incidents rencontrés dans les scripts [Moustier 2020].
• la pratique régulière du Gemba [Womack 2011] pour améliorer la transparence chère à Scrum [Schwaber 2020].
• PDCA [Moen 2010] pour améliorer continuellement le système.

Il existe également d'autres pratiques dérivées couramment utilisées dans l'industrie, comme [Moustier 2020] :

• Théorie des contraintes pour éliminer les goulets d'étranglement par une approche systémique
• Hoshin Kanri [Cudney 2009], que l'on retrouve dans les OKRde Google.
• Kaizen [Medinilla 2014] et Kaikaku [Yamamoto 2013].

Application de l'approche lean à la maturité des tests

L'activité de test doit être industrialisée pour faire face à la grande quantité de tests qui doivent être effectués dans la courte période de temps qu'est le sprint. Les pratiques Lean de l'industrie sont, avec un peu d'imagination, parfaitement transférables à cette activité, pour autant que l'on comprenne ces pratiques et ce qui les sous-tend :

• 3M : tests réguliers, sans excès (sur-qualité ou trop de tests) et avec une bonne valeur ajoutée
• VSM : durée des activités de test dans le flux de production [Moustier 2020].
• SMED : adapter rapidement sa stratégie de test aux livrables à vérifier - les tests exploratoires sont particulièrement pertinents dans ce contexte.
• Takt Time : calendrier des activités de test dans un délai limité.
• Kanban : les activités liées aux tests sont dans le kanban de l'équipe, soit dans chaque User Story, soit sous forme de Quality Stories [Bach 2019] (ce que SAFe appelle des "Enablers" [SAFe 2021-23]).
• WIP : les essais doivent avoir lieu sans délai et être soutenus par tous.
• JIT : les tests sont effectués à temps
• Poka Yoke : des tests automatiques interviennent pour signaler rapidement l'apparition d'anomalies [Moustier 2019-1].
• 5S : les moyens d'essais doivent être régulièrement purgés [Moustier 2019-1].
• Andon : dès qu'une anomalie est détectée par les tests, une alerte est levée [Moustier 2019-1].
• Jidoka : les scripts de test automatisés doivent s'adapter pour essayer de traiter les anomalies apparentes et éviter les faux positifs [Moustier 2020].
• Gemba : le testeur doit être la voix du client dans l'équipe et l'implémentation de X-Team [Ancona 2002] est d'une grande valeur ajoutée pour essayer de synchroniser les écocycles externes à son équipe [Moustier 2020].
• PDCA : l'activité de test doit être améliorée en permanence

La position d'Agilitest sur l'approche lean

La stratégie #nocode [Forsyth 2021] adoptée par Agilitest permet une adaptation très rapide des scripts de test et favorise la plupart des pratiques Lean mentionnées ci-dessus ; de plus, cette stratégie réduit le sentiment d'aversion à la perte [Moustier 2019-1] lié à la suppression d'un script, ce qui facilite les 5S.

Dans une approche de test continu où l'automatisation des scripts de test est abondante, la question du Jidoka est critique car la gestion des faux positifs ralentit le flux du cycle de développement [Moustier 2020]. A cet effet, #nocode permet de générer peu d'erreurs dans les scripts, ce qui réduit considérablement la présence d'erreurs liées aux scripts.

Un domaine d'amélioration essentiel pour faciliter Jidoka est la testabilité de l'application et de ses composants sous-jacents, de sorte qu'une erreur détectée à un niveau puisse être vérifiée à une couche inférieure de l'architecture du produit.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.