LEAN ET 5S

Nous sommes nombreux dans l'équipe. Suffisamment pour nous être organisé en plusieurs sous-équipes, chacune avec son tableau "kanban" et son Daily Stand-Up Meeting.

Avec la croissance des l'équipe et la multiplication des sous-équipes, il est alors devenu difficile d'assister au Daily Stand-Up Meeting d'une sous-équipe. Où et quand a lieu la réunion de telle ou telle sous-équipe?

Nous avons résolu ce petit problème de la manière suivante. Sachant que chaque sous-équipe mène son Daily Stand-Up Meeting devant son tableau "kanban", nous avons étiqueté chacun d'eux.
Sur chaque tableau, des étiquettes indiquent le nom de la sous équipe, l'horaire de son Daily Stand-Up Meeting et les prénoms des équipiers devant intervenir lors de cette réunion.

Cette petite solution toute simple rentre parfaitement dans le cadre de la pratique des 5S.

INTEGRATION CONTINUE + ANDON = JIDOKA

Nous avons configuré notre outil d'intégration continue pour qu'il envoie un mail d'alerte à chaque équipier lorsqu'un build automatisé (compilation et tests) échoue. Notre priorité est alors de revenir au plus tôt à une situation nominale caractérisée par un build réussi.

Mais voilà, notre attention n'est pas concentrée sur notre messagerie. Nous avons beau être nombreux dans l'équipe, certains builds échoués restent non détectés plusieurs heures. Il arrive également qu'un build échoué soit détecté, mais qu'il ne soit pas corrigé dans l'heure. Alors les équipiers s'inquiètent car ils ne sont pas certains que quelqu'un soit en train de résoudre le problème.

De sa propre initiative, l'équipe a décidé de se mettre la pression. Elle a réfléchi à la solution la plus simple pour mettre en place un andon. Il s'agit d'un signal lumineux visible de tous qui signale une anomalie.

Un équipier a alors acheté un i-buddy pour le poste d'intégration continue. Lorsque le build incrémental et le build complet sont tous deux réussis, la tête de l' i-buddy est verte. Si un de ces deux builds échoue, la tête de l' i-buddy est rouge. Lorsqu'un build échoué est en réparation, le tête de l'i-buddy est bleue.
La loupiote est posée sur l'écran du poste d'intégration continue. Une légende explicative attachée à l'i-buddy rend l'interprétation de son signal lumineux évidente pour tous (application du 5S) .

Cette petite initiative a plusieurs avantages:

• un signal lumineux visible de tous signale clairement les problèmes de build;
• le signal lumineux rouge, visible de tous, motive les équipiers à rapidement corriger le problème détecté;
• le signae lumineux bleu rassure l'équipe sur le fait que des équipiers se chargent du problème détecté;
  
• c'est une petite pratique sympa dont l'équipe est fière. Elle soude ses membres en contribuant à son folklore.
  

Bref, intégration continue + i-buddy = jidoka

PS: Il est de bon ton se caser quelques mots en japonais comme andon et jidoka dans son billet ;o)

LEAN, LE FLUX TIRE DE CREATION DE VALEUR

Après les billets sur une pratique de la valeur, de la cartographie du flux de création de valeur, du flux continu de création de valeur, voici la suite qui porte sur le flux tiré de création de valeur (ou "pull").

Alors que le flux continu de création de valeur est en place, il s'agit désormais de laisser le client tirer la création de valeur selon son besoin.

A ce jour, nous pratiquons le flux tiré de création de valeur à 3 niveaux.

DÉVELOPPEMENT TIRE PAR PRIORITÉ

D'abord, au plus près du client final, les exigences à implémenter sont priorisées par le Product Owner dans le Product Backlog. La succession des itérations tire les exigences par ordre de priorité hors du Product Backlog pour les transformer en logiciel opérationnel. Ainsi, en accordant une priorité à ses exigences et en laissant l'équipe de développement mener un développement itératif et incrémental piloté par les priorités, le client final est en fait en train de tirer le développement de son produit.

Nous pouvons affirmer que le développement itératif et incrémental piloté par les priorités du client final est en fait un système "pull" pour le développement de produit.

IMPLÉMENTATION TIRÉE PAR KANBAN

A un niveau plus bas, lorsqu'une itération tire une exigence prioritaire hors du Product Backlog pour l'implémenter, toutes les activités à mener pour la transformer en logiciel opérationnel sont identifiées par la Value Stream Map et tirées par un Kanban. Une étiquette du Kanban représente une exigence à implémenter. Les colonnes du Kanban sont les activités sérialisées de la Value Stream Map. Les cases à cocher dessinées sur les étiquettes sont les activités parallèlisées de la Value Stream Map. La traversée du Kanban par les étiquettes existantes est prioritaire à l'entrée de nouvelles étiquettes sur le Kanban. Le Kanban est actualisé une fois par jour, en équipe et en temps limité, lors du Daily Stand-Up Meeting. (voir la pratique en vidéo)

CODAGE TIRE PAR TEST

A un niveau encore plus bas, la pratique des tests de recette et des tests développeur conformément au développement piloté par les tests (ou TDD) est un système "pull" pour l'activité de codage. En effet, des tests qui échouent sont implémentés en premier lieu. Puis, juste assez de codage est tiré pour faire passer ces tests avec succès. Nous pouvons afirmer que le Développement Piloté par les Tests (ou TDD) est en fait un système "pull" pour l'activité de codage.

Ainsi, le flux tiré de création de valeur est pratiqué à plusieurs niveaux. Cette manière d'organiser la chronologie des développements et des activités évite les gaspillages de la surproduction, des défauts cachés dans l'inventaire et du développement d'exigences non prioritaires.

Le prochain billet consacré au Lean portera sur la recherche de la Perfection. Nous aurons alors survolé une certaine implémentation des 5 piliers du Lean.

AGILITE AU SALON DU BOURGET

Nous avons eu la chance d'être invités au Salon du Bourget. Nous avons eu le plaisir d'y voir deux porteurs pour lesquels nous avons développé des logiciels de vol en appliquant les méthodes agiles.

Ces deux logiciels ont été livrés à temps et avec la qualité attendue. Très discrètement et pour certains initiés, les méthodes agiles étaient à l'honneur au Salon du Bourget!

AGILITE ET SURETE DE FONCTIONNEMENT

Voici une annonce citant l'utilisation des démarches agiles pour le développement d'applications critiques.

Pour comprendre pourquoi ce rapprochement est pertinent, lisez les billets suivants: EXTREME PROGRAMMING EMBARQUE et MOINS CHERS ET PLUS SURS.

DOSSIER AGILE DANS [PRO]GRAMMEZ

Disponible en kiosque, le numéro 120 du magazine PROgrammez propose un dossier sur le développement logiciel Agile. Le journal y consacre une introduction et 7 articles, le tout couvrant 15 pages (sur 82).

Voici la table des matières du dossier:

• Développeur AGILE. Pour retrouver le goût du développement. (introduction du dossier)
• Les méthodes agiles pour mieux développer.
• eXtreme Programming: les fondamentaux du développeur agile.
• La journée d'un développeur agile.
• Standardiser la résolution de problèmes dans une équipe agile.
• L'agilité , une révolution culturelle.
• Vendre SCRUM à une équipe en cycle V.
• Adopter me mode agile en début d'un projet ou en cours de route.

J'ai tout particulièrement apprécié la contribution de Raphaël Pierquin (eXtreme Programming: les fondamentaux du développeur agile). Son propos est dynamique, bien vulgarisé et pédagogique. Je suis sûr que son article donne envie de s'y mettre! De plus, je trouve qu'il a le bon goût de mettre l'accent sur les pratiques techniques. Sans son article, le dossier aurait été bancal, traitant essentiellement de la partie visible et organisationnelle de l'agilité. C'est d'ailleurs un choix étonnant pour le magazine PROgrammez dont la cible est pourtant le programmeur.

Je trouve que le dossier contient quelques maladresses, donnant trop d'importance à mon goût aux outils et aux fameuses "usines logicielles". On lit aussi un étonnant énoncé des différences entre Scrum et les autres méthodes agiles. Étant donné les arguments choisis, je pense que cela révèle simplement un manque de connaissance et de pratique d'XP. Personnellement, je ne vois pas ce que Scrum apporte par rapport à XP sur le fond. Pour moi, l'apport est sur la forme avec une plus claire formalisation des rôles, artefacts et cérémonies. J'ai aussi été surpris de voir UP catalogué parmi les démarches agiles. Ceci dit, on doit pouvoir se conformer aux valeurs et principes du Manifeste Agile avec un processus UP bien adapté.

Accessoirement, j'ai aussi été agréablement surpris de reconnaitre un Sprint Burndown Chart de notre projet à la Figure 4 de la page 28. Après tout, si les photos sont en ligne, c'est bien pour qu'elles servent!

Bref, à part quelques critiques mineures, j'ai apprécié l'initiative et la lecture de ce dossier. Aussi, j'en déduis qu'on prend les pratiques techniques très au sérieux chez Pyxis. Je ne suis pas étonné.

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!