(ou plutôt de la veille)
Je travaille en ce moment sur une application web qui gère un processus de souscription à différents produits d’assurance. Il s’agit d’un enchainement d’écrans pouvant aller jusqu’à 5 ou 6 formulaires d’affilée … ce qui fait que le pauvre développeur qui travaille sur le dernier écran est obligé de saisir les 5 premiers formulaires pour pouvoir admirer/tester son travail. S’il va directement au dernier écran au mieux ça le redirige vers premier (et au pire ça plante)
Pour améliorer la vie de mon malheureux développeur, j’ai développé un filtre Http qui vérifie s’il y a un paramètre « init=test » dans la requête ; si oui il positionne toutes les données de test nécessaires pour aller directement aux derniers écrans.
Cette petite amélioration s’avère être un véritable gisement de productivité :
- Temps de développement du filtre : 15 minutes
- Temps gagné par jour (et par développeur) : 30 minutes (ça aurait pu être mieux, mais c’est qu’il les saisit vite ses formulaires le bougre ;-)
Elle est pas lean la vie ? :)
N’hésitez pas à imiter/améliorer cette idée, c’est l’essence même de l’amélioration continue.
10 commentaires sur “Mon action lean du jour”
Et... imaginons que ton action t'ai pris des jours et des jours de développements, est-ce que ça vaudrait encore le coup / coût ? Est-ce qu'on peut savoir si une action est valable si on ne sait pas trop combien de temps elle prendra, et si au final elle risque de coûter plus cher que le temps qu'elle permet de sauver ?
Dans ce cas ton action n'est pas kaizen, il s'agit plutôt d'une innovation; les bénéfices et les risques sont calculés autrement. Une action kaizen est non seulement limitée, mais en plus fait l'objet d'une mise en oeuvre minutieuse qui répond exactement à toutes ces questions (coût ? avantages ? etc.) : Plan Do Check Act.
Pour préciser : le kaizen est une approche de l'amélioration continue incrémentale, présente dans le Toyota Production System. 'Lean' est le terme américain pour 'Toyota Production System'.
L'action de Christian est kaizen car
- c'est un petit changement
- elle améliore la productivité tout de suite
- il n'y a pas de risque de retour en arrière
- pour le développeur qui en profite, il n'y a pratiquement aucun inconvénient, presque rien de nouveau à apprendre, pas de pertubation, ni de risque
- elle permet -- et suscite -- d'autres améliorations
'15 minutes de travail pour 30 minutes de gains'.
A mon sens, ce procédé pour le développeur peut être encore plus valorisé (X * 30) si la douleur à laquelle il a répondu était mal vécue et entrainait d'autres conséquences non exprimées directement (anomalies, découragement...). Peut-tu me dire plus sur ce point ?
De même as-tu fait l'exercice de remettre cette amélioration du jour dans un contexte plus global (cycle de développement, intégration, mise en production) pour en mesurer la valeur ? Si oui, peut-tu aussi en dire plus ?
- Attention mac, je parle de 30 minutes par jour ! :)
- Pour l'instant je ne crois pas que cette 'douleur' ait entrainé d'effets secondaires particulièrement vicieux (en fait je l'ai identifiée assez rapidement, car j'ai eu à travailler moi même sur l'un des derniers écrans !)
- En ce qui concerne le fait de mettre cette amélioration en perspective dans un cadre plus large ... je ne vois pas exactement ou tu veux en venir ; peux tu éclairer ma lanterne ?
Bonsoir,
effectivement automatiser ou faciliter les tâches récurrentes me semble une bonne pratique 'lean'.
Par contre, j'ai quand meme 2 petites remarques:
- ajouter un nouveau paramètre dans l'action java 'init=test' me semble douteux car à priori ça veut dire du nettoyage avant avant d'imaginer un build de déploiement. Enfin il s'agit surtout ne pas oublier d'effacer ce patch qui injecte des données dans la session ou requête.
- peut-être même que l'utilsation de solutions existantes seraient encore plus 'lean' selenium.openqa.org/ ou www.roboform.com/ par exemple.
Voilà, bonne continuation dans le lean development ;)
Eric,
Merci pour tes remarques, je vais tenter d'y répondre :
- Tu trouves que le init=test relève de la bidouille, et je ne suis pas d'accord :). En effet, ce n'est pas la première fois que j'introduis dans mes applications un "mécanisme" permettant d'améliorer la productivité des développements. Le plus connu étant la génération du schéma de base de données par Hibernate (hbm2ddl pour les connaisseurs). En revanche je suis d'accord pour que ces "artifices" ne doivent pas aller jusqu'en production, et je ne peux pas manuellement "retirer ce patch" (et pour cause l'application est déployée en intégration 1x par jour !). Pour pallier à ce problàme je m'appuie donc sur l'environnementalisation (excusez le barbarisme) de la configuration (i.e. l'application s'appuie sur des fichiers de configuration différents dans chaque environnement, permettant d'activer/désactiver des fonctionnalités à notre gré).
- L'utilisation de Selenium est une bonne idée, je m'en sers sur cette application pour automatiser quelques tests de recette. En revanche je trouvais le filtre plus adapté pour l'amélioration de la productivité car il réduit le couplage entre mes écrans : si l'écran 4 connait une régression, le script Selenium plante et le développeur de l'écran 5 est pénalisé (voire bloqué) ; le filtre permet lui d'initialiser l'état de l'application sans passer par les écrans précédents. En revanche l'astuce du filtre marche ici parce que l'architecture de l'application l'y autorise, mais je pense que Selenium est une solution plus tout-terrain ;-)
A+
Christian
Bonjour,
merci pour ta réponse.
Je ne dis pas 'bricolage', parfois il n'y a pas le choix mais je pense que s'il y a moyen délocaliser cette injection de données ce serait mieux. Par exemple, avoir des controllers 'test' permettant de forger des données dans la session ou request avant de rediriger vers le controller 'production'.
Quoiqu'il en soit avec des fichiers de configuration, ca reste une solution plus que correcte si l'intégration se fait de façon fluide :D
Eric
Bonjour,
Pour ma part, j'ai également souvent rencontré ce problàme, et il est vrai qu'à part mettre en place une bidouille, il n'est pas simple d'industrialiser ce genre de mécanisme.
Cela dit, sur mon ancien projet, nous avions utilisé une variable d'environnement liée à la JVM (configurée via eclipse)+ des fichiers de conf spring qui, pour la peine ne vont pas jusqu'en production.
'En ce qui concerne le fait de mettre cette amélioration en perspective dans un cadre plus large ... je ne vois pas exactement ou tu veux en venir ; peux tu éclairer ma lanterne ?'
Il arrive parfois que la cause de certains problàmes dans le processus de dev, lorsqu'elle est identifié puis corrigé, permette de réaliser des gains de temps (productivité + qualité) et donc d'argent pour l'organisation concerné".
Je ne prétend pas que cela ainsi (dommage :)) pour ton client. Cependant, il est interessant d'observer quand cela fait sens comme les améliorations 'lean' (kaizen ou innovation ) influe sur l'ensemble de la production du logiciel et notamment sur le temps de cycle entre une requête d'évolution/d'ajout de feature et sa livraison au client.
Ma question est-elle plus claire ? Fait-elle sens ?
MAC
Mac,
Nous travaillions déjà en cycle court (livraison en intégration tous les jours, en recette toutes les semaines) et je ne constate pas directement de cause à effet entre cette amélioration et la durée des cycles.
En revanche cette amélioration a un effet direct sur la productivité et donc sur le nombre de fonctionnalités que nous sommes capable de livrer en un cycle (i.e. augmentation de notre vélocité, au sens agile du terme)
En ce qui concerne la qualité, je pense que cette amélioration permet sensiblement de l'améliorer car elle favorise les tests de bout en bout (en les rendant moins pénible).
A+
Christian