RESOUDRE LES PROBLEMES

C'est bien bien sympa de voir les problèmes. Ceci dit, l'objectif reste de les résoudre!

Alors, ces problèmes identifiés et exposés à la vue de tous, sont-ils traités?

1. PETIT RAPPEL

Rappelez-vous: l'équipe prend conscience que pour apprendre, progresser et gagner en efficacité, elle doit résoudre systématiquement les problèmes qu'elle rencontre.
Alors,

• on développe la détection systématique des problèmes;
• on affiche les problèmes pour les rendre visibles;
• on résout les problèmes de manière structurée.

Cette attitude et cette démarche sont décrit dans un précédant billet.

2. EST-CE PRATIQUÉ?

Afin de s'assurer que ces beaux principes sont devenus des pratiques, nous affichons un indicateur révélant le nombre de problèmes résolus (le bas des barres) et le nombre de problèmes non-résolus (le haut des barres). Cet indicateur est actualisé à chaque itération (voir photo ci-dessus).

3. EST-CE EFFICACE?

C'est bien joli de mettre en place de nouvelles pratiques - encore faut-il qu'il y ait un retour sur investissement ... Et là, il faut reconnaître qu'il est difficile de mesurer l'impact de la résolution systématique des problèmes.

Difficile n'est pas impossible: les burndown-chart et la courbe de non-qualité révèlent les gains en productivité et en qualité de cette démarche.
Notamment, la courbe de non-qualité révèle de sévères réductions de la non-qualité correspondant à des chantiers mis en place suite à un problème levé. Ensuite, les paliers qui suivent une chute de cette courbe montrent que l'action corrective "coup de poing" s'est efficacement transformée en pratique continue.
Puisque le burndown-chart ne souffre pas d'une augmentation ou d'une stagnation du "restant à faire", c'est que la résolution du problème a contribué positivement au développement.

4. EFFET SECONDAIRE

Nous avons remarqué un autre effet secondaire bénéfique de cette démarche. Il s'agit d'une très forte augmentation de la standardisation.
En effet, la résolution d'un problème résulte généralement en:

• une contre mesure automatisée (scriptée dans le build, dans le commit, ...);
• une contre mesure manuelle décrite par une petite procédure textuelle;
• l'amélioration d'une procédure existante.

Ainsi, nous avons constaté que notre wiki s'est enrichi de beaucoup de petites procédures pragmatiques. Il s'agit de l'officialisation des meilleures manières de faire à ce moment pour ce projet. Cela constitue un standard léger et évolutif, partagé par les équipiers.

Je pensais que la standardisation étaient une démarche formelle, lourde et ralentissant l'évolution. Je suis désormais convaincu du contraire.

VOIR LES PROBLEMES

"Loin des yeux, loin du cœur". Un problème qui n'est pas visible n'est pas traité.

Sur les conseils de Régis Médina et après avoir assisté à sa conférence présentée à l'Agile Tour à Valence, nous cherchons depuis quelques itérations à rendre nos problèmes visibles pour ne pas les laisser trainer. Pour cela, nous avons mis en place 2 pratiques.

1. VOIR LES DÉFAUTS DU PROCESSUS

La première, déjà évoquée à l'occasion d'un billet sur la résolution systématique des problèmes consiste à afficher sur un tableau dédié les problèmes rencontrés par l'équipe (voir photo).

2. VOIR LES DÉFAUTS DU PRODUIT

La deuxième consiste à identifier, mesurer et afficher quotidiennement et automatiquement la non-qualité du produit. Il s'agit de la somme de tout ce qui est à corriger pour atteindre le niveau de qualité que nous recherchons pour notre produit (et nous sommes TRÈS exigeants).
Ainsi, nous sommons

• le nombre de warnings de compilation du code et des tests,
  
• le nombre d'opérations qui dépassent un seuil de complexité,
  
• le nombre de classes non couvertes à 100% par des tests automatisés,
  
• le nombre de classes qui ne respectent pas les standards de codage ...

L'historique de cette métrique enrichie une courbe qui est affichée quotidiennement à l'endroit le l'open space où il y a le plus de passage, juste à côté des burndown charts.

Depuis que nous avons décidé de rendre visibles ces problèmes, nous nous sommes mis de manière disciplinée et continue à réduire cette non-qualité, comme le révèle la courbe affichée.

Dès que la courbe se stabilise à un niveau acceptable de non-qualité (correspondant à un minimum de travail en cours) nous enrichissons cet indicateur d'une nouvelle classe de défauts. Vous verrez un tel saut commenté à la main sur la courbe affichée. Ainsi, nous relevons notre niveau d'exigence de manière maitrisée.

Nous ne nous intéressons pas à la valeur de la métrique mais plutôt à la pente de la courbe. En effet, elle révèle très clairement si l'équipe s'améliore ou se relâche.

Il est très intéressant d'afficher cette courbe de non-qualité à côté des burndown charts. En effet, on constate souvent que l'amélioration de la productivité (visible sur un burndown chart) se fait au détriment de la qualité (visible sur la courbe de non-qualité). L'affichage quotidien et côte à côte de ces 2 courbes permet de visualiser que nous ne jouons pas aux vases communicants. Mieux, nous arrivons même à corréler que travailler mieux permet de travailler plus vite!

Enfin, nous avons aussi valorisé cette mesure de la non-qualité du produit. A chaque catégorie de défaut identifié nous avons associé une valeur: il s'agit du temps théorique requis pour corriger un défaut de cette catégorie. Ainsi, nous mesurons le temps estimé nécessaire pour obtenir un produit de la qualité recherchée.

Avec la mesure quotidienne et combinée du restant à faire et de la non-qualité du produit, nous avons des outils objectifs, pertinents et complémentaires pour piloter notre développement.

RECRUTE EQUIPIER

Nous cherchons un équipier pour un CDD d'un an. Si vous êtes mobile pour venir sur Valence et que vous souhaitez intégrer un grand projet industriel, cette opportunité pourrait vous intéresser.

Sincèrement, je pense que notre projet est une bonne école du génie logiciel. Nous exigeons un niveau de qualité maximal, convaincus que bien développer le bon produit permet de développer plus vite. Nous pratiquons l'eXtreme-Programming, Scrum, le Lean, la démarche orientée objet et la programmation par contrat.

Si vous êtes tentés par cette aventure enrichissante techniquement et humainement, l'offre est accessible via l'APEC ici. Si vous voulez en savoir plus sur notre équipe, on en parle sur d'autres blogs, tels celui d'Alexandre Boutin.

A bientôt?

THE TOYOTA WAY, JEFFREY K. LIKER

Après avoir lu plusieurs livres sur le Lean appliqué au développement logiciel, tels Lean Software Strategies, Implementing Lean Software Development et Lean Software Development, j'ai eu besoin de pousser plus loin ma compréhension de cette philosophie pour aider à sa pratique sur notre projet.
En insistant que le Lean s'apprenait par la pratique avec un mentor praticien et non dans les livres, Régis Médina m'a tout de même conseillé la lecture de The Toyota Way.

Le Toyota Way est la philosophie de gestion pratiquée par Toyota. Elle est structurée en 4 parties: la philosophie à long terme, le processus, collaborateurs et partenaires et la résolution des problèmes.

Nos années de pratique de l'eXtreme Programming, de Scrum et du Lean Software Development nous ont conduit à mettre l'accent sur l'aspect processus du Lean. Notre pratique s'appuie essentiellement sur les nombreux outils du Lean, tels le flux continu, le kanban, le jidoka, les andon, le heijunka, le management visuel, etc. Le dernier billet de Régis Médina révèle que nous ne représentons pas un cas isolé.

La lecture du Toyota Way nous a permis de comprendre que nous avions - non pas négligé - mais plutôt sous-estimé - les 3 autres facettes: la philosophie à long terme, les collaborateurs et les partenaires et la résolution des problèmes.

En réaction, nous sommes actuellement en train de travailler sur la résolution des problèmes. Sur ce thème, nous travaillons actuellement sur plusieurs axes en parallèle:

1. Rendre visibles les problèmes de l'équipe (voir billet);
   
2. Mettre en place une résolution systématique et structurée des problèmes (voir billet) ;
3. Animer régulièrement des chantiers d'amélioration de type Kaizen (billet à venir!);
4. Avec des praticiens qui enseignent le métier, pratiquer un leadership de terrain (billet à venir!).

A bientôt pour les billets annoncés!

AGILE TOUR 2009 VALENCE - C'EST FINI!

Cette année, pour l'édition 2009 de l'Agile Tour à Valence, nous avons reçu 150 participants représentant un peu plus de 40 organisations. Grâce aux intervenants et aux sponsors, nous avons accueilli plus de monde que l'année dernière autour du thème du développement agile.
Quelques blogueurs parlent de l'évènement, tout comme:

• Emmanuel Hugonnet,
• Alexandre Boutin et
• Florian Villoing.

Les présentations sont consultables en ligne sur le site du CARA.

En assistant à des conférences, on ramène toujours au moins une piste à explorer. Cette année, notre équipe à déjà commencé à mettre en pratique plusieurs idées recoltées à l'Agile Tour Valence:

• Rendre visibles les problèmes de l'équipe. Je consacrerai un billet à ce seul sujet.
• Valoriser la dette technique: de manière automatisée, la partie visible de la dette technique du projet est mesurée, puis estimée en heures de correction.
• Nos pratiques de résolution systématique des problèmes et d'amélioration continue n'ont pas toujours un impact visible sur nos indicateurs d'avancement (burndown et vélocité). Une explication consiste à conclure que ces pratiques sont inefficaces. Une autre explication consiste à supposer que notre panel d'indicateurs est inapproprié pour détecter l'effet de ces améliorations. Nous avons alors complété nos indicateurs de pilotages par 2 métriques révélant l'efficacité de nos pratiques d'amélioration continue. Je consacrerai également un billet à ce seul sujet.

A bientôt pour le détail de nos nouvelles pratiques.

PROGRAMME DE L'AGILE TOUR 2009 VALENCE

Voici en avant première le programme l'étape de Valence de l'Agile Tour 2009.

Cette année, Valence accueillera 14 orateurs qui animeront 12 sessions dans 4 salles. Cela représente 16 heures d'interventions dont 50% d'ateliers.

Cette année, 6 heures de sessions seront consacrées au Lean.

Les sessions sont organisées pour offrir 4 heures de sessions aux participants selon 3 profils type:

• novice en agilité;
  
• manager / décideur / chef de projet;
• développeur praticien.

Pour participer, l'inscription est gratuite et obligatoire. Venez nombreux en vous inscrivant ici.
A très bientôt!

VENEZ A L'AGILE TOUR A VALENCE

Venez nombreux à Valence assister aux conférences et participer aux ateliers de l'Agile Tour 2009.

L'évènement aura lieu le Jeudi 22 Octobre 2009 dans les locaux de l'IUT de Valence, de 13h à 18h.
Comme l'année précédente, l'évènement est gratuit et sera suivi d'un apéritif.

Cet évènement est la deuxième édition de la conférence itinérante sur les méthodes Agiles (eXtremeProgramming, Scrum, Lean ...). En 2008, l'évènement a rassemblé à Valence 120 participants, professionnels, enseignants et étudiants représentant les principaux industriels, sociétés de services en informatique et écoles de la région.

En particulier cette année, si vous êtes intéressés par le Lean, l'eXtreme Programming, le pilotage par les tests (TDD), la contractualisation des forfaits agiles, le management agile ou le CMMi, venez nous rejoindre le Jeudi 22 Octobre après-midi.

Pour faciliter l'organisation, l'inscription est obligatoire en remplissant le formulaire ici. Pour toute question, n'hésitez pas à nous contacter par mail.
A très bientôt!

LEAN, LA CULTURE

A travers 5 billets, nous avons balayé un jeu de pratiques de développement logiciel permettant d'implémenter les 5 piliers du Lean:

• la définition de la valeur,
• la cartographie du flux de création de valeur,
• le flux continu de création de valeur,
• le flux tiré de création de valeur et
• le perfectionnement.

A travers d'autres billets nous avons vu encore d'autres pratiques toujours relatives au Lean contribuant:

• au jidoka,
• au Stop The Line,
• au poka-yoke et
• aux 5S.

Une pratique quotidienne de ces outils et une attitude d'amélioration continue de tous les les jours ne suffit malheureusement pas pour devenir une organisation Lean. Au mieux, cela développe des îlots Lean.

Attention, c'est déjà beaucoup! Mais il est possible d'aller beaucoup plus loin si on relie ces îlots, si on leur donne du sens et si on assure une continuité par une culture d'entreprise appropriée.

Pour assurer la continuité des pratiques et réellement promouvoir l'amélioration continue, il faut une culture d'entreprise qui exige la prise de décision en se basant sur des objectifs à long terme. Le pilotage au jour le jour et au gré des tempêtes ne donne pas le temps de progresser par la pratique.

Pour donner du sens à ces pratiques et pour justifier leur adoption, il faut une culture d'entreprise connue des équipes. Les pratiques et l'attitude qui va avec sont d'autant plus facilement adoptées si les équipes comprennent en quoi cela sert leurs clients, leur entreprise et leur développement personnel.

Pour qu'une telle culture d'entreprise soit connue des équipes, il faut qu'elle soit enseignée. Il est de la responsabilité des managers d'être des leaders qui pratiquent et enseignent la culture à leurs équipes. Pour cela, ces leaders doivent être sur le terrain, connaître le métier et enseigner le métier par l'exemple en se référant à la culture d'entreprise qui justifie la manière de le pratiquer. Dans une telle dynamique, les leaders deviennent des praticiens de la résolution systématique des problèmes pour aider leurs équipes à devenir plus productives et les aider à tenir leurs objectifs.

Alors, avec des pratiques solidement enracinées dans une culture d'entreprise, elle-même enseignée par des leaders praticiens, il devient envisageable de relier les îlots Lean pour développer une organisation Lean.

ET MAINTENANT?

Au boulot!

LEAN, LA PERFECTION

Après la définition de la valeur, la cartographie du flux de création de valeur, le flux continu de création de valeur, et le flux tiré de création de valeur, le dernier pilier du Lean est la perfection.

DE QUOI S'AGIT-IL?

Il s'agit de l'amélioration continue des pratiques de travail par la résolution systématique des problèmes.
Utiliser le mot perfection pour nommer ce dernier pilier est maladroit. En effet, la perfection n'est jamais atteinte et il est toujours possible d'améliorer. Plutôt que perfection, il vaudrait peut être mieux parler de perfectionnement.

QUELLES PRATIQUES?

Je trouve qu'il s'agit du principe le plus difficile à transformer en pratiques de travail. La lecture de The Toyota Way m'a fait réaliser que j'avais largement sous estimé l'implémentation de ce principe. Voici où nous en sommes:

Les rétrospectives

Chaque itération d'un mois se termine par une réunion en équipe complète appelée rétrospective. En se basant sur des métriques, des faits marquants et des impressions, les équipiers identifient les principaux problèmes rencontrées dans l'itération et cherchent des contre mesures à expérimenter dans la prochaine itération pour les résoudre. Ce travail périodique permet de régulièrement prendre du recul sur notre manière de travailler pour s'améliorer.

Notre pratique de la rétrospective d'itération contribue au perfectionnement des pratiques de travail, mais je ne pense pas qu'elle suffise. En effet, les problèmes identifiés tout au long de l'itération attendent la rétrospective pour être sérieusement évoqués en équipe. Ainsi, en attendant la rétrospective, l'équipe aura contourné ces problèmes en perdant en efficacité. Pire, certains des problèmes identifiés tôt dans l'itération auront empiré en attendant la rétrospective en fin d'itération. Les contre mesures demanderont alors plus d'effort. Pire encore, certains problèmes ne sont même pas traités en rétrospective car l'équipe fatigue en fin d'itération (ne me parlez pas de rythme soutenable) ou certains problèmes semblent trop petits pour être traités à 20 équipiers. Dans ce cas, on ne peut réellement parler d'amélioration continue. Nous cherchons donc à compléter la rétrospective d'itération par une autre pratique, plus régulière.

La résolution systématique des problèmes

La lecture de The Toyota Way nous a conduit à expérimenter une approche systématique et structurée de résolution de problème. Nous parions que cette démarche nous permettra d'optimiser nos pratiques au quotidien et en continue en résolvant les problèmes de manière systématique dès qu'ils sont identifiés.
Nous sommes actuellement en train de construire notre pratique de travail. Pour le moment, les équipiers rédigent une fiche dès qu'ils identifient un problème. Cette fiche datée synthétise:

• la description du problème constaté;
• le résultat de la recherche de la cause racine du problème;
• autant de cycles Plan, Do, Check, Act qu'il en faut pour faire disparaitre ce problème et l'empêcher de se présenter à nouveau.

Lorsqu'un problème est résolu par cette approche structurée, sa fiche cartonnée est conservée car elle sera réutilisée et enrichie si jamais le problème revient malgré les contre mesures mis en place. Certaines fiches ressortiront plusieurs fois et révèleront les problèmes récurrents.
Puisque le management visuel sert à ne pas cacher les problèmes, les fiches cartonnées sont affichées sur un tableau baptisé "Problem Solving" (voir photo). Ainsi, n'importe quel équipier peut présenter les problèmes actuels à un manager.
En quelque sorte, cette pratique est au défaut de processus ce que le Stop The Line est au défaut de produit.

Cette démarche présente de nombreux avantages:

• elle contribue à entretenir une amélioration continue des pratiques de travail;
• elle contribue à créer un état d'esprit où les équipiers identifient les problèmes et arrêtent leur travail en cours pour les résoudre afin d'optimiser la création de valeur;
• elle donne des faits pour comprendre les difficultés rencontrées par l'équipe;
• elle rend visibles les problèmes de l'équipe;
  
• elle permet d'identifier les problèmes récurrents dont la résolution est stratégique pour la réussite du projet;
• elle implique les managers de manière constructive dans le travail de l'équipe puisque la résolution de certains problèmes est hors de portée de celle-ci;
  
• elle aide l'équipe à devenir une organisation qui apprend à mieux travailler.

Cette pratique est aussi très difficile à mettre en place. En effet, il faut développer l'état d'esprit de l'identification et de la résolution systématique de problèmes chez les équipiers (à commencer par soi-même!). Il s'agit d'une attention de tous les jours. Il faut aussi et surtout convaincre les managers qu'il est important d'arrêter le travail en cours pour résoudre les problèmes qui freinent la productivité ou réduisent la qualité. Cela peut s'avérer très difficile si les décisions n'ont pas l'habitude d'être prises en se basant sur des objectifs à long terme.

ET MAINTENANT?

Cette petite série de billets sur notre implémentation des 5 piliers du Lean est désormais close. Néanmoins, la pratique quotidienne des outils présentés dans ces 5 billets m'amène à en rédiger bientôt un 6ème. Il sera dédié à un atout qui me semble primordial pour devenir une organisation Lean: la culture d'entreprise.

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!

2 ANTIPATTERNS DE BINOMMAGE

Nous pratiquons le Pair Programming. Pas 100% du temps, mais le plus possible.

Nous pilotons nos activités avec un Kanban. Chaque étiquette du Kanban est un post-it sur un tableau. Chaque post-it représente une tâche à mener. Sur ces post-it, nous nommons les équipiers qui participent à sa réalisation.

En surveillant la liste des équipiers sur les post-it, nous avons pu identifier 2 antipatterns de Pair Programming. Il en existe bien plus, mais ceux là nous amusent bien.

A + B - B, ou le "Ca pue, je me casse"

Nico est le premier assigné à une tâche. ManU vient binommer avec Nico. Après quelques heures, ManU trouve une tâche plus prioritaire à mener. En fait, après avoir vu ce sur quoi travaillait Nico, ManU s'est mis en tête de trouver une tâche plus prioritaire. Il s'agit d'une manière agilement correcte de dire "Ta tâche pue, je me casse!".

A + B - A, ou le "Je te délègue ma bouse"

ManU est le premier assigné à une tâche. Nico vient binommer avec ManU. Après quelques heures, ManU trouve une tâche plus prioritaire à mener. Il s'agit d'une manière agilement correcte de dire "Je te délègue ma bouse!".

Les patterns sont un langage de travail

Désormais, dans notre open space, nous entendons des développeurs se dire: "Mais, tu ne serais pas en train d'essayer de me faire un A + B - A?".

Pas très agile tout ça

Certains extrémistes s'évertueront à dénoncer qu'il s'agit de manquements aux valeurs, principes et pratiques de l'agilité. C'est vrai, mais parfois nous sommes aussi des hommes. Et puis on se marre bien dans l'équipe ;o)

AGILITY AND LEAN FOR AVIONICS, EN VIDEO

Voici la vidéo de ma conférence donnée chez AdaCore à l'occasion de l'évènement The Lean, Agile Approach To High-Integrity Software. La vidéo est en quatre parties.

Partie 1 sur 4:


Partie 2 sur 4:


Partie 3 sur 4:


Partie 4 sur 4:


Les slides de la présentation sont disponibles ici et l'article ayant servi à préparer la conférence est consultable ici.

Les vidéos ont initialement été mis en ligne sur le site OPEN-DO. Vous y trouverez les vidéos des autres présentations de l'évènement.

LA CHUTE

J'aime bien quand on rit de l'agilité. C'est agréable de ne pas se prendre au sérieux. L'analogie n'est pas heureuse, mais j'ai adoré ce détournement. Le son est obligatoire même s'il n'apporte aucune information.

L'INTÉGRATION CONTINUE EST UN SYSTÈME MULTITACHE

Ce billet est consacré à une pratique de l'intégration continue et au parallèle que nous pouvons dresser entre le développement concurrent avec intégration continue et les systèmes multitâches.

3 IDÉES

• Je vais commencer par vous expliquer comment nous pratiquons une forme sécurisée de l'intégration continue.

• Ensuite, j'évoquerai un problème propre à l'intégration continue et je présenterai les solutions que nous avons mis en place pour y remédier.

• Enfin, pour illustrer mon propos je ferai un parallèle entre développement concurrent avec intégration continue et les systèmes multitâches.

INTÉGRATION SÉCURISÉE

Pour qu'un développeur de notre équipe contribue au projet en délivrant ses travaux, il utilise un script qui automatise les activités suivantes:

1. Identification des modifications: Il s'agit du "commit" ou "checkin" des fichiers modifiés de l'espace personnel de travail. Un éditeur texte est ouvert pour que le développeur justifie ses modifications.
2. Synchronisation de l'espace personnel: L'espace personnel de travail est synchronisé par rapport à la référence du code en y important les nouveautés de la référence du code.
   
3. Build et test de l'espace personnel: Le build est lancé et l'intégralité des tests xUnit sont exécutés dans l'espace personnel. Cette étape s'assure que les modifications du développeur sont compatibles de la référence du code.
4. Synchronisation de la référence: Si le build et tous les tests ont réussi, alors les modifications de l'espace personnel sont délivrées dans la référence du code.
5. Build et test de la référence: En moins d'une minute, l'outil d'intégration continue détecte la modification de la référence du code et lance un build incrémental avec rejeu de tous les tests xUnit. En général, le défaut type détecté par cette étape est un nouveau fichier source introduit dans le produit par le développeur et non géré par l'outil de gestion des versions.
   

Il s'agit d'une démarche de contribution sécurisée car le développeur ne peut délivrer des modifications incompatibles avec la référence du code. En effet, l'étape 3 interdit la livraison des modifications si le build ou le test de la version intégrée échoue. La référence du code est donc protégée contre l'injection de défauts.
Cette synchronisation est fluide car elle est automatisée et courte. Elle ne dure que de 2 à 3 minutes environ. Ainsi, chaque développeur se synchronise plusieurs fois par jour pour entretenir une intégration continue du produit en développement.

INTÉGRATION CONTINUE OU INTÉGRATION PERPÉTUELLE?

Néanmoins, il existe un point faible dans cette démarche, entre l'étape 2 et l'étape 4. Pour le comprendre, analysons le scénario suivant.
Supposons que Jacques et Paul soient deux développeurs de notre équipe. Jacques a terminé une étape de son travail et souhaite la délivrer dans la référence du code. Il lance le script d'intégration. A l'étape 2, il a récupéré chez lui les nouveautés de la référence du code. Il en est à l'étape 3: les tests sont en cours d'exécution dans son espace personnel.
Il se trouve que Paul avait commencé une synchronisation quelques minutes ou secondes avant Jacques. Alors que Jacques en est encore à l'étape 3, Paul en est déjà à l'étape 4: il délivre le résultat de son travail dans la référence du code.
Maintenant, c'est au tour de Jacques de passer à l'étape 4 et de délivrer son travail. Mais la référence du code a changée car elle a été enrichie des travaux de Paul. Donc, Jacques vient de finir son intégration et pourtant il n'est déjà plus synchronisé avec le version de référence du code! Il ne peut donc pas délivrer son travail et il doit reprendre son intégration depuis le début, à l'étape 1.

Ce petit scénario n'est pas bien grave. Jacques n'a perdu que 3 minutes. Maintenant, comprenez que notre équipe est composée de plus de 15 développeurs qui se synchronisent plusieurs fois par jour. Ce scénario de collision a donc une forte probabilité d'occurrence et l'intégration de Jacques peut durer des heures. Pour Jacques, l'intégration continue est devenu une intégration perpétuelle.

LE PROBLÈME

Nous nous sommes rendu compte qu'un seul développeur de l'équipe peut intégrer à la fois. L'intégrateur doit bénéficier d'un accès exclusif à la référence du code pour intégrer ses travaux sans être perturbé par les modifications d'autres développeurs. L'outil de gestion de configuration de gère pas cette exclusion mutuelle car l'intégration est composée de plusieurs commandes atomiques de gestion de versions.

GIZMO, OU L'EXCLUSION MUTUELLE EN INTÉGRATION

Depuis plusieurs projets, nous avons décidé de régler ce problème à l'aide d'une simple peluche, baptisée Gizmo par l'équipe. Pour intégrer ses travaux, un développeur doit poser cette unique peluche sur son écran. A la fin de sa synchronisation, il libère la référence du code en retirant le Gizmo de son moniteur. Ainsi, nous avons très simplement organisé l'intégration exclusive des travaux dans la référence du code.
Il se trouve que la pratique du Gizmo a deux autres bénéfices très importants expliqués en détail dans la description de nos pratiques d'équipe.

LE VERROU NUMÉRIQUE D'INTÉGRATION

La pratique du Gizmo suffit pour assurer l'exclusion mutuelle des développeurs en intégration dans le cas où l'équipe partage le même bureau. En effet, il faut visualiser où est Gizmo et pouvoir le prendre. Or, certains (rares) contributeurs à notre projet ne sont pas dans notre open-space. Nous avons alors décidé de doubler la peluche Gizmo par un verrou numérique. La séquence automatisée par le script d'intégration est donc devenue:

1. [Nouveau] Recherche du verrou. Si la référence du code est verrouillée en intégration, la séquence est interrompue et on demande au développeur d'intégrer plus tard;
2. [Nouveau] Verrouillage de la référence du code.
   
3. Identification des changements;
4. Synchronisation de l'espace personnel;
5. Build et test de l'espace personnel;
6. Synchronisation de la référnce du code (si les tests ont réussi!);
7. [Nouveau] Libération du verrou;
8. Build et test de la référence du code par l'outil d'intégration continue.
   

Le verrou est un simple fichier créé et supprimé dans la référence du code. Ce verrou numérique ne remplace pas pour autant le Gizmo en peluche. En effet, l'utilisation de la peluche présente deux autres bénéfices très intéressants (se référer à la description de nos pratiques d'équipe).

DÉVELOPPEMENT CONCURRENT AVEC INTÉGRATION CONTINUE ET SYSTÈME MULTITACHE

Pour comprendre la nécessité d'un verrou d'intégration, il suffit de faire un parallèle avec la programmation concurrente et les systèmes miltitâches.

Une équipe qui pratique le développement concurrent est un système multitâche. En effet, chaque développeur (ou binôme) est assimilable à un thread concurrent qui mène ses activités en parallèle des autres.

Si les développeurs pratiquent l'intégration continue, alors ils se partagent une ressource. Il s'agit de la référence du code. La séquence de synchronisation avec la référence (étapes 1 à 4) est donc une section critique. Un seul développeur à la fois doit la dérouler. Puisqu'il s'agit d'une section critique, il convient d'en assurer une utilisation exclusive à l'aide d'un mécanisme d'exclusion mutuelle, comme les mutex ou les sémaphores. La peluche baptisée Gizmo ou le verrou numérique sont en fait un sémaphore (à un jeton) tel qu'il en existe dans les OS temps-réel pour gérér l'exclusion mutuelle des thread dans les sections critiques.

Autrement dit:

Les développeurs sont les threads concurrents, la référence du code est la ressource partagée, la séquence d'intégration est la section critique et le verrou d'intégration est le mutex. Le développement avec intégration continue est un système multitâche.

Une fois que ce parallèle est admis, alors les règles de la programmation concurrente s'appliquent également pour l'intégration continue. En effet, le temps passé en section critique doit être aussi court que possible car une section critique est un goulet d'étranglement. La pratique de l'exclusion mutuelle en intégration créé une file d'attente d'intégration qui peut pénaliser les travaux si la durée d'intégration est longue ou si l'équipe est nombreuse.

COMMENT FONT LES AUTRES ÉQUIPES?

Je m'étonne toujours de constater que d'autres équipes (même chez nous) ne semblent pas être confrontées à ce problème. Cela n'est pas une question de taille de l'équipe car nous avons instauré cette pratique pour la première fois lors d'un projet développé à 4 développeurs organisés en 2 binômes. Ce problème me semble indissociable du développement concurrent avec intégration continue.
Alors, comment faites-vous?

CLEAN CODE, ROBERT C. MARTIN

J'avais énormément appris en lisant le précédant livre d'Uncle Bob, Agile Software Development: Principles, Practices and Patterns. Son catalogue des principes avancés de conception objet et ses métriques de couplage ont été une aide pour développer mieux.

Autant dire que j'attendais le livre suivant Clean Code, traduit en français sous le titre Coder Proprement.

Malheureusement, j'ai été déçu. Le livre est bien, mais j'ai appris bien moins qu'avec le précédant. Aussi, les chapitres rédigés par différents auteurs sont assez irréguliers en qualité. Voici la synthèse de ce qui m'a plu et de ce que j'ai appris.

QUELS SONT LES CRITÈRES DE QUALITÉ D'UN BON CODE?

Voici la définition qu'en donne l'eXtreme Programming:

Par ordre de priorité, le bon code respecte les critères suivants:

1. Il passe ses tests;
2. Il ne contient pas de redondance;
3. Il est explicite;
4. Il est minimal.

Malheureusement, l'auteur insiste peu sur le fait que les critères 3 et 4 peuvent être contradictoires et que l'ordre des priorités entre ces deux critères est très important. En effet, un code explicite tend à être plus modulaire et à être découpé en petites classes ayant chacune une seule responsabilité et en courtes opérations ayant un seul niveau d'abstraction. Ceci amène à plus de déclarations et donc à plus de code, ce qui s'oppose au critère 4.
D'ailleurs, dans tous les exemples de remaniement du livre, on constate que le code remanié est toujours 2 fois plus volumineux que le code d'origine! Cela ne me choque pas, mais je pense qu'il est important de le souligner clairement.

LIRE ET ÉCRIRE

Nous passons plus de temps à lire du code qu'à en écrire. En rendant le code facile à lire, nous le rendons plus facile à écrire.

LA RÈGLE DU BOY SCOUT

Lorsque nous ouvrons un fichier de code source, nous devons le laisser plus propre que nous l'avons trouvé.

LA LIGNE VIDE

Une opération ne doit pas contenir de ligne vide. Une ligne vide dans une opération sert à aérer son code en regroupant les instructions contribuant à une même action. Une ligne vide est donc un indice indiquant que l'opération passe à autre chose et qu'il y a plusieurs niveaux d'abstraction au sein de la même opération.
Alors, il plus cohérent d'exporter chaque groupe d'instructions contribuant à une même action dans une nouvelle opération nommée selon cette action et à appeler cette nouvelle opération dans l'opération d'origine. Ainsi, il ne reste dans l'opération d'origine que des instructions d'un même niveau d'abstraction.

LIRE LE CODE D'UNE OPÉRATION

Les étapes d'une opération doivent se trouver à un même niveau d'abstraction en dessous du nom de l'opération. Le code d'une opération bien écrite doit pouvoir se lire de la manière suivante:

POUR nom_de_l_opération IL FAUT première_étape_de_l_opération PUIS deuxième_étape_de_l_opération PUIS troisième_étape_de_l_opération PUIS ...

Les différentes étapes de l'opération sont des instructions du langage de programmation ou des appels d'opérations d'un même niveau d'abstraction.

CLASSES ET STRUCTURES DE DONNÉES

Depuis quelques projets, nous remarquons qu'il semble par endroit plus adapté d'écrire un code procédural plutôt qu'un code orienté objet. Est-ce une hérésie? Le constat suivant d'Uncle Bob m'a beaucoup rassuré.

Un code procédural (un code qui utilise des structures de données) facilite l'ajout de nouvelles fonctions sans modifier les structures de données existantes. Un code orienté-objet facilite l'ajout de nouvelles classes sans modifier les fonctions existantes.

Un code procédural complexifie l'ajout de nouvelles structures de données car toutes les fonctions doivent être modifiées.
Un code orienté objet complexifie l'ajout de nouvelles fonctions car toutes les classes de l'arbre d'héritage doivent être modifiées.

Par conséquent, ce qui est difficile pour l'orienté objet est facile pour le procédural, tandis que ce qui est difficile pour le procédural est facile pour l'orienté objet!

Dans un système, nous avons parfois le besoin d'une souplesse d'ajout de nouveaux types de données et choisissons alors une implémentation fondée sur les objets. Si nous voulons disposer d'une souplesse d'ajout de nouveaux comportements, alors nous optons pour les structures de données et les procédures.

Les programmeurs expérimentés savent très bien que l'idée du tout objet est un mythe. Les bons développeurs de logiciels abordent ces questions sans préjugé et retiennent l'approche adaptée à leurs besoins.

DES TESTS PROPRES

Le code de test est aussi important que le code de production. Il doit rester aussi propre que le code de production.
J'avais consacré un billet intitulé Les Tests Sont du Code à ce sujet et c'est d'ailleurs le thème du livre que je suis actuellement en train de lire : xUnit Test Patterns: Refactoring Test Code. Je reviendrai plus longuement sur ce livre car il améliore grandement ma pratique du test automatisé.

L'EVOLUTION DES SYSTEMES LOGICIELS

Les systèmes logiciels sont uniques si on les compare aux systèmes physiques. Leur architecture peut évoluer de manière incrémentale si nous maintenons la séparation adéquate des préoccupations (et le test de leurs constituants!).

SUR LA CONCURRENCE

Incroyable, deux chapitres du livre sont dédiés au développement de logiciels avec traitements concurrents! Malheureusement, il n'y a rien de bien nouveau. Néanmoins, c'est rassurant de lire des recommandations que nous appliquons déjà (voir mon précédant billet Extreme Programming Embarqué). Voici ces constats et recommandations:

La conception d'un système concurrent peut être très différente de celle d'un système monothread. Le découplage du quoi et du quand a généralement un impact très important sur la structure du système.

Gardez le code lié à la concurrence séparé de tout autre code. Ne tentez pas de pourchasser à la fois les bogues du code normal et ceux du code multithread. Assurez-vous que votre code fonctionne en dehors des threads.

CONCLUSION

Malgré quelques déceptions, je ne regrette pas la lecture de ce lire. Néanmoins, je conseillerais plutôt le livre précédant, bien plus enrichissant à mon avis.