Andon
Test actifEn cas d’erreur identifiée, une correction immédiate est requise avec une escalade qui mobilise l’organisation si cela ne suffit pas
Qu'est-ce qu'Andon ?
L'Andon (行灯) est historiquement une lanterne en papier sur un cadre en bambou qui était très populaire à l'époque d'Edo. Son écriture en japonais signifie littéralement "Go" (行) - "Lanterne" (灯). C'est devenu un outil présent dans l'industrie du lean qui signale visuellement un problème ou plus généralement une alerte qui va nécessiter une aide. Cette alerte peut également signifier, lorsqu'elle n'est plus visible, un retour à la normale [Moustier 2019-1]. Cet outil visuel est traditionnellement utilisé dans l'industrie manufacturière pour montrer l'état des opérations dans une zone et surtout pour signaler l'apparition d'anomalies [Kemmer 2006].
En ce qui concerne les alertes, le SRE de Google propose trois niveaux [Beyer 2016] :
- Niveau 1: actions immédiates à entreprendre pour résoudre l'alerte
- Niveau 2: actions qui peuvent être planifiées pour gérer l'événement
- Niveau 3: information simple qui doit être enregistrée pour une analyse future.
Par conséquent, Andon est une sorte de système de surveillance basé sur des capteurs situés là où de bons ou de mauvais événements peuvent se produire, combiné à une prise de décision au niveau de l'alerte et d'un tableau de bord pour aider à l'autonomie.
En termes de Shift left et Shift right testing, cela signifie que les questions de développement, de livraison et de produit doivent être surveillées grâce à des observables et des politiques qui mènent à Jidoka. Andon encourage également l'élimination des anomalies dès qu'elles apparaissent selon l'approche Kaizen.
Influence sur la maturité des tests
Pendant le Sprint, la transparence est facilitée pour Andon. Plus les problèmes sont visibles, plus l'objectif du sprint est maîtrisé. En ce qui concerne les problèmes, il ne s'agit pas seulement du site bugs mais aussi de tout obstacle. Le moment le plus propice pour partager ces obstacles est la réunion quotidienne de Scrum. C'est le moment idéal pour obtenir de l'aide et créer un groupe de travail sur le problème afin d'éviter de mettre en péril les objectifs du sprint.
En ce qui concerne la livraison, le WIP fournit également quelques bonnes mesures sur le flux. Tant que le nombre d'histoires d'utilisateur en cours (US) sur un tableau Kanban est maintenu sous le seuil acceptable, le flux de livraison est sous contrôle et aucun Andon n'est nécessaire. Dans le cas où le stock de US en cours d'exécution dépasserait la quantité acceptable de travail en cours, Andon est déclenché et l'équipe doit se mobiliser autour de certaines US en cours d'exécution pour les libérer et réduire le WIP. D'autres indicateurs tels que le rendement du premier passage ou le Niko-Niko peuvent également déclencher Andon.
Des capteurs peuvent également être ajoutés au produit. Ils permettent de vérifier que les indicateurs avancés de l'Epic [SAFe 2021-34] sont toujours "verts" et que les hypothèses sont toujours valables pour poursuivre la tendance budgétaire de l'Epic, ce qui reflète l'adhésion au domaine. Le produit doit également intégrer des capteurs pour surveiller l'infrastructure et l'adhésion de l'entreprise à la solution proposée.
En ce qui concerne la bonne santé du produit, un autre type d'observable qui peut être utilisé pour surveiller Andon est la quantité de bugs [Bjork 2017] et plus généralement la politique de traitement des anomalies.
Le point de vue d'Agilitest sur cette pratique
Les scripts de test automatisés offrent la possibilité d'arrêter éventuellement le pipeline de livraison si certains critères de gravité sont remplis, tels que showstopper. Cette situation conduit éventuellement à un Andon pour permettre la livraison.
Un autre Andon possible sur les scripts automatisés concernerait la quantité de flaky tests. Si trop de faux positifs sont relevés, le pipeline de livraison serait arrêté pour rien avec une augmentation du temps passé à livrer le produit. Ce problème peut être résolu en introduisant Jidoka dans le pipeline.
Pour découvrir l'ensemble des pratiques, cliquez ici.
Crédits
Icônes réalisées par
Cartes connexes
Pour aller plus loin
- [Beyer 2016] : Betsy Beyer, Chris Jones, Jennifer Petoff et Niall Richard Murphy - " Site Reliability Engineering : How Google Runs Production Systems " - O'Reilly Media - 2016 - ISBN-13 : 978-1491929124 - https://landing.google.com/sre/sre-book/toc/index.html
- [Bjork 2017] : Aaron Bjork - " Agile chez Microsoft " - Microsoft - 2017 - https://www.youtube.com/watch?v=-LvCJpnNljU
- [Kemmer 2006] : Sérgio L. Kemmer & Martina A. Saraiva & Luiz F. M. Heineck & Ana Valéria. L. Pacheco & Marcos de V. Novaes & Carlos A. M. A. Mourão & Luiz C. R. Moreira - JUL 2006 - "The Use of Andon in High Rise Buildingé" - https://www.researchgate.net/publication/254978249
- [Moustier 2019-1] : Christophe Moustier - JUIN 2019 - " Le test en mode agile " - ISBN 978-2-409-01943-2
- [SAFe 2021-34] : SAFe - FEV 2021 - "Epic" - https://www.scaledagileframework.com/epic/