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!