- « Nous on est pas Google ou Facebook »
- « Nous on fait pas que du logiciel »
- « Nous on a de vrais risques produit »
Autant de punchlines que nous avons déjà entendues comme justification à « Que pensez-vous d’Agile ? » et qui sont aujourd’hui entrées dans l’inconscient collectif : « Agile, c’est pour les autres ».
Nancy VAN SCHOOENDERWOERT et Brian SHOEMAKER ont écrit un ouvrage intitulé « Agile Methods for Safety-Critical Systems » où ils partagent avec nous leurs implémentations d’Agile dans des systèmes complexes et critiques (avec un impact sur la vie d’un être humain).
Il vous est donc proposé ici d’en déguster un résumé des grandes lignes en vous invitant à faire l’acquisition de ce court ouvrage (environ 100 pages et des schémas couleurs) qui siéra parfaitement aux néophytes. L’idée de cet édito n’est pas d’évangéliser la culture Agile en cherchant à l’adapter et en prônant le remède miracle (les Westerns nous ont appris deux choses : Ennio MORRICONE est un prodigieux compositeur ; et le vendeur ambulant de remèdes miracles termine souvent mal) : intéressons-nous donc à la matière.
Agile n’est qu’une solution à un type de problème précis
Le livre, est en partie consacré à une présentation d’Agile (et sa mise à l’échelle) à travers ses modes de fonctionnement, bénéfices et pièges, sujets amplement traités avec soin dans nombre d’articles. Nous ne développerons pas cette partie de l’ouvrage ici.
Néanmoins il est un aspect que le livre rappelle : non, Agile n’est pas applicable à tous les projets. Non, Agile n’est pas le remède miracle qui apporte croissance à 2 chiffres. Agile est une philométhode (entre la philosophie / culture et la méthodologie) qui est efficace dans des situations précises.
Agile gère excellemment bien les environnements complexes avec des incertitudes fonctionnelles et techniques (moyennes à fortes) mais n’est pas adaptée aux environnements à fortes certitudes : si nous savons exactement quoi produire et comment le produire, la construction itérative n’a pas grand intérêt. Prenons une chaîne de production automobile : la première voiture doit avoir le même niveau de qualité que la 1000e, en aucun cas la valeur du produit ne peut être construite de façon itérative dans un environnement maîtrisé : nous savons quoi faire, et comment le faire.
Agile Vs produits « Hardware + Software »
La souplesse du logiciel avec sa capacité de mise à jour aisée en fait une part de plus en plus importante de l’ingénierie d’un produit : machine à café, voiture, bâtiment, une grande majorité des produits incorporent aujourd’hui une couche software. Le monde du « Soft » a popularisé Agile (qui vient paradoxalement … Du « Hard » !) si bien qu’une rupture des deux mondes s’est opérée : et on se boude !
Après la rupture, place à la réconciliation. Et si Agile pouvait réconcilier les deux anciens amants ? C’est la piste qui a été explorée dans l’ouvrage à travers la construction d’un spectromètre. Pour rappel un spectromètre conjugue : logiciel, mécanique et électronique (deux couches hardware à l’inertie différente) : la couche logicielle tourne en Agile, les deux couches Hardware en « ingénierie traditionnelle » :
Mais voila : l’algorithme avait des « ratés », y compris lorsque les données issues des capteurs étaient correctes. La couverture des tests unitaires et la capacité à faire tourner le code stable sur la cible hardware aura permis à l’équipe « soft » de remonter le problème à l’équipe « hard » qui identifia alors un bug sur la carte électronique.
Dans ce cas, Agile offre des points de vérification rapprochés et fournit aux couches plus rigides des tests fréquents qui favorisent la détection des défauts hardware et gomme ainsi le caractère inertiel de l’ingénierie à longs cycles. Oui, un produit complexe peut avoir une partie traditionnelle et une partie Agile. Mieux : cette dernière apporte des valeurs projets supplémentaires.
Agile d’accord, mais quid des normes et règlementations ?
La régulation… Le tortionnaire de tout projet critique, avec ses standards et son épée de Damoclès. Elle a droit de mort sur le produit sitôt qu’il n’est pas « compliant ».
Intéressons-nous ici à la FDA (Food and Drug Administration) qui régit les produits médicaux et alimentaires aux USA et qui sert de standard dans nombre de pays, entre autre en France. Pour faire simple vous êtes « compliant FDA » = vous avez le droit de vendre. La FDA est connue pour être une des règlementations des plus strictes et pour cause : on touche à l’être humain.
Néanmoins, une rigueur administrative n’impose pas forcément une rigidité projet totale. Mais que dit la FDA (ISO est également alignée sur ces aspects) sur les aspects projet ?
- Suffisamment de données d’entrées doivent avoir été énoncées et comprises
- Que pour chaque entrée, une analyse des risques doit avoir été faite
- Que pour chaque risque une atténuation de celui-ci doit avoir été faite et que chaque atténuation doit être reliée à une fonctionnalité
- Toutes les fonctionnalités doivent être liées à un test et celui-ci doit avoir été exécuté, revu et réussi
Et … C’est tout !
Mais voilà, en pratique on fait des aller-retours entre nos 4 points, l’un enrichissant l’autre : on procède de façon itérative pour affiner. Et si une situation itérative est appréciée, c’est bien dans Agile.
Agile offre dans ce cas là la même couverture des risques qu’une ingénierie traditionnelle (la gestion des risques ne dépend pas du cycle de développement) mais grâce à son caractère itératif (sprints) elle offre plus d’opportunités de détection (et de facto de correction) des divers défauts.
Gardez à l’esprit qu’un standard :
- Impose une analyse de risque itérative
- Impose de documenter et tracer les risques
- N’impose pas un cycle de développement particulier
Qu’un défaut trouvé en production coûte 10 000 fois plus qu’un défaut trouvé en étape de design : plus on teste tôt, plus on corrige tôt, plus on réduit les coûts de MCO des systèmes complexes.
En conclusion
