Aujourd’hui, de nombreux programmes de modernisation des systèmes de gestion du trafic aérien (ATM) suivent encore une méthodologie d’ingénierie de cycle en V et sont organisés en plusieurs sous-projets, chacun fonctionnant relativement indépendamment les uns des autres. L’expérience a démontré que dans les environnements ATM, cela peut mener à un allongement des échéances et à une augmentation des coûts des projets. Des experts d’Egis expliquent en quoi une approche « agile » peut apporter une solution à ces problématiques.
Les programmes de modernisation ATM sont complexes et reposent sur le déploiement d’un ou de plusieurs systèmes également complexes, souvent basés sur des solutions sur étagère et difficiles à faire évoluer en raison des normes de sécurité et des exigences de certification. À cela s’ajoute la difficulté de déployer le même système ou groupe de systèmes pour différents organismes de contrôle du trafic aérien ayant des paramètres, des contraintes, des besoins et des exigences parfois très différents les uns des autres.
Dans une méthode de type cycle en V, les ingénieurs définissent des éléments au début du projet, puis travaillent pendant des mois (voire des années) sans pouvoir en montrer les résultats, laissant les autres parties prenantes dans l’ignorance. C’est ce que nous appelons communément l’« effet tunnel ». Par ailleurs, cette méthode pose un certain nombre de problèmes récurrents tels que :
- Le besoin d’impliquer les industriels afin d’améliorer la coordination globale du projet, mais également de les accompagner à différents niveaux (méthodologique, technique, documentaire, etc.) pour faire le lien avec les différents centres de contrôle aérien et mettre en œuvre le système, surtout lorsqu’il doit s’intégrer à un système ou un environnement préexistant
- Le manque de visibilité quant à l’avancement du projet ou la production de doublons (ou bien l’omission de certains éléments) en raison du manque de coordination et de partage d’informations au sein du programme et des sous-projets
- Le démarrage et l’exécution d’activités multiples en parallèle (groupes de travail, paramètres à spécifier/mettre en œuvre/tester, etc.) créant des changements de contexte (trop) fréquents pour les équipes impliquées dans le projet et rendant la convergence difficile sur l’ensemble des activités
- Enfin, certaines questions transverses et communes à plusieurs sous-projets d’un même programme ne semblent pas être abordées ou le sont trop tardivement.
En parallèle, le monde de l’aviation est de plus en plus à la recherche de nouveaux processus pour obtenir des résultats le plus rapidement possible, pour fournir aux responsables un bon niveau de visibilité sur l’avancement du projet, qui doit être économiquement et humainement viable et faire participer tous les acteurs en équipes intégrées, de l’utilisateur final au développeur.
Les enjeux d’une nouvelle approche consistent donc à améliorer la collaboration et la coopération à tous les niveaux (de l’industriel à l’utilisateur final), tout en garantissant le respect des échéances de mise en service ainsi que l’efficacité et la valeur de ce qui est produit.
Les principes des méthodes Agiles
Les méthodes de développement Agiles reposent sur un groupe de méthodologies itératives dans lequel les exigences et les solutions évoluent grâce à la collaboration entre des équipes multidisciplinaires auto-organisées. Ces méthodes permettent de faire des points d’avancement du projet et des adaptations fréquentes, et encouragent une philosophie de leadership qui met l’accent sur le travail d’équipe et la responsabilisation. Elles permettent la mise en œuvre d’un ensemble de meilleures pratiques en matière d’ingénierie en vue de la fourniture rapide d’une solution logicielle de qualité. Enfin, elles encouragent une approche opérationnelle qui assure un développement logiciel en phase avec les besoins des clients et les objectifs de projet ou les enjeux commerciaux.
Le Manifeste agile comprend les principes suivants :
- « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »
- « Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les délais plus courts. »
- « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. »
- « À intervalles réguliers, l'équipe réfléchit aux moyens d’améliorer son efficacité, puis règle et ajuste son comportement en conséquence.»
Il faut cependant noter que, bien que l’approche Agile puisse être utilisée pour des cycles de développement courts d’un système, il n’est pas toujours possible de déployer ce système à la fin de chaque cycle, car il n’aura pas nécessairement les fonctions minimales requises pour être utilisable d’un point de vue opérationnel.
De récentes expériences d’acquisition de systèmes sur étagère et de l’application du développement classique du cycle en V ont souligné la difficulté de maîtriser le planning du projet, les coûts et le contenu des systèmes développés. C’est dans ce contexte que des équipes d’ingénieurs du secteur aéronautique ont développé une approche proactive pour s’orienter vers des méthodes de développement agiles.
Deux exemples concrets d’approche Agile
Un client dans le domaine de l’ATM a décidé d’utiliser une méthode Agile pour remplacer un outil de gestion des flux de trafic aérien. Le processus était simple : il consistait à installer une nouvelle version de l’outil dans plusieurs centres de contrôle en route tous les six mois au maximum, d’abord en version de test, puis auprès des utilisateurs opérationnels une fois que le système était jugé suffisamment mature. Il n’a fallu que deux ans pour que ce système soit opérationnel dans les différents centres de contrôle en route, malgré leurs spécificités. Depuis, de nouvelles versions ont été développées et mises en service tous les six mois.
Notre rôle dans le cadre de ce projet consistait à créer, maintenir et échelonner des priorités pour le « backlog » fonctionnel agile, c’est-à-dire fournir une vision commune, en format agile, des besoins et des priorités des opérations du centre de contrôle, le tout conformément aux objectifs stratégiques du projet. Nous avons également apporté un support au « Scrum Master » et assuré la relation avec le fournisseur du système, afin qu’il puisse proposer une solution conforme aux futures attentes. De plus, nous avons aidé le chef de projet à élaborer une feuille de route du projet dans un contexte agile en lui fournissant les bons outils agiles ainsi qu’une équipe support.
Un autre client a utilisé une autre méthodologie d’agilité à l’échelle appelée « SAFe » (ou Scaled Agile Framework), avec des équipes internationales géographiquement distantes, pour fournir avec succès des services à distance dans un délai de trois ans, respectant ainsi les échéances et le budget fixés. Pour ce client, un seul train agile a été mis en place pour synchroniser les équipes de production, qui fonctionnent elles-mêmes en mode agile. A la différence des méthodologies Scrum ou Kanban, SAFe comprend une couche supplémentaire au niveau du programme qui organise la synchronisation entre les équipes en établissant le rythme de travail grâce à des itérations prédéfinies et à des objectifs communs.
Nos équipes d’ingénieurs ont joué différents rôles pour accompagner le client dans ce projet, au niveau du programme comme « Product Manager Proxy », afin de définir le backlog du programme, d’établir la priorité des activités et « d’alimenter » les équipes du programme. Au niveau des équipes Agiles, nous avons travaillé sur des sujets transversaux, garantissant ainsi la définition et la cohérence de l’ensemble du système (architecture, choix technique, etc.), ainsi que la spécification technique et la validation du système. Nous avons également aidé les équipes de développement travaillant sur chaque composant ou service support, pour nous assurer que le système répondait aux attentes des clients.
Pas de solution miracle
Grâce à ces expériences, ainsi qu’à l’application de l’approche Agile dans les aéroports et les environnements avioniques, nous savons que celle-ci peut apporter une vraie valeur ajoutée. Aussi, pourquoi n’a-t-elle pas été adoptée plus tôt et plus largement pour assurer la transformation des systèmes aéronautiques ? La réponse réside en partie dans la nature critique de ces systèmes en matière de sécurité. Lorsque la sécurité est primordiale, les décisionnaires doivent s’assurer que les composants passeront avec succès les tests de sécurité et que celle-ci puisse être évaluée. L’enjeu de sécurité constitue un défi constant (sans qu’il soit pour autant insurmontable). Un autre facteur à prendre en compte est que les méthodes Agiles, si elles sont mises en œuvre par des personnes inexpérimentées, peuvent se traduire par des déploiements « précipités », sans stratégie ni cadre global. Il est essentiel de s’assurer qu’il y ait une vision claire et partagée des résultats finaux avant de se lancer dans un développement Agile. Enfin, lorsque la production des livrables se fait de façon itérative et que le périmètre notamment fonctionnel n’est pas figé dès le début, il peut être parfois difficile d’y lier les exigences contractuelles. Encore une fois, cet aspect n’est pas insurmontable.
Agile et intégré
L’intégration de nos ingénieurs dans les équipes mêmes de nos clients dans le cadre de projets à long terme leur a permis de partager les meilleures pratiques acquises en dehors de l’entreprise et d’appliquer ce savoir-faire de façon plus adaptée et efficace. Nos équipes intègrent de plus en plus des approches Agiles dans les problématiques d’ingénierie auxquels elles sont confrontées, car les résultats parlent d’eux-mêmes, que ce soit pour la rapidité du déploiement, la réduction des coûts ou l’atteinte des objectifs fixés. C’est la raison pour laquelle des clients comme la DSNA, Airbus, Skyguide et ADP choisissent Egis pour accompagner leurs projets d’évolution des systèmes.
