Transition agile d'une organisation Eric Gauthier et Eric Le Merdy

1. Mardi 17 Novembre 2009
Paris, la Défense
LEAN Développement – Témoignage
Thales Aerospace
Eric GAUTHIER,
Expert Ingénierie Logiciel & Système
Thales
eric.gauthier@thalesgroup.com
Michel BAUJARD,
Lean Engineering Expert
Thales Aerospace
michel.baujard@fr.thalesgroup.com

2. Sommaire
• Présentation de THALES
• Pourquoi une approche Lean en développement
• Témoignages
#2

3. Profil de THALES
Leader mondial des systèmes d’information critique
Trois marchés principaux
• Aéronautique et Espace
• Défense
• Sécurité
} 12,7 milliards d’euros
Un groupe mondial
• Effectif mondial : 68 000 personnes
• Présence dans 50 pays

4. Trois domaines principaux
Défense
50 %
„ Air
„ Terre
„ Naval
„ Interarmées
Aéronautique et Espace Sécurité
25 % 25 %

5. Trois domaines
Trois domaines définis par leurs marchés
Aéronautique Espace Défense Sécurité
Aéro- Espace Systèmes Systèmes Naval Solutions
nautique aériens Terre et de Sécurité
Interarmées et Services
Une organisation cohérente
Expertise technologique et présence internationale au service de nos clients

6. Des problèmes couramment constatés
Des risques en
Architecture
Contract • Une architecture
Customer non explicite Qualification
Needs
SSS • Des justifications
inaccessibles ou
Requirements perdues Validate
Architecture
• Des analyses
• Des ingénieries Design
SS
DD d’impact non
en “silo” disponibles
Verify
• Une approche • Des aléas en
centrée sur les integration
documents Integrate
Specify
Components • Beaucoup de papier!
• Des problèmes de management
de données et de maîtrise des
configurations
• Des informations dupliquées
dans de nombreux documents
Mise à jour et cohérence?
S RS • Pour une modification, une
S DD forte propagation dans les
documents
Coût élevé, faible valeur
ajoutée
Software Specification Software Design Evolution difficile

7. Pourquoi une approche Lean en développement?
lesifs) • Fonctionnalité non attendue par le client
mpaust • Document trop détaillé
xe exh
E n • Tâche réalisée trop tôt • Design repris car exigence
(no client mal définie ou comprise
• Transmission d’informations
6XU
• Circuit de décisions complexe VSpFLILFDWLRQ incomplètes
• Très nombreuses interfaces 5HZRUN
• ‘Stop Go’ activities
7UDQVIHUWV
LQXWLOHV • Tâches redondantes
*DVSLOODJHV 6XU • Réinvention de
3URFHVVXV l’existant
• Attente de décisions
$WWHQWHV
2XWLOV
• Retards dus à la
surcharge des ressources 7UDYDLO LQDGDSWpV
• Engorgements LQDFKHYp
• Procédés non fiables
• Solutions non testées • Accès difficile à l’information
• Document non validé
• Désynchronisation des tâches

8. Les principes Lean
Valeur: Du point de vue du client, spécifier ce qui lui apporte de la
valeur
Æ Développer le bon produit
Flux de Valeur: Identifier les étapes créatrices de valeur, éliminer le
reste
Æ Développer sans gaspiller!
Flux continu: Faire en sorte que les étapes créatrices de valeur se
déroulent en une séquence continue et serrée
Æ Développer vite!
Flux tiré: Laisser le client tirer la création de valeur à sa demande
Æ Être réactif aux besoins du client
Perfection: Rechercher la perfection par l'amélioration continue

9. La méthode utilisée pour Lean development
3 - Analyse
2 - Measure
4 - Improve
1 - Define
5 - Control
6 - Standardize

10. Plusieurs étapes possibles : recommandé!
Agile (système avec
logiciel), optimisation
métier
“Chasse au
gaspillage”
Management
visuel,
pilotage au
quotidien

11. Plan sponsorisé Direction Opérations
Environ 4000 personnes concernées: (France, UK, US, Allemagne)
Ingénieries système, logiciel, matériel…
2007 2008 2009 2011
Projets isolés, Equipes projet Value
par métier intégrées streams
Approche Bottom–up Focalisation sur les • Produit et système
Projets lean locaux projets et systèmes • RAO au support
. Industriel
. Développement
+ Approche Top-down
Lean Enterprise

12. 100 Projets Lean depuis 2008
56 projets lean
en 2009
45 projets
lean en 2008
130
personnes
formées
140
managers
sensibilisés

13. Exemple d’un projet Lean 1/4
Respect de la méthodologie « DMAIC »
La charte du chantier:
Lean Project Charter
IESI V2 - IVVQ
Problem description: Pilot: E. BOINOT (RIS)
Les travaux d'IVVQ dépassent souvent en terme de délai, et de coût Sponsor: F. GARDERE (Chef de Service) - Y. JACOBS
(rework car pb détectés tardivement) Coach: O. GUILLEMAILLE
Team: J. PAPINEAU (WPM)
Purpose of the project: JP. VITRAS (IS)
P. KERSULLEC (WPM HW EL)
Tenir les délais du projet, en maîtrisant les risques et les coûts D. CHAILLOU (HWE)
avec exhaustivité dans la vérification, sans déroger sur la levée des pb Proconseil (A. FERCOQ) - supprimé
Perimeter of the project: Additional resources:
IVVQ, intégration, vérification et essais constructeur en environnement
(dont Safety Of Flight)
dont procédures (et mise à jour des plans si nécessaire) D. BRANGER (IS)
Périmètre HWE et produit C. IZARD (RT SW)
Levers of the project: F. JEULIN (PLD)
Regroupement de tests, automatisation, moyens, documentations
(procédures, rapports) … B. BELLON
Parallélisation des travaux, réduction des redondances JL. BRICOUT (Essais Environnementaux)
Tests fonctionnels, limite HW/produit-système Start Date:
Objectives of the project: Gate 0: 21/03
Réussir la mise en service de l'IESI V2 sans défaut de maturité Gate 1: 1/04
Détecter les problèmes potentiels au plus tôt (éviter les rework) Gate 2: W16
Tenir fin des essais constructeurs au 30/10/2008 avec un coût IVVQ
200k€: gain de 100k€ Gate 3: W17
Tenir les coûts et délais de la qualification 2009 Gate 4: W18
Stop Date: 15/07 Integration
Risks of the project: 30/08 Essais constructeurs
Nombreuses innovations nécessitant une exhaustivité accrue, une
maîtrise des risques efficace et pilotée Specific items:
Référence sur intégration incomplète - Indisponibilité des personnes
Décision de séparation du chantier en 2 parties:
D Intégration-vérification / Essais constructeurs

14. Exemple d’un projet Lean 2/4
SIPOC Initial
Î SIPOC formalisé
SIPOC Intégration (Outil)
Suppliers
Suppliers Inputs Process
Process Outputs Customers
Customers
Réactivité
Visite IDI
IDI Stock composants
Stock composants Réalisation procédure Procédure de test
Procédure de test Equipe produit
Tronico de test Formation Equipe produit
Test in
JTAG - LVDS
situ/takaya
HWE PLD
HWE PLD Procédures de test
Procédures de test
Debug carte HW 2 protos HW Equipe SW
Equipe SW
Cartes Où est le 2 protos HW
rallonge
labo?
ALTERA
ALTERA PLD opérationnel
PLD opérationnel Nbre
Test cartes 1 proto produit
1 proto produit protos?
SIPOC: VSM:
MYE
MYE PLD de test
PLD de test Validation
cartes (PSU,
OPM, FIB,
ATP? SW IESI intégré
SW IESI intégré
UMI) Intégration HW-HW
Experts externes
Experts externes Protos HW (2)
Protos HW (2)
Protos L1.0
Protos L1.0
* Supplier * Value Stream Mapping Intégration HW-SW
vérifié et intégré
vérifié et intégré
Equipe SW
Equipe SW Protos produit (1)
Protos produit (1)
* Input SW téléchargement Outils JTAG
Ointégration carte
+ PLD
SW téléchargement
* Process PC
PC
Ressources
Outil utilisé en
Lean Dev INT - 27/01/2009
* Output SW de test
SW de test
Logiciel
HWE
Ressources
Log
problèmes
préparation
déverminage inexpérimentées
* Customer S Fournisseur
ou LMEO
Nb protos du VSM …
I Entrée
D
P Processus
O Sortie
D
C Client
7 Aerospace - TBU INT

15. Exemple d’un projet Lean 3/4
Å Le VSM initial ….
Le diable se cache
dans les détails
Bonne implication de l’équipe
VSM final …
M A

16. Exemple d’un projet Lean 4/4
Stratégie d’intégration définie
Cartes seules Cartes + PLD PLD+logiciels Vérification formelle Produit
110 130
PLD TCP (hors SW) Perfos Octave
06/06/08 12/06/08 17/06/08 30/06/08
5j 0% 32j 10j 0% 0j
18 170 224
Préparation intégration Carte MOB - Vérification Modif carte MOB pour EFF
23/05/08 03/07/08 16/07/08 16/07/08 16/07/08 16/07/08
30j 0% 0j 0j 0% 48j 0j 0% 48j
40 221
Carte DB - Intégration OSP ( flash série)
30/05/08 05/06/08 17/06/08 30/06/08
5j 0% 0j 10j 0% 23j
90 120 160
PLD Octave - OSP Tests internes SW Carte IOB - Vérification
10/06/08 16/06/08 16/06/08 16/06/08 16/07/08 16/07/08
5j 0% 0j 0j 0% 23j 0j 0% 48j
220
Si pb DDR, SW en RAM interne
17/06/08 23/06/08
5j 0% 25j
10 20 50 70 100 140 141 180 200 225
T0 Intégration Intégration carte convertisseur DB Carte MOB - Intégration Carte DB/MOB - Intégration Carte DB+MOB+IOB Mise au point Driver Bas niveau Driver DB Mise au point SW CC Mise au point SW Appli Qualification envir - Vérif produit
LVDS
23/05/08 23/05/08 23/05/08 29/05/08 30/05/08 05/06/08 06/06/08 09/06/08 10/06/08 11/06/08 24/06/08 26/06/08 01/07/08 16/07/08 17/07/08 06/08/08 07/08/08 11/08/08 23/09/08 03/11/08
0j 0% 0j 5j 0% 0j 5j 0% 0j 2j 0% 0j 2j 0% 0j 3j 0% 25j 12j 0% 23j 15j 0% 23j 3j 0% 23j 30j 0% 0j
229 223 222 150 210
Intégration UMI-bloc optique-P90 SW driver LVDS IOP avec SW Carte DB - Vérification Produit - test préliminaires
11/06/08 11/06/08 26/06/08 26/06/08 26/06/08 26/06/08 16/07/08 16/07/08 12/09/08 22/09/08
0j 0% 0j 0j 0% 37j 0j 0% 37j 0j 0% 48j 7j 0% 0j
60 80
Carte IOB - Intégration Carte MOB/IOB - Intégration
30/05/08 05/06/08 06/06/08 09/06/08
5j 0% 0j 2j 0% 0j
230 190
Mesure des signaux PLD - Vérification
11/06/08 11/06/08 17/07/08 30/07/08
0j 0% 0j 10j 0% 38j
226 227
Livraison OPM - CMO Intégration OPM/produit
21/07/08 21/07/08 05/09/08 11/09/08
0j 0% 34j 5j 0% 0j
228
Livraison EFF
05/09/08 05/09/08
Réduction
0j 0% 0j
des reworks
Actions principales Commentaires Bénéfices
Optimisation des tests « cartes seules » et des Mise en place de ressource HWE Réduction de cycle
1 tests « cartes + PLD » et matérielle
I 2
Parallélisation des intégrations HWE + PLD
(suppression des risques de rework)
Gestion de configuration et niveau
de tests clarifiés aux interfaces
d’équipe
Réduction de risque
3
Mise en place d’un logiciel de mise en œuvre Logiciel outillage pour activation Optimisation
des E/S PLD
C

17. Des ressources décentralisées pour animer
Leader Unité
ou Coach Lean
Unité/Site
Adjoint Expert Lean
Région Unité/Site
Sud Ouest France Région Paris
Chef de projet Coaching coaching, Unité/Site
Formation Formation,
Michel Baujard Communication
Unité/Site
Pilotage projet Unité/Site
Lean Développement
Unité/Site
Unité/Site
Unité/Site
Germany
UK
US Canada

18. Typologie des projets lean: Problématiques
Problématiques Applications typiques
Transition entre phases d’un RAO Développement
programme Développement Production 10%
Interfaces entre métiers HW / SW; IS / SW; IS / HW
Outils ou Bancs 30%
Prototypes
Maturité des produits Obsolescences
Politique Produit 5%
Stabilité des exigences
Team-Building / équipe intégrée Planification entreprise
PERT 40%
Préparation IVVQ
Processus Séquentiel / Itératif / Récurrent 10%
Périmètre externe à DAe Clients / Fournisseurs
Autres Divisions du Groupe 5%

19. Typologie des projets lean : Phases
V descendant V montant
• IS / • Intégration / Validation
Orga.documentaire • Rework
• Conception de cartes • PERT
• Revues SW • Préparation Qualif
9Ô Ò 50%
25% 9
6XSSRUW
Support
25% • Gestion des Faits Techniques
• Circuit de validation / Signature
• Processus de Codification

20. Typologie des projets lean : Profondeurs
Durée Effort Atelier Impact / Enjeu
1Jour 5 ateliers Chantier découverte du Lean pour l’entité
1 mois 40%
/participant x 2 heures Améliorations par la pratique partagée
Appropriation et optimisation d’un
3Jours 10 ateliers processus par une équipe 40%
2 mois
/participant x 3 heures Team-building par le travail partagé autour
d’un enjeu commun
Remise en cause et re-définition d’un
8Jours 20 ateliers processus 20%
3 mois
/participant x 4 heures Remise à plat d’une organisation (entité ou
programme)

21. Témoignage
Une équipe de développement « lean »

22. Plusieurs types de formation
« Découverte » : 1HZ
H
Durée : 2 H /HD Q *DP
Objectif : Sensibiliser
Contenu : enjeux, principes, exemples
« Participer » Sur site
Durée : 1 jour
Objectif : Participer à un projet lean,
le démarrer / informer
Contenu : séquence type, outils, retours
d’expériences
« Animer » Thales University
Durée : 2 à 3 jours
Objectif : Former les animateurs et chefs de projet
Contenu : Etude de cas
3OD
]HUR WKH
Z
By JDPHDVWH
Aerospace Division

23. Mardi 17 Novembre 2009
Paris, la Défense
Développement Lean Agile
Retour d’expérience
Eric GAUTHIER
Expert Ingénierie Logiciel Système
THALES
eric.gauthier@thalesgroup.com
Eric LE MERDY,
Consultant
VALTECH
eric.lemerdy@valtech.fr

24. Message 1 : Il suffit de se lancer
Logo partenaire
(si besoin)

25. Comment démarrer ?
« Déclic »
Approche projet pilote « bottom-up »
• Le succès du pilote doit servir à disséminer les pratiques
Organisation
Programme Programme
Sub-System 1 Sub-System 1
Sub-System 2
Sub-System 2
Sub-System 3 Sub-System 3 Sub-System 3
Logo partenaire
(si besoin)

26. Message 2 : Notre expérience
Logo partenaire
(si besoin)

27. D’où partons-nous ?
Projet pilote en 2007 : XP
• Pratiques non maintenues : changement d’équipe, moins de
convictions, manque de recul
Nouvelle tentative à partir de mai 2009 sur le même projet
• Taille du projet de plus en plus importante
• Afin d’optimiser les efforts en phase d’intégration (fin de l’effet « big
bang »)
Quelles ont été les pratiques déployées ?
Logo partenaire
(si besoin)

28. Convaincre l’équipe
Adhésion aux valeurs de l’approche Agile
La culture d’équipe initiale était compatible de ces valeurs
Commencer à pratiquer
Nous avons commencé doucement…
Les « quick win » sont faciles à obtenir
Profiter des résultats !
Plus aucun défaut détecté en validation formelle au bout de la 4°
itération
La confiance grandit…
Logo partenaire
(si besoin)

29. Pourquoi faire son marché aux pratiques ?
Eviter l’effet « Ce n’est qu’une nouvelle méthode de plus… »
« Coaching » avec un équipier qui connaît bien les méthodes agiles
Montrer l’intérêt de l’approche pour renforcer l’engagement de
l’équipe
Logo partenaire
(si besoin)

30. 1. Le “fini-fini” de l’équipe
très
utile
Travailler sur la définition du “fini-fini”
…dans l’environnement Thales
Ce que définit
une action
“terminée”
…Ressemble à un mini-cycle en V pour chaque tâche
Publier sur le Kanban en A3 !
Logo partenaire
(si besoin)

31. 2. Communication
très
utile
Stand-up meeting
Chaque 2 ou 3 jours, le matin
utile
Sprint planning meeting
Partage de connaissance sur l’analyse au début d’itération
très
Retrospective utile
L’amélioration continue en marche !
Pair-programming
Seulement lors d’un problème technique complexe
Logo partenaire
(si besoin)

32. 3. Qualité intrinsèque
très
utile
Tests “croisés” continus
Chaque changement est “challengé” par un autre équipier
utile
Re-passage des tests formels en fin d’itération
Juste au cas où…
utile
Couverture de test dans l’outil et au tableau
Plus de surprises, écriture des fiches de test en continu
Logo partenaire
(si besoin)

33. 4. Outils ?
utile
Management visuel = “Radiateur d’informations” = kanban
Maintient l’équipe concentrée et concernée par le backlog
utile
Wiki
Outils classiques de gestion de projet
Logo partenaire
(si besoin)

34. Artefacts du project
Un fichier texte pour les stand-up meeting : affectation des tests croisés
En l’absence du Kanban…
Un fichier texte pour la Release Note, basé sur la Gestion de Configuration
Pas de tâches réalisées et oubliées
Un fichier texte pour le rapport de rétrospective
L’équipe voit la valeur ajoutée de l’approche
Couverture des tests avec Excel
Garantir la couverture, assurer un mixage des tests croisés
Logo partenaire
(si besoin)

35. Vers une dissémination des pratiques:
Pourquoi cela a-t-il marché pour nous ?
Une équipe avec l’esprit ouvert, pas de problème pour apporter du
changement, environnement basé sur la confiance
Le support du management
Les équipes se sont montrées volontaires (effet « tâche d’huile »)
Chef de projet prêt à partager ses connaissances et ses
responsabilités avec l’équipe
Phase de consolidation du produit confortable pour instaurer les
changements
Logo partenaire
(si besoin)

36. Selon l’équipe…
« L’agilité, c’est du bon sens appliqué au développement itératif »
« Je commence à croire à mon produit et en notre équipe »
« Je vais mettre ces 2 mois de pratique agile en haut de mon CV ! »
Logo partenaire
(si besoin)

37. Message 3 : C’est un long chemin
Logo partenaire
(si besoin)

38. Améliorations en cours…
Fragilité du « fini-fini » (documentation continue)
Effort à fournir sur la testabilité automatique du logiciel
Besoin de prendre de la maturité sur les estimations d’effort
La métrique devrait être basée sur
une unité relative d’estimation (feature point, story point)
Logo partenaire
(si besoin)

39. Déploiement au programme
On veut du concret !
• Production d’un rapport A3 pour supporter le changement
Augmentation de la satisfaction client
• Amélioration sensible de l’ergonomie, de la performance, de
l’utilisabilité du produit
Le retour d’expérience en interne suscite des envies
Logo partenaire
(si besoin)

40. ms s
yste tem
b-s ys
Su b-s
Su
Logo partenaire
(si besoin)

41. Des questions ?
Logo partenaire
(si besoin)