SlideShare une entreprise Scribd logo
RAYNET SNC / Agile Grenoble 2012
Qualité: Stop à la procrastination
             Agile Grenoble 2012
             L. Dupanloup - F. Chaminand




RAYNET SNC
Procrastination
                       Nom féminin

                       Tendance pathologique à différer, à remettre
                       l’action au lendemain.




                                                               Source: www.larousse.fr




RAYNET SNC / Agile Grenoble 2012
Les procrastinateurs


                                                       Fabrice Chaminand
                                                       ScrumMaster




                                   Laurent Dupanloup
                                   Product Owner
                                   Project Manager




RAYNET SNC / Agile Grenoble 2012
Agenda

                                   Phase 1: Procrastination - contexte

                                   Phase 2: Formation

                                   Phase 3: Stratégie

                                   Phase 4: Mise en suspens

                                   Phase 5: Action rattrapage

                                   Phase 6: L’équilibre

                                   Conclusion



RAYNET SNC / Agile Grenoble 2012
Phase 1 : Procrastination - Contexte


                                   Phase 1: Procrastination - contexte

                                   Phase 2: Formation

                                   Phase 3: Stratégie

                                   Phase 4: Mise en suspens

                                   Phase 5: Action rattrapage

                                   Phase 6: L’équilibre

                                   Conclusion



RAYNET SNC / Agile Grenoble 2012
Phase 1 : Procrastination - Contexte


                                                     Le produit

                      Suivi de la production et traçabilité dans les ateliers (automotive)

                      Env. 1000+ instances à travers le monde

                      Production en 24/24h, 7/7j




RAYNET SNC / Agile Grenoble 2012
Phase 1 : Procrastination - Contexte


                                                    Le projet

                    Démarrage cycle en V

                    Migration vers l’agilité en cours de projet

                    Projet en cours, début de mise en production

                    50 000 lignes de code

                                    Très peu de tests automatisés / code peu testable


RAYNET SNC / Agile Grenoble 2012
Phase1 : Procrastination - Contexte


                                                Situation

                  Pour le PO :
                              Régression  frustration

                  Pour les développeurs :
                              Refactoring cassant  frustration

                  Pour le client :
                               Avenir très incertain




RAYNET SNC / Agile Grenoble 2012
Phase 2 : Formation


                                   Phase 1: Procrastination - contexte

                                   Phase 2: Formation

                                   Phase 3: Stratégie

                                   Phase 4: Mise en suspens

                                   Phase 5: Action rattrapage

                                   Phase 6: L’équilibre

                                   Conclusion



RAYNET SNC / Agile Grenoble 2012
Phase 2 : Formation

                          Motivations
                             Prise de conscience sur la nécessité d’implémenter des tests
                               automatisés
                             Mise en production imminente

                          Décisions
                             Formation « TDD » sur l’implémentation des tests unitaires
                             Apprentissage : « Comment faire du code testable »
                             Mise en place de quelques tests




RAYNET SNC / Agile Grenoble 2012
Phase 2 : Formation

                  Activités
                     2h de workshop par semaine :
                          pour toute l’équipe développement
                          Binômage

                  Résultat
                     Le nouveau code est plus testable
                     Beaucoup de temps passé versus couverture de test faible




RAYNET SNC / Agile Grenoble 2012
Phase 3 : Stratégie


                                   Phase 1: Procrastination - contexte

                                   Phase 2: Formation

                                   Phase 3: Stratégie

                                   Phase 4: Mise en suspens

                                   Phase 5: Action rattrapage

                                   Phase 6: L’équilibre

                                   Conclusion



RAYNET SNC / Agile Grenoble 2012
Phase 3 : Stratégie

                   Motivations
                      Budget qualité limité
                      Planning serré
                      Nécessité de cibler les tests -> Dépenser au bon endroit

                   Décisions
                      Identification des fonctionnalités critiques
                      Choix des fonctionnalités à tester en priorité
                      Analyse des composants logiciels impactés
                      Choix du type de test et estimation des coûts
                      Sélection des composants : Les moins coûteux et gains importants




RAYNET SNC / Agile Grenoble 2012
Phase 3 : Stratégie
                          Identification des fonctionnalités critiques
                                                                                                                          use cases
                                                                                             Worrying
         Who         What                             Details                        Where    after                                                        Downgraded mode, workaround
       Operator    To have the list of the POs and next PO notification up to date   RM      1h         none
       Operator    To supervise the current operation
                                 Change of batch                                     RM      15mn       ALT-F4; unplugg the machine; start again the same operation and close it (red cross); call controls engineer (marking); call CIP for data correction
                                 Change the operation                                RM      15mn       ALT-F4; unplugg the machine; start again the same operation and close it (red cross); call CIP for data correction
                                 Input a comment                                     RM      1d         paper
                                 Consult the comments                                RM      1d         paper
                                 Modify the status                                   RM      1d         none
                                 Process the HUs (recording, printing,…)             RM      1h         manual printing; none for creating/modifying Hus; Poogle+…
                                 Manage the Quality controls                         RM      1h         call controls engineer (unblock after first sampling); SAP GUI; manual unblocking in Raypro
                                 Change the HU type                                  RM      2h         None today; tomorrow :Poogle+… and manual printing;
                                 View operation details                              RM      7d         Supervision
                                 Print manually the label                            RM      7d         Supervision
                                 Send the setup                                      RM      15mn       call controls engineer; tomorrow add capability to edit et re send the parameters in RM
                                 View header information                             RM      8h         paper
                                 View notifications                                  RM      2h         paper
                                 View status (current and history)                   RM      1d         none
                                 View graph of productivity                          RM      7d         none
                                 View graph of quality                               RM      7d         none
                                 View defect counters                                RM      1d         PLC
                                 View batch info                                     RM      4h         paper; none
                                 View misc info                                      RM      8h         none
                                 View components list                                RM      3d         paper
       Manivelle   To setup the operation for material & WC                          RS      4h         today none; tomorrow add capability to edit et re send the parameters in RM
       Manivelle   Definition of the material                                        RS      8h         if by import, do it manually; if manual, none
       CIP         To add/modify hardware configuration                              RS      1d         None but a lot of XML export/import functionnalities exists
       The boss    To obtain productivity information (screen)                       RS      1d         shop floor
       The boss    To obtain productivity information (reports)                      RS      3d         paper
       Manivelle   To block/unblock batches/HUs                                      RS/RM   4h         CIP
       Manivelle   To validate the calendar                                          RS      2d         none
       Manivelle   To be informed about the last 24/48h running                      RS      2d         shop floor



RAYNET SNC / Agile Grenoble 2012
Phase 3 : Stratégie
                              Identification des composants impactés




RAYNET SNC / Agile Grenoble 2012
Phase 3 : Stratégie
                                   Analyse de testabilité des composants
                    Block            Projet               Risques                             Moyens                               Coût                                  Rq                                                                Action
                                                                                                                                                 Refactoring a bcp de valeur pour ajouter des
              UI                   Machine       Faible                       TU                                          très elevé             fonctionnalités (synchro supervision de l'atelier :
                                                                                                                                                 story à venir en R4)



                                                                                                                                                                                                       Part 1 : garantir règle métier => regrouper les entités model (packaging,
                                                                                                                                                                                                       handling unit, operation, workcenter, etc...toutes les WFEntities) concernées
                                                                                                                                                                                                       par WFModel , défniir leur dépendances pour etablir la sequence dans laquelle
                                                                                                                                                                                                       elles doivent être sauvegardées. Tester que pour chaque entité commitée, cet
                                                                                                                                                                                                       ordre de sauvegarde est respecté.
                                                                                                                                                                                                       Part 2 : garantir unicté de l'instance d'entité manipulée : Gérer un dictionnaire
                                                 moyen (regles metiers, chagt TU + definition de regles à introduire dans                                                                              de WFEntity et ne créer une nouvelle instance que si absente du dico. Attention
             WF Entities           Machine       de status)                   les entités                                 faible                                                                       aux perf! gérer la durée de vie des WFentity dans ce dico



                                                                                                                        en l'etat de nos
                                                                                                                        connaissances,coût TU
                                                                                                                        elevé du fait de la
                                                                              TU sur workaround + regle sur ajout/modif dépendance à
                                                                              dans schema (limiter les dependances) + Nhibernate. UPDATE :
                                                                              definir des workaround (sur le save,      on maitrise maintenant
                                                                              checker les dependances, sauvegarder ce la testabilité des                                                               Identifier les entités et leurs relations (analyse) => identifier les entites qui ne
                                                                              qu'on peut et lever un warning) + regle   services dépendant                                                             doivent pas etre transient sur un SaveOrUpdate => TU sur cette méthode avec
                                                                              d'equipe sur le passage obligé par        d'Nhibernate => Cout                                                           fake sur entité et repo (transient or not)
              Business Services    Machine       moyen                        commande pour toute modif de donnees faible                      en fait c'est un DAL                                    Si SaveOrUpate failed => remonter l'exception

                                                                                                                                                 Peu de raisons de toucher au scheduling
                                                                                                                                                 code existant Lourd et peu flexibles , peu de
                                                                                                                                                 classes pour neaucoup de responsabilités =>
                                                                                                                                                 moyens limités, impact fort
                                                                                                                                                 Axer le test sur CommandeInvoker et pas
                                                                                                                                                 WFConnector
                                                                                                                                                 Tester le méchanisme et non les commandes
             WF Engine             WF Engine     élevé (si on y touche)       TU => refactoring                           moyen (à confirmer)    Définir ce qu'il faut tester                          y
                                                                                                                          élevé :
                                   WF                                                                                     normalisation lourde
                                   Communicatio                               Normaliser les commandes + "Boite à         beaucoup de
             WF Commands           n            faible à moyen                tester la norme"                            commandes              Tester les différentes commandes + la norme
                                                                              Outil de test des workflows + écriture des
                                                                              cas, normaliser les worklows (idem                                 Le workflow en lui-même
                                   Raypro.Worklo                              commandes) + règles d'utilisation des                              Outil similaire développé par Thales (Charlotte
             Workflows             w.Specific    très élevé                   activités                                  élevé                   Gaidon, cf Jérémie Gomez)                             Définir un backlog pour l'outil de test des workflows
                                   WFCommunica
             Machine Commands      tion          faible                       TU                                          faible
                                   Abstract                                                                               moyen (Construction
             Abstract Machine      Machine       faible                       TU                                          des devices)
                                   Abstract                                                                                                      script de contrôle des I/O générés pour un
             Device (Business)     Machine       élévé                        TI Automatisé                               élevé                  comportement métier donné
                                   Abstract
                                   Machine +                                                                                                     application de TI pour chacun des device
             Device (Hardware)     Wrapper       faible à moyen               TI (drivers simulé, simulateur, ….)         (très) élévé           independemment les uns des autres



RAYNET SNC / Agile Grenoble 2012
Phase 3 : Stratégie


                    Activités
                       2h de workshop par semaine
                           Toute l’équipe projet
                           Planning + implémentation



                    Résultat
                       Liste de tâches cibles à faire en workshop
                       Format workshop mal adapté à l’implémentation




RAYNET SNC / Agile Grenoble 2012
Phase 4 : Mise en suspens


                                   Phase 1: Procrastination - contexte

                                   Phase 2: Formation

                                   Phase 3: Stratégie

                                   Phase 4: Mise en suspens

                                   Phase 5: Action rattrapage

                                   Phase 6: L’équilibre

                                   Conclusion



RAYNET SNC / Agile Grenoble 2012
Phase 4 : Mise en suspens

                   Motivations
                      Baisse de capacité non prévue
                      Changements non prévus sur les fonctionnalités
                      Date de livraison figée

                   Décisions
                      Suppression temporaire des workshops Qualité jusqu’à livraison

                   Résultat
                      Livraison dans les temps
                      Augmentation de la charge de tests manuels de non régression
                      Besoin de refactoring encore plus pressant



RAYNET SNC / Agile Grenoble 2012
Phase 5 : Rattrapage


                                   Phase 1: Procrastination - contexte

                                   Phase 2: Formation

                                   Phase 3: Stratégie

                                   Phase 4: Mise en suspens

                                   Phase 5: Action rattrapage

                                   Phase 6: L’équilibre

                                   Conclusion



RAYNET SNC / Agile Grenoble 2012
Phase 5 : Rattrapage

                    Motivations
                       Livraison effectuée
                       Besoin de rattraper le retard en terme de Qualité
                       Ressources supplémentaires
                       Bugs critiques dans le backlog nécessitant du refactoring

                    Décisions
                       Création d’un backlog de story Qualité :
                            sur les fonctionnalités critiques
                            sur les fonctionnalités récentes (Garantie testables)
                       Premier sprint avec 50% de story Qualité
                       Story Qualité comptabilisées à 0 point dans le sprint



RAYNET SNC / Agile Grenoble 2012
Phase 5 : Rattrapage

                   Activités
                      Intégration des story au storyboard.
                      Code review pour valider les Story Qualité

                   Résultat
                      Nouveau code testé
                      Mauvaise répartition de l’effort :
                          Beaucoup de temps passés sur les story Qualité moins critiques
                          Pas assez de disponibilités des « experts » sur les story qualité
                            critiques
                      Perturbation sur l’organisation du sprint :
                          Pas de différenciation sur le tableau (User story vs Quality story)
                          Calcul faussé de la vélocité

RAYNET SNC / Agile Grenoble 2012
Phase 6 : L’Equilibre


                                   Phase 1: Procrastination - contexte

                                   Phase 2: Formation

                                   Phase 3: Stratégie

                                   Phase 4: Mise en suspens

                                   Phase 5: Action rattrapage

                                   Phase 6: L’équilibre

                                   Conclusion



RAYNET SNC / Agile Grenoble 2012
Phase 6 : L’Equilibre

                   Motivations
                      Bugs critiques dans le backlock nécessitant du refactoring
                      Nécessité de cibler les tests -> Dépenser au bon endroit

                   Décisions
                      Sélectionner le volume de story qualité en fonction du contenu du sprint
                        (Disponibilité des « experts »)
                      Avoir un ratio 80/20
                      Meilleure identification des story qualité au tableau (Post-it vert)
                      Estimer et comptabiliser les story Qualité




RAYNET SNC / Agile Grenoble 2012
Phase6 : L’Equilibre

                   Activités
                      Implémentation des story en binôme (expert + développeur)
                      Revue de code pour valider la story

                   Résultat
                      Des composants critiques enfin testés
                      Des bugs critiques enfin résolus
                      A terme, moins de régression sur les fonctionnalités critiques




RAYNET SNC / Agile Grenoble 2012
Conclusion


                                   Phase 1: Procrastination - contexte

                                   Phase 2: Formation

                                   Phase 3: Stratégie

                                   Phase 4: Mise en suspens

                                   Phase 5: Action rattrapage

                                   Phase 6: L’équilibre

                                   Conclusion



RAYNET SNC / Agile Grenoble 2012
Conclusion

            Procéder par étapes

            Justifier l’effort par du résultat concret

            Trouver un équilibre

            Rester réaliste

            Négocier, collaborer, être ouvert



RAYNET SNC / Agile Grenoble 2012
Questions?




RAYNET SNC / Agile Grenoble 2012
DISCLAIMER
        “Presentation” means the information and any materials available in this presentation including, without any limitation, pictures, datasheets, product descriptions, etc. “RAYNET SNC” means an independent company of ARaymond Network and
        the editor of this presentation. This presentation does not constitute an offer or an agreement of any kind. The presentation is provided «as is». RAYNET SNC makes no warranty or representation whatsoever regarding the presentation, its
        use or its suitability to meet specific needs. RAYNET SNC DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
        PURPOSE OF THE presentation. RAYNET SNC is not liable for any incidental, consequential or special damages of any kind due to the use of the presentation. The presentation and/or its contents is copyrighted works of RAYNET SNC and
        may be also protected by trademark laws, patent laws or other laws. All other copyrights, trademarks or patents not owned by RAYNET SNC are the property of their respective owners. The only use permitted is to consult the presentation.
        Any rights not expressly granted herein are reserved. Except as expressly specified in these terms, nothing contained herein shall be construed as conferring any license or right of any copyright, trademark, patent, or any proprietary rights.
        Any unauthorized use of this presentation e may violate rights, and so, RAYNET SNC or any third party concerned may claim any damages or losses suffered.




RAYNET SNC

Contenu connexe

Tendances

Retour d'expérience dev-ops AT-strasbourg 20121018
Retour d'expérience dev-ops AT-strasbourg 20121018Retour d'expérience dev-ops AT-strasbourg 20121018
Retour d'expérience dev-ops AT-strasbourg 20121018Pierre Parrend
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agilesguesta206aa87
 
Pres agile tour 2012 d0.83 fr
Pres agile tour 2012 d0.83 frPres agile tour 2012 d0.83 fr
Pres agile tour 2012 d0.83 fr
Patrick Sarfati
 
Y Meheust Vieldvpt Sqop09 Afeit
Y Meheust Vieldvpt Sqop09 AfeitY Meheust Vieldvpt Sqop09 Afeit
Y Meheust Vieldvpt Sqop09 Afeit
AFEIT
 
Présentation Stage de quatrième année
Présentation Stage de quatrième annéePrésentation Stage de quatrième année
Présentation Stage de quatrième annéeJérôme Le Naou
 
DevExp 2012 methodes agiles SCRUM jesnault
DevExp 2012 methodes agiles SCRUM jesnaultDevExp 2012 methodes agiles SCRUM jesnault
DevExp 2012 methodes agiles SCRUM jesnault
Jérôme Esnault
 
Facilitation les rituels agiles
Facilitation les rituels agilesFacilitation les rituels agiles
Facilitation les rituels agilesMathieu Gandin
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
JEAN-GUILLAUME DUJARDIN
 
Mesurer scrum avec Roboscrum
Mesurer scrum avec RoboscrumMesurer scrum avec Roboscrum
Mesurer scrum avec Roboscrum
Pierre E. NEIS
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
Valentin Bourgoin
 

Tendances (10)

Retour d'expérience dev-ops AT-strasbourg 20121018
Retour d'expérience dev-ops AT-strasbourg 20121018Retour d'expérience dev-ops AT-strasbourg 20121018
Retour d'expérience dev-ops AT-strasbourg 20121018
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agiles
 
Pres agile tour 2012 d0.83 fr
Pres agile tour 2012 d0.83 frPres agile tour 2012 d0.83 fr
Pres agile tour 2012 d0.83 fr
 
Y Meheust Vieldvpt Sqop09 Afeit
Y Meheust Vieldvpt Sqop09 AfeitY Meheust Vieldvpt Sqop09 Afeit
Y Meheust Vieldvpt Sqop09 Afeit
 
Présentation Stage de quatrième année
Présentation Stage de quatrième annéePrésentation Stage de quatrième année
Présentation Stage de quatrième année
 
DevExp 2012 methodes agiles SCRUM jesnault
DevExp 2012 methodes agiles SCRUM jesnaultDevExp 2012 methodes agiles SCRUM jesnault
DevExp 2012 methodes agiles SCRUM jesnault
 
Facilitation les rituels agiles
Facilitation les rituels agilesFacilitation les rituels agiles
Facilitation les rituels agiles
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 
Mesurer scrum avec Roboscrum
Mesurer scrum avec RoboscrumMesurer scrum avec Roboscrum
Mesurer scrum avec Roboscrum
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 

Similaire à Agile Grenoble 2012 - Qualité: Stop à la procrastination

Le bureau de projet: de la demande à l'offre... ou comment être utile sans ja...
Le bureau de projet: de la demande à l'offre... ou comment être utile sans ja...Le bureau de projet: de la demande à l'offre... ou comment être utile sans ja...
Le bureau de projet: de la demande à l'offre... ou comment être utile sans ja...
Claude Emond
 
5 Pourquoi et PDCA : trouver la cause racine et éradiquer le problème
5 Pourquoi et PDCA : trouver la cause racine et éradiquer le problème5 Pourquoi et PDCA : trouver la cause racine et éradiquer le problème
5 Pourquoi et PDCA : trouver la cause racine et éradiquer le problème
Joel DUFLOT
 
Pmi Auvergne : Histoire D’un chef de projet qui adopte l’agilité
Pmi Auvergne : Histoire D’un chef de projet qui adopte l’agilitéPmi Auvergne : Histoire D’un chef de projet qui adopte l’agilité
Pmi Auvergne : Histoire D’un chef de projet qui adopte l’agilitéPierre Fauvel
 
RE: Les risques lies a l'amelioration continue
RE: Les risques lies a l'amelioration continueRE: Les risques lies a l'amelioration continue
RE: Les risques lies a l'amelioration continue
Francois Salazar
 
Scrum day-2013-samuel retiere
Scrum day-2013-samuel retiereScrum day-2013-samuel retiere
Scrum day-2013-samuel retiereSamuel RETIERE
 
Gestion de projet automobile
Gestion de projet automobileGestion de projet automobile
Gestion de projet automobile
Gestion Projet Auto
 
Présentation kaizen
Présentation kaizenPrésentation kaizen
Présentation kaizen
LafargeHolcim
 
Comment BCA Expertise satisfait ses clients grâce au Lean
Comment BCA Expertise satisfait ses clients grâce au Lean Comment BCA Expertise satisfait ses clients grâce au Lean
Comment BCA Expertise satisfait ses clients grâce au Lean
Institut Lean France
 
Up1
Up1Up1
Formation 5 S
Formation 5 SFormation 5 S
Formation 5 Syassin86
 
Quick Response Quality Control : La réactivité organisée vers le 0 défaut
Quick Response Quality Control : La réactivité organisée vers le 0 défautQuick Response Quality Control : La réactivité organisée vers le 0 défaut
Quick Response Quality Control : La réactivité organisée vers le 0 défaut
Joel DUFLOT
 
Automation Lean & Lean Entreprise
Automation Lean & Lean Entreprise Automation Lean & Lean Entreprise
Automation Lean & Lean Entreprise
Jürgen Lauber
 
Définir un cadre méthodologique
Définir un cadre méthodologiqueDéfinir un cadre méthodologique
Définir un cadre méthodologiqueMathieu Gandin
 
L'industriel n'est pas là ou le croit !
L'industriel n'est pas là ou le croit !L'industriel n'est pas là ou le croit !
L'industriel n'est pas là ou le croit !reporter4change
 
Enjeux kanban
Enjeux kanbanEnjeux kanban
Enjeux kanban
Laurent Morisseau
 

Similaire à Agile Grenoble 2012 - Qualité: Stop à la procrastination (20)

Le bureau de projet: de la demande à l'offre... ou comment être utile sans ja...
Le bureau de projet: de la demande à l'offre... ou comment être utile sans ja...Le bureau de projet: de la demande à l'offre... ou comment être utile sans ja...
Le bureau de projet: de la demande à l'offre... ou comment être utile sans ja...
 
Atclt 2012 - Approche Lean Design des grands projets - Mario Moreno
Atclt 2012 - Approche Lean Design des grands projets - Mario MorenoAtclt 2012 - Approche Lean Design des grands projets - Mario Moreno
Atclt 2012 - Approche Lean Design des grands projets - Mario Moreno
 
5 Pourquoi et PDCA : trouver la cause racine et éradiquer le problème
5 Pourquoi et PDCA : trouver la cause racine et éradiquer le problème5 Pourquoi et PDCA : trouver la cause racine et éradiquer le problème
5 Pourquoi et PDCA : trouver la cause racine et éradiquer le problème
 
Pmi Auvergne : Histoire D’un chef de projet qui adopte l’agilité
Pmi Auvergne : Histoire D’un chef de projet qui adopte l’agilitéPmi Auvergne : Histoire D’un chef de projet qui adopte l’agilité
Pmi Auvergne : Histoire D’un chef de projet qui adopte l’agilité
 
RE: Les risques lies a l'amelioration continue
RE: Les risques lies a l'amelioration continueRE: Les risques lies a l'amelioration continue
RE: Les risques lies a l'amelioration continue
 
Scrum day-2013-samuel retiere
Scrum day-2013-samuel retiereScrum day-2013-samuel retiere
Scrum day-2013-samuel retiere
 
CM processus agile
CM processus agileCM processus agile
CM processus agile
 
Gestion de projet automobile
Gestion de projet automobileGestion de projet automobile
Gestion de projet automobile
 
Présentation kaizen
Présentation kaizenPrésentation kaizen
Présentation kaizen
 
Comment BCA Expertise satisfait ses clients grâce au Lean
Comment BCA Expertise satisfait ses clients grâce au Lean Comment BCA Expertise satisfait ses clients grâce au Lean
Comment BCA Expertise satisfait ses clients grâce au Lean
 
Up1
Up1Up1
Up1
 
Formation 5 S
Formation 5 SFormation 5 S
Formation 5 S
 
Quick Response Quality Control : La réactivité organisée vers le 0 défaut
Quick Response Quality Control : La réactivité organisée vers le 0 défautQuick Response Quality Control : La réactivité organisée vers le 0 défaut
Quick Response Quality Control : La réactivité organisée vers le 0 défaut
 
Lean Entreprise 2.0
Lean Entreprise 2.0Lean Entreprise 2.0
Lean Entreprise 2.0
 
Automation Lean & Lean Entreprise
Automation Lean & Lean Entreprise Automation Lean & Lean Entreprise
Automation Lean & Lean Entreprise
 
Définir un cadre méthodologique
Définir un cadre méthodologiqueDéfinir un cadre méthodologique
Définir un cadre méthodologique
 
Fichier récupéré 1
Fichier récupéré 1Fichier récupéré 1
Fichier récupéré 1
 
Agile@scale
Agile@scaleAgile@scale
Agile@scale
 
L'industriel n'est pas là ou le croit !
L'industriel n'est pas là ou le croit !L'industriel n'est pas là ou le croit !
L'industriel n'est pas là ou le croit !
 
Enjeux kanban
Enjeux kanbanEnjeux kanban
Enjeux kanban
 

Agile Grenoble 2012 - Qualité: Stop à la procrastination

  • 1. RAYNET SNC / Agile Grenoble 2012
  • 2. Qualité: Stop à la procrastination Agile Grenoble 2012 L. Dupanloup - F. Chaminand RAYNET SNC
  • 3. Procrastination Nom féminin Tendance pathologique à différer, à remettre l’action au lendemain. Source: www.larousse.fr RAYNET SNC / Agile Grenoble 2012
  • 4. Les procrastinateurs Fabrice Chaminand ScrumMaster Laurent Dupanloup Product Owner Project Manager RAYNET SNC / Agile Grenoble 2012
  • 5. Agenda Phase 1: Procrastination - contexte Phase 2: Formation Phase 3: Stratégie Phase 4: Mise en suspens Phase 5: Action rattrapage Phase 6: L’équilibre Conclusion RAYNET SNC / Agile Grenoble 2012
  • 6. Phase 1 : Procrastination - Contexte Phase 1: Procrastination - contexte Phase 2: Formation Phase 3: Stratégie Phase 4: Mise en suspens Phase 5: Action rattrapage Phase 6: L’équilibre Conclusion RAYNET SNC / Agile Grenoble 2012
  • 7. Phase 1 : Procrastination - Contexte Le produit  Suivi de la production et traçabilité dans les ateliers (automotive)  Env. 1000+ instances à travers le monde  Production en 24/24h, 7/7j RAYNET SNC / Agile Grenoble 2012
  • 8. Phase 1 : Procrastination - Contexte Le projet  Démarrage cycle en V  Migration vers l’agilité en cours de projet  Projet en cours, début de mise en production  50 000 lignes de code Très peu de tests automatisés / code peu testable RAYNET SNC / Agile Grenoble 2012
  • 9. Phase1 : Procrastination - Contexte Situation  Pour le PO : Régression  frustration  Pour les développeurs : Refactoring cassant  frustration  Pour le client : Avenir très incertain RAYNET SNC / Agile Grenoble 2012
  • 10. Phase 2 : Formation Phase 1: Procrastination - contexte Phase 2: Formation Phase 3: Stratégie Phase 4: Mise en suspens Phase 5: Action rattrapage Phase 6: L’équilibre Conclusion RAYNET SNC / Agile Grenoble 2012
  • 11. Phase 2 : Formation  Motivations  Prise de conscience sur la nécessité d’implémenter des tests automatisés  Mise en production imminente  Décisions  Formation « TDD » sur l’implémentation des tests unitaires  Apprentissage : « Comment faire du code testable »  Mise en place de quelques tests RAYNET SNC / Agile Grenoble 2012
  • 12. Phase 2 : Formation  Activités  2h de workshop par semaine :  pour toute l’équipe développement  Binômage  Résultat  Le nouveau code est plus testable  Beaucoup de temps passé versus couverture de test faible RAYNET SNC / Agile Grenoble 2012
  • 13. Phase 3 : Stratégie Phase 1: Procrastination - contexte Phase 2: Formation Phase 3: Stratégie Phase 4: Mise en suspens Phase 5: Action rattrapage Phase 6: L’équilibre Conclusion RAYNET SNC / Agile Grenoble 2012
  • 14. Phase 3 : Stratégie  Motivations  Budget qualité limité  Planning serré  Nécessité de cibler les tests -> Dépenser au bon endroit  Décisions  Identification des fonctionnalités critiques  Choix des fonctionnalités à tester en priorité  Analyse des composants logiciels impactés  Choix du type de test et estimation des coûts  Sélection des composants : Les moins coûteux et gains importants RAYNET SNC / Agile Grenoble 2012
  • 15. Phase 3 : Stratégie Identification des fonctionnalités critiques use cases Worrying Who What Details Where after Downgraded mode, workaround Operator To have the list of the POs and next PO notification up to date RM 1h none Operator To supervise the current operation Change of batch RM 15mn ALT-F4; unplugg the machine; start again the same operation and close it (red cross); call controls engineer (marking); call CIP for data correction Change the operation RM 15mn ALT-F4; unplugg the machine; start again the same operation and close it (red cross); call CIP for data correction Input a comment RM 1d paper Consult the comments RM 1d paper Modify the status RM 1d none Process the HUs (recording, printing,…) RM 1h manual printing; none for creating/modifying Hus; Poogle+… Manage the Quality controls RM 1h call controls engineer (unblock after first sampling); SAP GUI; manual unblocking in Raypro Change the HU type RM 2h None today; tomorrow :Poogle+… and manual printing; View operation details RM 7d Supervision Print manually the label RM 7d Supervision Send the setup RM 15mn call controls engineer; tomorrow add capability to edit et re send the parameters in RM View header information RM 8h paper View notifications RM 2h paper View status (current and history) RM 1d none View graph of productivity RM 7d none View graph of quality RM 7d none View defect counters RM 1d PLC View batch info RM 4h paper; none View misc info RM 8h none View components list RM 3d paper Manivelle To setup the operation for material & WC RS 4h today none; tomorrow add capability to edit et re send the parameters in RM Manivelle Definition of the material RS 8h if by import, do it manually; if manual, none CIP To add/modify hardware configuration RS 1d None but a lot of XML export/import functionnalities exists The boss To obtain productivity information (screen) RS 1d shop floor The boss To obtain productivity information (reports) RS 3d paper Manivelle To block/unblock batches/HUs RS/RM 4h CIP Manivelle To validate the calendar RS 2d none Manivelle To be informed about the last 24/48h running RS 2d shop floor RAYNET SNC / Agile Grenoble 2012
  • 16. Phase 3 : Stratégie Identification des composants impactés RAYNET SNC / Agile Grenoble 2012
  • 17. Phase 3 : Stratégie Analyse de testabilité des composants Block Projet Risques Moyens Coût Rq Action Refactoring a bcp de valeur pour ajouter des UI Machine Faible TU très elevé fonctionnalités (synchro supervision de l'atelier : story à venir en R4) Part 1 : garantir règle métier => regrouper les entités model (packaging, handling unit, operation, workcenter, etc...toutes les WFEntities) concernées par WFModel , défniir leur dépendances pour etablir la sequence dans laquelle elles doivent être sauvegardées. Tester que pour chaque entité commitée, cet ordre de sauvegarde est respecté. Part 2 : garantir unicté de l'instance d'entité manipulée : Gérer un dictionnaire moyen (regles metiers, chagt TU + definition de regles à introduire dans de WFEntity et ne créer une nouvelle instance que si absente du dico. Attention WF Entities Machine de status) les entités faible aux perf! gérer la durée de vie des WFentity dans ce dico en l'etat de nos connaissances,coût TU elevé du fait de la TU sur workaround + regle sur ajout/modif dépendance à dans schema (limiter les dependances) + Nhibernate. UPDATE : definir des workaround (sur le save, on maitrise maintenant checker les dependances, sauvegarder ce la testabilité des Identifier les entités et leurs relations (analyse) => identifier les entites qui ne qu'on peut et lever un warning) + regle services dépendant doivent pas etre transient sur un SaveOrUpdate => TU sur cette méthode avec d'equipe sur le passage obligé par d'Nhibernate => Cout fake sur entité et repo (transient or not) Business Services Machine moyen commande pour toute modif de donnees faible en fait c'est un DAL Si SaveOrUpate failed => remonter l'exception Peu de raisons de toucher au scheduling code existant Lourd et peu flexibles , peu de classes pour neaucoup de responsabilités => moyens limités, impact fort Axer le test sur CommandeInvoker et pas WFConnector Tester le méchanisme et non les commandes WF Engine WF Engine élevé (si on y touche) TU => refactoring moyen (à confirmer) Définir ce qu'il faut tester y élevé : WF normalisation lourde Communicatio Normaliser les commandes + "Boite à beaucoup de WF Commands n faible à moyen tester la norme" commandes Tester les différentes commandes + la norme Outil de test des workflows + écriture des cas, normaliser les worklows (idem Le workflow en lui-même Raypro.Worklo commandes) + règles d'utilisation des Outil similaire développé par Thales (Charlotte Workflows w.Specific très élevé activités élevé Gaidon, cf Jérémie Gomez) Définir un backlog pour l'outil de test des workflows WFCommunica Machine Commands tion faible TU faible Abstract moyen (Construction Abstract Machine Machine faible TU des devices) Abstract script de contrôle des I/O générés pour un Device (Business) Machine élévé TI Automatisé élevé comportement métier donné Abstract Machine + application de TI pour chacun des device Device (Hardware) Wrapper faible à moyen TI (drivers simulé, simulateur, ….) (très) élévé independemment les uns des autres RAYNET SNC / Agile Grenoble 2012
  • 18. Phase 3 : Stratégie  Activités  2h de workshop par semaine  Toute l’équipe projet  Planning + implémentation  Résultat  Liste de tâches cibles à faire en workshop  Format workshop mal adapté à l’implémentation RAYNET SNC / Agile Grenoble 2012
  • 19. Phase 4 : Mise en suspens Phase 1: Procrastination - contexte Phase 2: Formation Phase 3: Stratégie Phase 4: Mise en suspens Phase 5: Action rattrapage Phase 6: L’équilibre Conclusion RAYNET SNC / Agile Grenoble 2012
  • 20. Phase 4 : Mise en suspens  Motivations  Baisse de capacité non prévue  Changements non prévus sur les fonctionnalités  Date de livraison figée  Décisions  Suppression temporaire des workshops Qualité jusqu’à livraison  Résultat  Livraison dans les temps  Augmentation de la charge de tests manuels de non régression  Besoin de refactoring encore plus pressant RAYNET SNC / Agile Grenoble 2012
  • 21. Phase 5 : Rattrapage Phase 1: Procrastination - contexte Phase 2: Formation Phase 3: Stratégie Phase 4: Mise en suspens Phase 5: Action rattrapage Phase 6: L’équilibre Conclusion RAYNET SNC / Agile Grenoble 2012
  • 22. Phase 5 : Rattrapage  Motivations  Livraison effectuée  Besoin de rattraper le retard en terme de Qualité  Ressources supplémentaires  Bugs critiques dans le backlog nécessitant du refactoring  Décisions  Création d’un backlog de story Qualité :  sur les fonctionnalités critiques  sur les fonctionnalités récentes (Garantie testables)  Premier sprint avec 50% de story Qualité  Story Qualité comptabilisées à 0 point dans le sprint RAYNET SNC / Agile Grenoble 2012
  • 23. Phase 5 : Rattrapage  Activités  Intégration des story au storyboard.  Code review pour valider les Story Qualité  Résultat  Nouveau code testé  Mauvaise répartition de l’effort :  Beaucoup de temps passés sur les story Qualité moins critiques  Pas assez de disponibilités des « experts » sur les story qualité critiques  Perturbation sur l’organisation du sprint :  Pas de différenciation sur le tableau (User story vs Quality story)  Calcul faussé de la vélocité RAYNET SNC / Agile Grenoble 2012
  • 24. Phase 6 : L’Equilibre Phase 1: Procrastination - contexte Phase 2: Formation Phase 3: Stratégie Phase 4: Mise en suspens Phase 5: Action rattrapage Phase 6: L’équilibre Conclusion RAYNET SNC / Agile Grenoble 2012
  • 25. Phase 6 : L’Equilibre  Motivations  Bugs critiques dans le backlock nécessitant du refactoring  Nécessité de cibler les tests -> Dépenser au bon endroit  Décisions  Sélectionner le volume de story qualité en fonction du contenu du sprint (Disponibilité des « experts »)  Avoir un ratio 80/20  Meilleure identification des story qualité au tableau (Post-it vert)  Estimer et comptabiliser les story Qualité RAYNET SNC / Agile Grenoble 2012
  • 26. Phase6 : L’Equilibre  Activités  Implémentation des story en binôme (expert + développeur)  Revue de code pour valider la story  Résultat  Des composants critiques enfin testés  Des bugs critiques enfin résolus  A terme, moins de régression sur les fonctionnalités critiques RAYNET SNC / Agile Grenoble 2012
  • 27. Conclusion Phase 1: Procrastination - contexte Phase 2: Formation Phase 3: Stratégie Phase 4: Mise en suspens Phase 5: Action rattrapage Phase 6: L’équilibre Conclusion RAYNET SNC / Agile Grenoble 2012
  • 28. Conclusion  Procéder par étapes  Justifier l’effort par du résultat concret  Trouver un équilibre  Rester réaliste  Négocier, collaborer, être ouvert RAYNET SNC / Agile Grenoble 2012
  • 29. Questions? RAYNET SNC / Agile Grenoble 2012
  • 30. DISCLAIMER “Presentation” means the information and any materials available in this presentation including, without any limitation, pictures, datasheets, product descriptions, etc. “RAYNET SNC” means an independent company of ARaymond Network and the editor of this presentation. This presentation does not constitute an offer or an agreement of any kind. The presentation is provided «as is». RAYNET SNC makes no warranty or representation whatsoever regarding the presentation, its use or its suitability to meet specific needs. RAYNET SNC DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE OF THE presentation. RAYNET SNC is not liable for any incidental, consequential or special damages of any kind due to the use of the presentation. The presentation and/or its contents is copyrighted works of RAYNET SNC and may be also protected by trademark laws, patent laws or other laws. All other copyrights, trademarks or patents not owned by RAYNET SNC are the property of their respective owners. The only use permitted is to consult the presentation. Any rights not expressly granted herein are reserved. Except as expressly specified in these terms, nothing contained herein shall be construed as conferring any license or right of any copyright, trademark, patent, or any proprietary rights. Any unauthorized use of this presentation e may violate rights, and so, RAYNET SNC or any third party concerned may claim any damages or losses suffered. RAYNET SNC