AGILE, LEAN ET LOGICIEL CRITIQUE

C'était osé de croiser trois domaines tels que l'agilité et le Lean, le logiciel critique et le logiciel libre (d'ailleurs, cela m'a permis de comprendre la symbolique du logo du projet Open-DO).
Ce mélange est bien à l'image d'AdaCore qui a organisé cet évènement très réussi, baptisé The Lean, Agile Approach to High-Integrity Software.

J'ai beaucoup apprécié plusieurs choses:

DU LOGICIEL ET DES HOMMES

D'abord, je trouve cela vraiment agréable de mettre des visages sur les outils qu'on utilise, sur les lignes de code qu'on réutilise et sur les signatures des experts qui vous dépannent. Ce genre d'évènement est une des rares occasions de rencontres, de retrouvailles et d'échanges informels et enrichissants entre professionnels du même milieu, parfois même entre concurrents.

DES HOMMES ET DES IDÉES

Ensuite, j'ai vraiment ressenti qu'il y avait confrontation d'idées et divergences d'opinions. Pour moi, l'exemple le plus frappant était l'opposition entre ceux qui privilégient la preuve formelle par analyse statique à la compilation et ceux qui privilégient la preuve expérimentale par test à l'exécution. Attention, j'insiste sur le mot privilégier, car il accorde plus d'importance à un aspect sans pour autant négliger les autres. D'ailleurs, la programmation par contrat est peut-être une pratique qui réunit les deux mouvements, puisque les assertions sont spécifiées, compilées et exercées à l'exécution par les tests.

DES IDÉES ET DES PISTES

Aussi, je ramène toujours d'une conférence au moins une idée, ou plutôt une piste à explorer. Cette fois ci c'est Roberto Di Cosmo qui me l'a soufflé lors de sa géniale présentation. J'ai retenu que pour paralléliser les travaux de nombreux développeurs, certains projets de logiciels libres adoptent une architecture modulaire inspirée de la philosophie Unix. L'architecture s'appuye sur l'utilisation de nombreux modules indépendants ayant chacun une responsabilité (forcément, on repense au Single Responsibility Principle d'Uncle Bob). Dans un premier temps, une série de modules est développée. Puis dans un deuxième temps, une fonctionnalité est développée en s'appuyant sur ce catalogue de modules. Pour un agiliste, la première phase semble être génératrice de stock.

Ceci dit, en parallèle d'une démarche itérative et incrémentale pilotée par les tests de recette des fonctionnalités les plus prioritaires, pourquoi ne pas mener également le développement de modules à une responsabilité dont on sait bien qu'on aura besoin dans l'avenir. Certes, c'est du stock, mais cela peut permettre d'augmenter la vélocité des itérations futures. Ce deuxième flux de travail, en parallèle et en avance de phase, peut par exemple être piloté par simple Kanban. Une telle organisation ne permet pas de réduire les coûts de développement mais elle permet peut être de tenir la course aux jalons. De plus, elle permet d'avancer en parallélisant sans accentuer la pression sur l'architecture. Celle-ci peut donc évoluer au fil des remaniements pour accueillir les fonctionnalités à venir qui intégreront les petits modules préalablement développés. A méditer ...

DES PISTES ET DES SOUVENIRS

Enfin, je ramène de cette rencontre un collector: Mon exemplaire de Lean Software Strategies est désormais signé par l'auteur ;o)

Merci AdaCore!

Références et liens:
Présentation du projet Open-DO par Cyrille Comar;
Compte-rendu par Laurent Morisseau;
Lean vs Agile, par Alexandre Boutin
The Lean, Agile Approach To High-Integrity Software, par Jamie Ayre

LEAN, CARTOGRAPHIE DU FLUX DE VALEUR

Il s'agit d'identifier toutes les étapes créatrices de valeur en éliminant les activités qui ne créent pas de valeur.

COMMENT PROCÉDONS-NOUS?

Il n'y a pas réellement de pratique agile qui implémente spécifiquement cet objectif. Ceci dit, toutes les pratiques de l'Extreme-Programming implémentent la valeur Simplicité, qui consiste à maximiser le travail à ne pas faire.

Alors, nous pratiquons le Value Stream Mapping du Lean. Les activités à mener en série et en parallèle sont identifiées. Des temps moyens par poste sont mesurés afin de révéler les contraintes et de mesurer une cadence type. Nous avons aussi remarqué que cette cartographie est appréciée par les nouveaux arrivant sur le projet. La cartographie permet de visualiser comment nous procédons pour transformer les besoins en logiciel opérationnel.

IDENTIFIER LES GASPILLAGES

Lorsqu'on pratique le Value Stream Mapping, il faut apprendre à identifier les gaspillages. Il s'agit des pratiques qui ne créent pas de valeur.
Par exemple, dans notre secteur, les développeurs sont terrorisés par le risque que le logiciel ne tienne pas sur la carte embarquée à cause d'un dépassement de charge de calcul ou d'utilisation de mémoire. Alors, nombreux dans notre filière optimisent leur code prématurément. Cette optimisation est pilotée par la peur et non par des faits. Voilà une source de gaspillage: il se peut bien que le code soit suffisamment performant! L'effort consacré à l'optimisation est alors perdu. De plus, le code est devenu plus complexe. C'est pourquoi, notre pratique est de ne pas optimiser prématurément le code.
Par contre, nous nous devons de surveiller les performances tôt et souvent. Le code est alors optimisé au besoin et de manière ciblée sur la base d'informations concrètes. En effet, nous pensions qu'il est plus aisé d'accélérer un code correcte que de corriger un code rapide. La prise de décision est facilitée en automatisant la mesure des performances et le profiling du code.

Néanmoins, cette pratique n'empêche pas d'optimiser prématurément le code. Voilà encore une raison pour laquelle nous pratiquons le Pair Programming. Le navigateur se doit de décourager le pilote d'optimiser prématurément le code.

Le prochain billet sera consacré au flux continu de valeur. A bientôt!

LEAN, LA VALEUR

Le premier des 5 piliers du Lean est la Valeur. Il s'agit de spécifier la valeur du point de vue du client final. Pour nous, développeurs, il s'agit le développer le bon produit.

COMMENT PROCÉDONS-NOUS?

L'Extreme-Programming recommande d'adopter une organisation de projet avec un client sur site. Malheureusement, nous ne pouvons pas pas inclure un avionneur, un pilote et un certificateur dans chacune de nos équipes. Alors, comme recommandé dans Scrum, nos équipes ont chacune un Product Owner. Il s'agit d'un expert du domaine qui représente l'avionneur et le pilote. D'autre part, un responsable qualité est affecté à chaque projet. Il est le représentant du certificateur. Ainsi, le point de vue des différents clients est pris en compte.

Le Product Owner exprime la valeur sous forme d'exigences. Il donne ses critères de satisfaction en fournissant des tests de recette à automatiser.

Le Product Owner priorise les exigences dans le Backlog Produit. Ces priorités cherchent à maximiser le retour sur investissement du client. Comme ces priorités pilotent la succession des itréations, c'est le déroulement du développement qui cherche à maximiser le retour sur investissement du client.

Lorsque les équipes sont volumineuses, elles sont redivisées en sous-équipes plus petites. Chaque sous-équipe contient son propre Product Owner. Afin de s'assurer que les priorités de chaque sous-équipe restent compatibles et respectent celles du client final, le projet est piloté par un Super Product Owner. Au delà de la découpe du produit en sous-éléments, il est le garant de la vision produit et du point de vue du client final.

Le prochain billet abordera le second pilier du Lean: le Flux de Valeur. A bientôt!

EXTREME PROGRAMMING CRITIQUE

La pratique de l'Extreme Programming est très peu répandue pour le développement de logiciels critiques. Ces applications sont utilisées dans l'avionique, le médical, le ferroviaire, le nucléaire et l'automobile.

LES ALEAS DU LOGICIEL CRITIQUE

Les logiciels critiques doivent être certifiés par un organisme spécialisé pour garantir la sûreté de fonctionnement.

La certification est obtenue après une série d'audits exigeant la fourniture des preuves des activités menées pour garantir la sûreté de fonctionnement.
Par exemple, l'organisme certifacteur va s'assurer que le logiciel contient exclusivement du code implémentant les besoins opérationnels du produit. L'implémentation de tous les besoins opérationnels et tout le code devront être vérifiés par des tests. Ces tests devront être joués sur la version finale du logiciel. Ainsi, un changement même mineur du code de la version finale implique que l'intégralité des tests devront être rejoués. Ceci peut représenter un coût considérable si les tests sont joués manuellement par un opérateur. Enfin, tous les produits du développement (exigences, documents, traçabilité, architecture, code, tests) devront être revus.

Les projets de développement de logiciels critiques sont clairement marqués par les processus, les outils, la documentation et la recherche de la conformité aux plans. Le développement logiciel agile et l'Extreme programming en particulier sont-ils applicables dans ce secteur?

EXTREME SURETE

Certaines pratiques de l'Extreme Programming se révèlent être une grande aide au développement de logiciels critiques.
La construction incrémentale pilotée par les besoins opérationnels (les user stories) et les tests d'acceptation assure que le code n'est écrit que pour faire passer les tests d'acceptation d'un besoin opérationnel. Ainsi, le logiciel contient exclusivement du code implémentant des besoins opérationnels.
Les tests d'acceptation systématiques assurent que la prise en compte de tous les besoins opérationnels sont vérifiés par test.
Les tests dévéloppeur systématiques assurent que tout le code est vérifié par test.
La pratique du Test First Programming assure que les tests sont indépendants du code qu'ils vérifient puisqu'ils sont écrits avant même le code.
Les tests d'acceptation et développeur sont automatisés et vérifient leurs résultats. L'intégralité de ces tests est automatiquement rejouée par l'outil d'Intégration Continue dès que le code est modifié. Ainsi, la dernière version du logiciel est toujours intégralement et rigoureusement testée de manière reproductible à faible coût.
Le Pair Programming assure que les produits sont revus en continu.

ADAPTATION

Les pratiques d'XP ne fournissent pas le niveau de formalisme requis par les audits de certification. Certaines pratiques devront être adaptées et d'autres ajoutées. Par exemple, la documentation devra être considérée comme faisant partie du produit. Elle devra alors être incrémentalement rédigée au fil des itérations afin de rester potentiellement livrable.

CONCLUSION

Les pratiques disciplinées et rigoureuses de l'Extreme Programming sont une aide au développement de logiciels critiques. Par contre, les pratiques doivent être adaptées pour fournir le niveau de formalisme requis par les audits de certification.

MOINS CHERS ET PLUS SURS

Aujourd'hui, Alex et moi avons rapidement traversé un labo d'intégration et de validation de logiciels critiques. Tout en discutant nous avons remarqué que:

• plusieurs opérateurs déroulaient des procédures de test à la main;

• un des opérateurs rédigeait un SMS sur son téléphone portable tout en déroulant à la main une procédure de test. Nous ne pouvons pas lui en vouloir, la procédure de test manuelle est sûrement assommante et ce n'est probablement la première fois que l'opérateur déroule cette même procédure. De plus, il ne s'agit pas d'une exécution de test comptant pour une certification de sûreté de fonctionnement.
  

De cette petite visite, nous avons tiré les conclusions suivantes:

• des tests automatisés réduiraient le coût des tests déroulés dans ce labo;

• Alex et moi aurions plus confiance en un logiciel vérifié par un test automatisé qu'en un logiciel vérifié par un opérateur distrait.

Bref, par rapport à des tests manuels, les tests automatisés sont économiquement plus intéressants et améliorent la sûreté de fonctionnement.

Une troisième pensée me vient en rédigeant ce billet. Rien ne vaut aller et constater par soi-même (ou Genchi Genbutsu en Japonais), conformément au Toyota Way. Impossible de parler d'Alex sans évoquer le Lean ;o)

A la prochaine Alex!

EXTREME PROGRAMMING EMBARQUÉ

La pratique de l'Extreme Programming est encore assez peu répandue pour le développement de logiciels embarqués.

LES ALÉAS DE L'EMBARQUÉ

En plus de difficultés classiques rencontrées en développement de logiciels, ce secteur est également confronté à des problèmes bien spécifiques.

Le logiciel est souvent couplé à un HardWare (HW) et un OperatingSystem (OS) spécifiques. Parfois même, le HW et l'OS sont développés en parallèle du logiciel et ne sont donc disponibles que tard dans le projet et en faibles quantités. Ainsi, l'intégration avec le HW et l'OS est du type Big-Bang et trop tardive. L'activité de test est alors peu efficace puisque essentiellement composée de séances de debug sur la cible. Aussi, il est regrettable de vérifier des algorithmes métier complexes sur un environnement aussi peu ergonomique que la carte embarquée.

Enfin, les développeurs sont confrontés au temps-réel, à la concurrence et au ressources limitées en charge de calcul et en mémoire.

Historiquement, les projets embarqués ont plutôt la réputation d'être marqués par les processus, les outils, la documentation et la recherche de la conformité aux plans. Bref, nous sommes bien loin du développement logiciel agile.

EXTRÊME PROGRAMMING EMBARQUÉ

Pourtant, certaines pratiques techniques de l'Extreme Programming se révèlent être une grande aide au développement de logiciels embarqués.

La pratique du pilotage par les tests (TDD) amène naturellement à découpler le code. Pour un logiciel embarqué cela conduit à isoler et réduire les dépendances vers le HW et l'OS pour de simples raisons de testabilité. Une telle conception pilotée par les tests permet alors de jouer des suites de tests sur une machine de développement (et non sur la cible) avec des mocks et stubs du HW et de l'OS. Ainsi, la quasi-totalité du code est testée et intégrée bien avant la disponibilité du HW et de l'OS!

Lorsque la cible est enfin disponible, les suites de tests sont rejouées sur celle-ci. Avec un langage de programmation tel que Ada, la construction des suites de tests avec une version native de la runtime Ada embarquée permet même de rejouer les tests sur la cible sans adaptation particulière (autre que la compilation croisée pour le processeur cible).

Le plus étonnant est que l'indisponibilté du HW et de l'OS, jadis une difficulté, est dévenue un atout! En effet, le découplage exigé par le TDD et rendu possible par un langage de programmation orienté-objet impose de bien concevoir les dépendances en séparant les problèmes. Les interfaces avec le HW et l'OS sont donc isolées du code métier. Les algorithmes métier complexes sont testés d'un côté sur une machine de développement et les les interfaces avec le HW et l'OS sont testés par ailleurs sur la cible.

Ainsi, gràce à la confiance que le développeur a en son code pleinement testé, il sait que les problèmes qu'il rencontrera (peut-être tardivement) en intégrant sur la cible ne concerneront plus que les interfaces avec le HW et l'OS, le temps-réel, la concurrence et les ressources limitées en mémoire et charge de calcul.

EXTRÊME SÛRETÉ

Parfois les logiciels embarqués sont également critiques, c'est à dire sûrs de fonctionnement. Je consacrerai un prochain billet sur cette difficulté additionnelle.

TESTER LES IHM

Comme beaucoup de monde, nous nous sommes cassé les dents sur l'automatisation des tests d'IHM. Dommage que je ne connaissais pas à l'époque le petit pattern que Michael Feathers a décrit dans ce court article: The Humble Dialog Box.
Dans sa démarche, la couverture par les tests automatisés n'est pas exhaustive, mais elle est déjà bien optimisée. Et puis sa solution a le mérite de la simplicité. Ce n'est pas rien...

Son principe est de ne mettre aucune logique dans les classes des widgets. Ce code est extrait du widget pour être mis dans une classe écrite en Test First Programming et dépendant d'une interface du widget.
Pour les besoins des tests automatisés, l'interface du widget est implémentée dans la fixture du test unitaire par un stub ou un mock (au choix selon les goûts).
En revanche, pour l'application en production, l'interface du widget est implémentée par un vrai widget qui a l'humilité de déléguer le traitement de tous les évènements graphiques à une instance de la classe "intelligente". Ce code de délégation n'est pas testé de manière automatisé mais le risque est limité à du code "humble".

Michael Feathers est un testeur héroique. Il se confronte aux pires cas. Après le test automatisé des IHM, il s'est attaqué au test automatisé du "legacy code", c'est à dire des applications écrites sans tests. Il y a consacré un livre: Working Effectively With Legacy Code.

J'étais déjà tombé par hasard sur The Humble Dialog Box il y a quelques années mais je l'avais négligé à tord. C'est ma lecture du moment xUnit Test Patterns: Refactoring Test Code qui m'a redirigé vers cet article. Je reparlerai plus tard de ce livre assez génial qui impacte beaucoup ma manière de tester en ce moment.