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