Les méthodes agiles sont aujourd’hui populaires dans le monde du développement logiciel.
Mais peut-on réellement implémenter ce type d’approche itérative dans les projets d’ingénierie, en conception mécanique et électronique?
Syncroness, filiale du groupe ALTEN, combine avec succès la méthode agile et le cycle V industriel dans plusieurs projets de conception de systèmes spatiaux embarqués. Leur approche innovante a fait l’objet d’une publication sur AIAA, la plus grande communauté américaine des ingénieurs en aérospatial.

Jusqu’à présent, le développement des systèmes embarqués critiques (ex: calculateur de contrôle de trajectoire…) s’est toujours fait avec un processus rigoureux et un cahier des charges clairement défini dès le démarrage du projet. Mais cette approche conventionnelle commence à montrer ses limites face à l’évolution fulgurante des technologies de micro-électronique et des demandes changeantes du marché. Il n’est pas rare que, dans ce secteur, à peine arrivé au stade du prototypage, le produit soit déjà obsolète par rapport à la technologie disponible sur le marché, ou il ne réponde plus aux nouveaux besoins du client final.

La méthode agile, en particulier le Scrum , consiste à découper un projet complexe en plusieurs sous-projets. A défaut de délivrer un logiciel complet en deux ans, l’équipe de développement utilise une à deux semaines pour délivrer un module ou une évolution du logiciel. Entre chaque « sprint », l’équipe de développement est en contact avec le client final pour définir les besoins et les technologies à adopter. Cette « agilité » permet au concepteur de réagir rapidement aux déviations (ex : nouvelle demande de l’utilisateur, nouvelle technologie…).

Mais la méthode peut-elle convenir à la conception des systèmes intégrés (mécanique et électronique), comme le développement d’un système embarqué ? Nous allons donc parcourir les différences, point de vue projet d’ingénierie, entre le développement logiciel et la conception des systèmes électroniques-mécaniques.

 

La méthode Scrum ne peut s’appliquer telle quelle en projet d’ingénierie…

Comme on peut le voir dans le tableau ci-contre, la conception électronique / mécanique a des contraintes très différentes du développement logiciel.

Réaliser le prototype et industrialiser un équipement coûte cher, tout comme la modification de la définition d’un système si elle impacte les phases de test et de production. Tout le contraire du monde informatique.

Cela explique l’approche conventionnelle appliquée dans l’industrie : un cahier des charges extrêmement clair et bien défini, de multiples étapes de validation entre chaque phase de conception (ex : spécification technique, architecture, conception détaillée, test…). Cette démarche top-down, suivant un processus rigoureux (cycle en V), réduit au maximum le risque des modifications de dernière minute.

Cette différence fondamentale explique la réticence du secteur à adopter la démarche Scrum, et ceux qui ont essayé ont rencontré énormément de difficultés (Cf. la publication Case Study of a Mechanical Product Development Team using Scrum Mais dans le monde du développement logiciel embarqué, la méthode agile fait déjà l’unanimité . Syncroness fait le constat suivant : vu la complexité des systèmes modernes et le besoin d’intégration de plusieurs compétences, une démarche coordonnée est nécessaire pour mener à bien les projets de développement. Il n’est plus possible d’adopter deux méthodes de projet différentes pour d’un côté, l’équipe hardware, et de l’autre, l’équipe logiciel .

 

4 outils de méthode agile appliqués aux projets d’ingénierie mécanique et électronique

Incité par son équipe de développement logiciel, Syncroness a étudié comment implémenter les grands principes de méthode Agile dans différents aspects de conception de produits. Les avantages sont nombreux : délais de livraison plus rapides, meilleure qualité des livrables, réduction de risque, amélioration continue, transparence entre l’équipe de développement et le client final…

Après avoir parcouru beaucoup de littératures, les ingénieurs Syncroness ont découvert que les grands principes du manifeste agile ont beaucoup de points communs avec le Lean (une méthode issue du monde de la production). Aujourd’hui, ce qui manque pour une équipe projet, c’est un guide pratique pour commencer à mettre en oeuvre les principes de méthode Agile sans bousculer le processus de développement de produits existants . Après avoir étudié les principes et expérimenté la méthode dans des projets concrets, Syncroness a identifié les quatre outils les plus impactants : développement incrémental, tableau de bord des tâches, daily stand-up et démonstration régulière des valeurs.

1. Le développement incrémental

Une caractéristique clé du projet agile, c’est son découpage en plusieurs incréments (nommés « sprints » dans la méthode Scrum ). Chaque «sprint» ou incrément est opéré comme un mini cycle en V, avec des objectifs définis et un ensemble de tâches à accomplir.
Non seulement l’équipe aura un sentiment d’accomplissement à l’issue de chaque incrément, mais le client final verra aussi des résultats d’avancement de façon plus régulière.

En donnant la priorité aux fonctionnalités à développer, les risques sont réduits très tôt, les fonctionnalités essentielles sont mises en valeur et l’équipe de développement comprend plus rapidement les enjeux du projet.
Enfin, les retours d’expérience sont encouragés et incorporés avant qu’elle ne devienne trop coûteuse à mettre en œuvre.

 

 

Trois réunions définissent un sprint : le sprint planning, le sprint review et la rétrospective.

• Sprint planning (planification de l’incrément) Il s’agit de déterminer les objectifs du sprint, sa durée et les tâches/fonctionnalités à valider en priorité. L’objectif d’un sprint est d’apporter un résultat concret pour la réunion de revue du sprint. De préférence, il devrait pouvoir livrer un ensemble de définitions techniques liées à des fonctionnalités. Les premiers sprints commencent par les aspects à haut-risques de la conception et la fonctionnalité essentielle du produit. De cette manière, on réduit activement les risques et on construit une bonne base pour la suite. Ne confondons pas objectif et tâche. Par exemple, «travailler sur la conception mécanique» n’est pas un objectif, c’est une tâche. Un bon objectif sprint d’un projet mécanique serait plutôt «étudier la faisabilité de la conception du boîtier prototype». Concernant la durée du sprint, c’est à l’équipe de décider. Les ingénieurs du groupe ALTEN ont trouvé qu’un délai de 2 semaines convient à la plupart des projets d’ingénierie, même si la littérature recommande 1-4 semaines.

Pendant la planification du sprint, en fonction de l’objectif défini, certaines tâches sont déplacées de la liste backlog vers la liste des tâches validées, et elles sont hiérarchisées. [ME = mécanique, EE = électronique et SW = logiciel]
 

L’ensemble des fonctionnalités/composants à développer pour le système, et des tâches associées, constitue une liste (le «backlog»). Cette liste est évolutive. Et à chaque incrément, en fonction de l’objectif défini, l’équipe de développement détermine lors de cette réunion les tâches du backlog à déplacer dans la liste des tâches validées. Ces tâches doivent être réalisées durant ce sprint. Par ailleurs, si une tâche n’est pas achevée après le sprint i, elle est reportée au sprint suivant i+1.

• Sprint review (revue de l’incrément) La revue de l’incrément clôture le sprint. Il ne s’agit pas d’une revue de validation formelle, mais elle permet au décideur ou au client final de visualiser l’avancement et les livrables.Cette démonstration de produit est la partie clé du sprint review. Bien sûr, dans le monde IT, elle est plus facile, avec par exemple une application mobile opérationnelle. Dans le monde hardware, la démonstration d’un produit peut se faire avec des schémas, des maquettes numériques 3D ou un prototype. C’est l’occasion pour le client final/décideur de donner des retours à l’équipe de développement. Avec un marché et des besoins qui changent, de nouvelles exigences peuvent être ajoutées, de nouvelles fonctionnalités sont ajoutés au backlog et de nouveaux objectifs sont définis pour le sprint suivant.
• La retrospective (Rétrospective de l’incrément) Cette réunion se déroule juste après le sprint review, ou bien juste après le départ du prochain sprint. L’équipe de développement peut profiter de cette occasion pour identifier les manières d’optimiser leur façon de travailler. Après avoir analysé si les actions définies par les précédents rétrospectives ont été bien mises en place, l’équipe doit se focaliser sur les questions suivantes : Qu’est ce qui fonctionne bien ? Qu’est ce qui n’a pas bien fonctionné ? Qu’est ce qu’on peut améliorer au prochain sprint? La meilleure manière de procéder c’est de faire un tour de table pour que chacun ait l’occasion de s’exprimer. Pour finir, on peut aussi leur poser la question : Qu’est ce qui vous rendra plus heureux au prochain sprint ? Cette question est très efficace pour révéler les problèmes cachés des personnes concernées par le projet.

2. Tableau de bord des tâches

Quand le sprint a démarré, les ingénieurs ont besoin d’un outil pour communiquer au sein de l’équipe, sur quelle tâche ils travaillent (au cas où les tâches sont dépendantes entre elles), et quel est le statut. Un tableau de bord constitue un outil idéal pour tracer ces tâches et communiquer les statuts. On peut utiliser un mur de post-it, mais on peut aussi utiliser Excel ou des outils numériques comme Trello Axosoft Jira

Toutes les tâches planifiées pour un sprint sont donc ajoutées à ce tableau de bord. Les différentes colonnes sont :

• Approved (approuvé) : ce sont les tâches assignées à la réunion sprint planning. Elles sont prioritaires. Les tâches les plus urgentes et les tâches inachevées au sprint précédent sont placées dans le Top de la hiérarchie de priorité.
• In Progress (en cours) : les ingénieurs de l’équipe travaillent actuellement sur ces tâches. Quand ils commencent, ils doivent donc déplacer la tâche de la liste «Approved» vers cette liste «In Progress». Idéalement, pour éviter le travail multi-tâches qui est inefficient, un membre ne devrait travailler que sur une seule tâche. Mais on sait que ce n’est pas toujours faisable.
• Blocked (bloqués) : l’avancement de certaines tâches peut être bloqué par des facteurs externes ou techniques. Par exemple, un retard de livraison de définitions ou de composants. Le chef de l’équipe ou les autres membres devront alors trouver des solutions alternatives pour débloquer la situation.
• In review (en validation) : quand un membre a terminé une tâche, il la déplace dans la liste en validation. Le validateur (ex : ingénieur système, chef de projet… ) vérifie le travail effectué vis à vis des critères définis dans la carte (que nous verrons juste après). Si c’est OK, il déplace la tâche dans la liste Complete, sinon il la déplace dans Approved pour que le membre réalise des correctifs nécessaires.
• Complete (achevé) : comme dit précédemment, tous les tâches validées sont achevées et rangées dans cette liste.

L’enjeu de l’équipe c’est de déplacer toutes les tâches de la liste Approved vers la liste Complete. Chaque tâche dans un sprint devrait durer entre une demi-journée et trois jours , et elle a une définition explicite quand elle est achevée. Le découpage des tâches demande un certain apprentissage. Avec une tâche mal définie ou trop grosse, on peut trouver à la fin du sprint des tâches « réalisé à 80% » ou « presque fini »…

Par exemple, des tâches haut niveau en conception mécanique / électronique peuvent être «Concevoir le boîtier» ou «Concevoir une carte électronique».
Mais si on décompose les tâches, ça donnerait :

Quand on utilise un tableau de bord des tâches digital, on recommande fortement d’associer à chaque tâche une carte. Cette carte contient des informations de la tâche comme : le titre, la description, la personne en charge, les sous-tâches et les critères de validation. En option, on peut également taguer la carte par une compétence (mécanique, électronique…) et les champs spécifiques au projet.

Avec ce système de tableau de bord, il n’y a aucune ambiguïté sur l’avancement des tâches et ainsi éviter des discours tels que « c’est fini à 90% » . Les tâches bloquées sont visibles par tous et donc encouragent leur résolution. Chaque tâche achevée donne un sentiment d’accomplissement au membre, et démontre l’avancement du projet au décideur/client final.

3. Les daily Stand-ups

Il s’agit des réunions rapides journalières réalisées par l’équipe (debout), afin de déterminer les possibles dépendances et les suivis qui en découlent. L’objectif était de repérer rapidement les problèmes afin de les résoudre le plus en amont possible. C’est très facile en théorie, mais dans la réalité, on peut très vite arriver à ça :

Il y a un certain nombre de best-pratics pour le bon déroulement des daily stand-ups, et pour les rendre utiles :

• Adapter le rythme : certains projets n’ont pas besoin d’une réunion journalière
• Limiter la durée de réunion à 15 minutes
• Utiliser le chef de projet ou l’ingénieur système pour assurer ces réunions : c’est eux qui ont la vue globale du projet et les spécifications du produit en tête
• Structurer la réunion : 15 minutes c’est court, alors chaque membre doit être concentré pour répondre aux questions suivantes : « Qu’as tu effectué depuis le dernier stand-up ? », « Qu’est ce que tu vas faire pour le prochain stand-up ? « , « Est-ce-que quelque chose bloque ? « 
• Regarder le tableau de bord des tâches : ce n’est pas le moment de le manipuler, c’est aux membres de le faire plus tard. La réunion permet à chacun de voir l’impact des statuts des tâches sur le travail des autres.
• Réserver le créneau pour la prochaine réunion de suivi

Pour mener à bien le daily stand-up, il faut absolument éviter d’être assis, d’avoir un tableau de bord non à jour, d’être hors sujet, ou d’avoir trop de personnes impliquées.

 

4. Démonstration régulière de valeur

L’objectif d’un projet de développement c’est de livrer au client final, la valeur, de la façon la plus rapide et la moins coûteuse possible, tout en garantissant l’excellence de qualité du produit.

Avec l’approche du cycle en V traditionnel, le peu de fois où le donneur d’ordre voit un livrable, beaucoup de décisions ont déjà été prises et figées dans la conception. Si le donneur d’ordre est en désaccord avec les décisions de l’équipe de développement, cela peut aboutir à des échanges houleux sur les changements de spécifications… C’est pourquoi Syncroness utilise le concept « Démonstration régulière de valeur » :

• Démonstration : c’est de pouvoir montrer des fonctionnalités / composants développés depuis le dernier sprint. Il n’y a pas besoin d’avoir le produit fini. Toutes les démonstrations de livrables ajoutent de la valeur.
• Valeur : «Toute la valeur d’un projet réside dans les livrables». Un livrable c’est quelque chose de concret qui contribue à la commercialisation du produit. Une spécification, une décision, un schéma, une maquette numérique, un prototype ou un bout de logiciel embarqué sont des livrables. Un livrable diffère d’une activité ou d’une tâche.
• Régulière : Le fait de produire des livrables et des démos, vous donne l’opportunité de rencontrer régulièrement le client final/donneur d’ordre. L’équipe de développement peut confronter fréquemment leur conception aux besoins du donneur d’ordre. La conception est rendue plus robuste tout au long du projet.

Quelle forme peut prendre un livrable en ingénierie de systèmes électroniques et mécaniques ?

• Conception mécanique : les schémas de Brainstorming, les ébauches, les maquettes numériques 3D, les calculs de structure ou les prototypes rapides.
• Conception électronique : les schémas, les analyses de simulation, les routages, les platines d’expérimentation, ou les prototypes d’assemblages PCB.
• Général : le choix des fournisseurs, la nomenclature (BOM), les estimations de coût, ou les estimations de délai.

Chaque livrable cité ci-dessus, quand il est réalisé, nous rapproche d’un pas du produit final abouti. Avec ces nombreux livrables qu’on confronte au donneur d’ordre, nous réduisons les risques et les incertitudes, sans pour autant avoir le besoin de construire un prototype coûteux.

Dans le domaine du système embarqué, les prototypes intégrés jouent un rôle extrêmement important.
Leur construction permet à l’équipe de mieux comprendre l’assemblage réel, le comportement du système, les interactions entre différents compétences, les compatibilités d’interface, etc.

Faire coïncider la démonstration de ces prototypes avec les Sprint reviews demande un peu de planification anticipée, comme le rythme diffère entre les équipes de développement logiciel embarqué, de conception mécanique et de conception électronique.

 

 

 

2 exemples de projet d’ingénierie réalisés par ALTEN avec ces méthodes Agiles

Syncroness , filiale du groupe ALTEN, a pu réaliser plusieurs projets de développement de système embarqué, avec l’approche Agile ci-dessus. En particulier, les ingénieurs du groupe ALTEN ont développé, de A à Z, un contrôleur de moteur pour un fabricant spatial spécialisé dans les antennes et les panneaux solaires déployables, et des systèmes avioniques critiques pour l’industrie des lanceurs.

• Satellite – contrôleur de moteur : Un nouveau client a proposé à Syncroness de concevoir, fabriquer, assembler, tester et livrer une unité de démonstration technique (EDU, engineering demonstration unit) et un modèle de vol (FM, flight model), avec un délai de 7 mois et un budget fixé. Le produit doit être extrêmement fiable, de haute qualité et doit répondre aux exigences rigoureuses de l’aérospatiale américaine (norme AS9100). Afin de respecter ces contraintes, Syncroness a décidé d’aborder le projet avec les méthodes Agiles. L’approche «démonstration régulière de valeur» a permis d’entretenir une relation de confiance avec ce nouveau client. La meilleure validation de notre approche a été le mot du client durant les phases de test et de livraison : «the controller continues to be a rock of reliability» (« le contrôleur continue d’être un pilier de fiabilité »). Et la performance du contrôleur a été au rendez-vous.
• Lanceur – avionique : Syncroness a également utilisé l’approche Agile pour développer des systèmes avioniques pour les lanceurs spatiaux, comme un séquenceur de mise en orbite des satellites ou encore un système de mission. Le client a été satisfait de notre méthodologie et de notre avancement pour le développement de ses systèmes embarqués critiques, malgré un «planning agressif».

Grâce à l’application de cette méthodologie, les ingénieurs du groupe ALTEN ont pu développer le hardware dans le temps et budget impartis. Les avantages des méthodes Agiles appliquées à un projet d’ingénierie sont :

• Un développement produit plus rapide
• Des livrables de meilleure qualité
• Une réduction des risques
• Une meilleure collaboration entre les équipes d’ingénieurs et les parties prenantes
• Des étapes de projet plus transparentes et exactes

Publication sur AIAA :  Agile Hardware Development Approaches Applied to Space Hardware