L’agilité à la conquête de MARS (Approches agiles pour assurer la fiabilité extrême des logiciels embarqués dans les vaisseaux spatiaux Orion)

De la construction des grandes pyramides à l’atterrissage sur la lune, les œuvres les plus spectaculaires de l’humanité ont reposé sur l’effort conjoint de milliers de personnes travaillant ensemble pour un objectif commun.

Si aujourd’hui les noms de Neil Armstrong et Buzz Aldrin symbolisent à jamais l’une des plus grandes réalisations de l’humanité, ce sont bien les personnes ayant accompagné l’organisation des 400 000 hommes et 20 000 entreprises ayant travaillés sur les missions Apollo, qui ont été parmi les plus cruciales dans l’atteinte de les faire marcher sur la lune.

“De toutes les difficultés rencontrées par la NASA dans sa tentative d’envoyer des humains dans l’espace, la gestion du projet était sans doute le plus grand des défis.” – Roger D. Launius, chief historian, NASA

C’est une organisation et un formidable travail d’équipe qui ont remporté la course à l’espace.

A l’époque, pour la NASA , le problème n’était pas tant de savoir quoi faire, mais de savoir comment le faire en si peu de temps. Il fallait définir une organisation pour que chaque partie prenante de ce formidable projet réussissent à collaborer et à livrer un travail exploitable en temps opportun.

Pour définir cette organisation, la NASA a fait confiance au Dr George E. Muller, qui a accompagné tous les acteurs du programme Apollo de la Maison Blanche au plus petit fournisseur.

Le docteur George E. Muller a prit le parti, dès l’annonce de Kennedy en 1961 de créer 5 pôles :

• Contrôle de programme
• Ingénierie système
• Test
• Fiabilité
• Qualité et opérations aériennes

Ce système à cinq composantes, appelé boîtes GEM d’après les initiales de Muller, a été conçu “pour se concentrer, dès le début du programme, sur le fait que vous alliez tester des choses, et que vous deviez les concevoir et les réaliser dans le but de pouvoir les tester”.

Les tests ont toujours été au centre de la stratégie de qualité et de fiabilité de la Nasa.

Aujourd’hui, les choses ont bien évolué. Néanmoins l’organisation du travail reste L’ACTIVITE cruciale pour la NASA et les tests en sont encore et toujours le centre névralgique.

Quand j’ai entendu parler “d’organisation du travail”, en tant que coach agile, ma curiosité a été piquée au vif.

J’ai alors entrepris de sourcer et creuser le sujet et suis tombé sur un article fort intéressant de Monsieur Justin Smith qui travail pour la cellule de “vérification et validation” de la NASA. Cet article décrit comment la NASA utilise les “Approches agiles pour assurer la fiabilité extrême des logiciels embarquée dans les vaisseaux spatiaux Orion”. L’article est disponible en anglais (et payant) à cette adresse.

Je vais vous en résumer l’essentiel….

De l’agilité à la NASA ?

Le pôle de vérification et validation indépendantes de la NASA ( dans la suite de l’article IV&V) joue un rôle essentiel.
La mission de l’IV&V est de s’assurer que les logiciels embarqués dans les engins spatiaux feront ce qu’ils sont
censé faire, ne feront pas ce qu’il ne sont pas censé faire et réagissent de manière appropriée dans des conditions défavorables ou face à l’imprévu.

Entre autres projets, une cellule de l’IV&V doit assurer la fiabilité des logiciels présents à bord des vaisseaux Orion qui ne sont rien moins que la prochaine génération de vaisseaux spatiaux qui abriteront des vols habités et dont l’objectif principal est de se rendre à moyen terme sur mars.

Vous vous en doutez, le pilotage d’un vaisseau spatial dans les confins de l’espace est tellement complexe qu’il demande une énorme part d’automatisation. Autrement dit, la part humaine dans le pilotage de ces vaisseaux est minime.

Dans cet article, nous allons évoquer l’histoire du développement et du test de l’un des logiciels principaux : SEM (à priori pour System Exploration Mars).

SEM comprend plus de deux millions de lignes de code source composé à la fois développés main et aussi automatiquement générées. Nous reviendrons dans la suite de cet article sur le concept de code automatiquement généré qui est un point important dans les pratiques agiles de la NASA.

Avant d’envoyer des humains à bord d’Orion à la conquête de mars, deux vols d’essais ont été prévus.

Le premier de ceux-ci, Exploration Flight Test 1 (EFT-1), s’est déroulé avec succès le 5 décembre 2014. Il s’agissait de faire voler Orion sur deux orbites pour tester différents systèmes à bord du véhicule. La rentrée atmosphérique s’est réalisée à 32.000 km/h comme prévu, environ 85% de la vitesse d’une rentrée d’un véhicule revenant de la Lune. Pour ce projet la Nasa a dépensé près de 9 milliards de dollars.

Le deuxième vol d’essai, dont le lancement est prévu courant 2020 a le doux nom de EM-1. Il enverra la capsule Orion en orbite autour de la lune et passera trois semaines dans l’espace.

Après ces deux vols d’essais, la première mission concrète devrait voir le jour vers 2025. L’objectif avoué étant d’envoyer un vol habité vers la planète mars.

L’histoire de l’agilité chez IV&V – L’histoire de Justin

Lorsqu’il a été décidé que notre équipe, IV&V, allait être responsable de la fiabilité de SEM, nous étions enchantés.

Cependant, nous avons vite déchanté lorsque nous nous sommes aperçus que le développement du logiciel était effectué avec les méthodes agiles (en l’occurrence SCRUM). Pour que vous compreniez bien : l’agilité avait une mauvaise réputation à l’époque à la NASA. En effet, elle véhiculait l’impression de ne jamais obtenir un produit fini.

De notre côté, pour les tests, nous fonctionnions alors de manière très simple et traditionnelle : Nous attendions que l’équipe de développement nous livre un produit fini pour en faire l’analyse. Nous relevions les anomalies pendant notre phase d’analyse et donnions notre Go ou NoGo pour son déploiement.

L’enjeu, pour tester SEM était  que nous devions caler notre rythme et notre fonctionnement à celui de l’équipe de développement tout en maintenant un niveau de qualité de tests irréprochable.

La première étape a donc été de nous caler sur une démarche itérative pour tester un produit de plus en plus conséquent. Cela a été une révolution dans notre manière de fonctionner car nous devions rapidement répondre à beaucoup de questions :

• Comment dérouler l’intégralité des tests sur seulement des morceaux du logiciel ?
• Comment savoir quoi tester et à quel moment le tester ?
• Comment tester l’aléa (nous en parlerons dans la suite de l’article) sur seulement une partie du système ?

L’équipe de développement nous livrait sur un environnement exploitable un incrément testable tous les 3 mois.
C’était très frustrant pour nous, habitués à dérouler des plans de test robustes, de ne pouvoir mener que des demies-analyses !

De plus, au moment ou nous recevions le livrable à tester, nos retours n’étaient pas pris en considération : soit le problème était déjà résolu (donc notre valeur ajouté était nulle) soit l’équipe était déjà passé sur le prochain incrément et ne souhaitait pas prendre immédiatement en compte nos retours.

Face à un développement de produit si organique et vivant, il devenait évident que notre pôle devait s’adapter et ne pouvait plus fonctionner comme avant pour être efficace.

S’adapter, oui, aller de l’avant, ok, mais comment ? Nous venions déjà tant bien que mal de nous habituer à tester des morceaux de produit…L’équipe IV&V n’allait pas subitement doubler de taille, et l’équipe de développement n’allait pas ralentir sa production pour nous attendre !

IV&V devait mettre en œuvre un changement, quelque chose qui permette à l’équipe IV&V d’assurer la qualité extrême du logiciel de vol Orion tout en offrant la possibilité de changer rapidement nos plans d’analyse si les priorités, les zones de risque, changeaient pour une raison quelconque. Nous avons donc mené notre première rétrospective et identifié les points à améliorer suivants :

Levier d’amélioration 1 :

Nous avons compris que nous ne devions pas attendre la livraison d’un incrément produit pour mener nos tests mais que nous avions besoin de nous investir plus tôt dans le test de celui-ci et ce afin que l’équipe de développement puisse prendre en considération nos retours au moment approprié au lieu de les corriger dans une version ultérieure avec une augmentation des coûts pour un programme limité en ressources et budget.

Levier d’amélioration 2 :

Nous avions le sentiment de perdre une grande énergie pour assurer le bon fonctionnement de choses relativement peu importantes.

Levier d’amélioration 3 :

Notre équipe, constitué de 22 experts tous pointus dans leur domaine était en fait extrêmement sillotés : Nous étions tous experts dans un domaine très particulier mais non sachant sur les domaines voisins.

Face à ces axes d’améliorations nous avons décidés d’aborder concrètement les points suivants :

• Etre plus polyvalents au sein de l’équipe et passer d’un modèle de compétence en I vers un modèle en T.
• “Suivre le risque” de manière plus dynamique en étant capable de suivre les re-priorisation

Nos premières actions concrètes d’améliorations

Suite à cette première rétrospective les actions engagées ont donné lieu aux choses suivantes :

1. Nous avons dressé un “paysage du risque” dans chaque domaine de spécialisation. Un paysage du risque signifie que nous avons formalisé de manière fine ce à quoi sert cette partie du système, les points critiques à surveiller et les impacts si cette partie devenait dysfonctionnante pendant la mission.
2. Chaque “point critique” était :
   1. Formalisé de la manière suivante : «IV&V ajoute l’assurance que [nom] [action verbe] pour atténuer le risque / éviter [question / préoccupation] ».
   2. Couvert par un test directement dans le code avec la spécificité que si le test échoue lors d’une exécution, il est suffisamment intelligent pour générer lui-même le code correcteur afin de repasser ok.

En enclenchant ces actions, nous pensions grandement accroître la connaissance de l’équipe sur SEM, gérer les erreurs critiques et donc réduire le risque que la mission échoue.

L’ensemble de ces tests intelligents représente ce que le logiciel est à minima capable de faire à un moment M et sont devenus l’unique indicateur que nous communiquons à nos parties prenantes.

Grâce à cela, nous concentrions notre énergie uniquement là ou c’était nécessaire.

Je vois déjà bondir les adeptes des méthodes traditionnelles ! Voici un message qui leur est adressé :
Que notre manière de travailler fonctionne ne veut pas dire que les approches plus traditionnelles ne fonctionneraient pas. Elles fonctionneraient d’ailleurs très certainement.

Mais notre équipe IV&V n’avait pas le budget nécessaire pour se permettre de faire des tests mineurs et non critiques.
Dans un premier temps, l’approche agile nous permet de produire plus de valeur pour le Programme Orion avec les mêmes ressources.

Cependant avec cette manière de procéder, nous avons constaté que nous relevions beaucoup plus d’erreur critiques qu’avec notre ancienne méthodologie.

Diffusons et passons à l’échelle

Bingo !
Il ne fallait pas plus que quelques mois et les retours très positifs de nos parties prenantes et de l’équipe de développement pour qu’on nous demande d’industrialiser ces pratiques au delà de notre équipe pilote.

En débutant l’accompagnement des autres équipes de notre pôle sur ces nouvelles manière de travailler, nous nous sommes heurtés à une barrière inattendue : la liberté de choisir quoi faire.

En effet, l’auto-organisation n’est pas toujours évidente : si la majorité des analystes y voient une bonne chose d’autres semblaient préférer qu’on leur donne une orientation précise quant à l’analyse à effectuer plutôt que de la déterminer eux-mêmes.

Pour nous aider dans la diffusion de ces pratiques, et nous permettre de nous améliorer, nous avons fait venir un intervenant extérieur : Will Hayes.

Will possède une vaste expérience dans la mise en œuvre de Méthodes de développement agiles à grande échelle, avec une affinité particulière pour SAFe – Scaled Agile Framework.

Pour débuter son intervention, Will nous a fait effectuer l’atelier “letter from the futur” en nous demandant de décrire ce à quoi nous espérions que notre équipe ressemble dans 6 mois.

L’output de cet atelier est ce qui est devenue la vision “Agile IV&V” que nous viendrions à utiliser comme ligne directrice pour notre évolution.

Par la suite, Will nous a fait remarquer que notre fonctionnement d’équipe était du Scrum adapté. Effectivement, le suivi des points critiques évoqués plus haut alimentaient une sorte de backlog, nous fonctionnions en itérations, nous faisions des stand-up et des rétrospectives….

Le travail dans les mois qui ont suivis a été d’évangéliser et de convaincre, en s’appuyant sur nos succès, le reste des équipes de passer sur notre scrum adapté.

Pour ce faire, nous avons créé le rôle de Scrum Leader. Le rôle de SL se différencie du SM car nous ne cherchons pas à appliquer bêtement le framework Scrum mais à l’adapter au mieux au contexte de chaque équipe.

Aujourd’hui, début 2020, au dela des équipes de développements, l’intégralité de notre pôle fonctionne en SCRUM et nous savons qu’il nous reste du chemin à parcourir…

Et la suite ? SAFe ?

La problématique qui émerge naturellement (et presque immédiatement) lorsque plusieurs équipes agiles essaient de collaborer et la problématique de synchronisation.

Actuellement nous nous dirigeons donc vers un fonctionnement inspiré de SAFe avec un “mega-sprint” de 12 semaines lui-même constitué de 4 itérations de 3 semaines. Avec un point de synchronisation hebdomadaire inter-équipes et une grande rétrospective commune pour clore le mega-sprint.

Par ailleurs, pour compenser (et assurer) la de-responsabilisation potentielle provoquée par la polyvalence de chacun nous avons mis en place notre Chaos Monkey : Une intelligence provoquant de grandes perturbations aléatoires dans le code de SEM pour simuler les effets de l’incertitude de l’espace et les dysfonctionnement potentiel.

Cette mécanique de chaos couplée aux tests intelligents auto-correcteurs donne des résultats ahurissants !

Pour quels résultats ?

Depuis la transition courant 2016 vers les méthodes agile et au delà des bienfaits déjà évoqués, l’agilité nous apporte au quotidien :

• Des collaborateurs plus motivés et plus impliqués
• Un plus grand niveau de confiance dû à l’auto-organisation
• De bien meilleures conversations plus efficaces
• Une très grande qualité avec moins de faux-positifs

Début 2020, notre pôle se porte mieux que jamais. Toutes les entités avec qui nous sommes en interactions, de nos parties prenantes à nos sous traitants en passant par le TOP management de la NASA sont extrêmement impressionnés par la qualité du travail qu’IV&V effectue et nous sommes devenus un exemple d’excellence.

Note du traducteur

Sur coach-agile.com, nous parlons souvent d’outils, de concepts, … mais il y a très peu de retours d’expérience.
Je tente ce nouveau format car j’ai toujours été passionné par l’astronautique et j’ai voulu vous partager ma découverte récente.
J’espère que vous trouverez autant d’intérêt à le lire que j’ai eu à l’écrire et traduire. A quand les tests automatisés générant eux mêmes le code pour passer à ok dans votre contexte 😉 ?