LEAN, LE FLUX CONTINU DE VALEUR

Voici le 3ème billet consacré au développement logiciel Lean. Après un premier billet dédié à la valeur et un deuxième traitant la cartographie du flux de valeur, celui-ci décortique le flot continu de valeur.

DE QUOI S'AGIT T-IL?

Il s'agit d'enchainer toutes les étapes créatrices de valeur en un flux continu et rapide.

ALIMENTONS LE FLUX!

En s'inspirant des réseaux informatiques et des autoroutes, nous réduisons la taille des lots de travail pour alimenter un flux continu. Dans cette optique, nous avons adopté le rythme mensuel de Scrum, le Sprint.

Chaque Sprint est une itération qui produit un incrément potentiellement livrable de produit. Un tel développement itératif et incrémental en cycles courts et réguliers alimente un flux continu de travail.

Aussi, nous alimentons un flux continu d'information au sein de l'équipe en partageant tous un même espace de travail. Nous utilisons le contrôle visuel pour révéler les problèmes. En effet, notre espace de travail est décoré de Kanbans qui identifient les goulets d'étranglement, de Burndown Charts qui mesurent l'avancement et de Blocking Boards qui exposent les problèmes.

Ensuite, le flux continu est maintenu en éliminant les problèmes qui le ralentissent.

MANITENONS LE FLUX!

Les désynchronisations ralentissent le flux de travail. Les développeurs consacrent du temps à synchroniser le produit avec leurs modifications (intégrer) et à synchroniser les activités des équipiers (s'organiser). Ces deux sources de désynchronisations sont minimisées par deux pratiques agiles. D'abord, l'intégration continue alimente un flux régulier de logiciel testé, intégré et potentiellement livrable. Ensuite, la courte réunion quotidienne d'avancement maintient un travail d'équipe synchronisé. Par de petites et régulières synchronisations, ces deux pratiques éliminent les lourds efforts de synchronisation. Ainsi, le produit et l'équipe se désynchronisent aussi peu que possible.

Les bugs ralentissent le flux de travail. Nous gaspillons du temps à corriger des bugs que nous avons injectés dans notre produit. Afin de minimiser l'impact des défauts sur la cadence, nous avons adopté une attitude préventive envers les bugs. Le développement piloté par les tests permet de prévenir les défauts. Les tests étant écrits avant le code à tester, ils empêchent l'introduction des défauts à priori au lieu de les détecter à postériori comme c'est le cas lors de phases de tests. De même, la programmation en binôme évite l'introduction des défauts à priori car le code est relu avant d'être livré. Aussi, la programmation par contrat permet d'écrire du code détrompé puisqu'il est impossible d'utiliser le code autrement que conformément à ses préconditions. Enfin, les modifications de code ne peuvent être livrées vers la référence du code que si les tests passent avec succès.

Malheureusement, malgré ces pratiques, des bugs parviennent tout de même à s'infiltrer dans le produit. Alors, pour conserver un flux régulier de travail fini, nous pratiquons le Stop The Line. La détection des défauts est automatisée et elle entraine l'arrêt du travail. La priorité de l'équipe est alors de corriger le défaut détecté. Dans cette optique, notre outil d'intégration continue construit l'application et joue les tests dès qu'une modification est détectée dans la référence du code. Si la compilation ou les tests échouent, une alerte est automatiquement envoyée par mail à tous les équipiers. Notre priorité est alors de réparer le produit. Le build automatisé, les tests et les assertions dans le code sont les détecteurs de défauts. Cette pratique créé une culture de travail où les équipiers s'arrêtent pour corriger les problèmes.

EN BREF

Notre développement itératif et incrémental en cycles courts et notre pratique de l'intégration continue alimente un flux régulier de travail. Ce flux régulier et rapide expose des problèmes. Le flux est alors maintenu en s'arrêtant pour corriger les problèmes exposés.

Un quatrième billet sur le Lean sera consacré au flux tiré de valeur. A bientôt!