SlideShare une entreprise Scribd logo
1  sur  28
Télécharger pour lire hors ligne
Méthodes agiles
 et Gestion des
 changements
        Agnès CREPET
Architecte – Laboratoires Boiron


  JUG LYON – 19 janvier 2010

                                   page 1
Quelques mots me concernant…

       Architecte Java EE au sein des Laboratoires Boiron
       En charge de la mise en places des architectures logicielles
       « Scrum Master » sur les projets


       Formatrice autour des méthodes agiles :
       Au sein des laboratoires Boiron
       A l'École des Mines de Saint-Étienne


       En parallèle du monde professionnel
       Fait partie de l’association Avataria (http://www.avataria.org) :   organisatrice de
        concerts et ... de Linux Party!




                                                                                          page 2
De quoi allons nous parler ce soir?


 Pas une présentation théorique sur les méthodes agiles


 Mais plutôt un retour d’expériences
   Sur la mise en place de ces méthodologies chez Boiron
   Difficultés rencontrées
   Les vraies réussites
   Les écarts avec ce qui est préconisé par les méthodes agiles



 Focus de la présentation:
   La planification itérative et la gestion des changements…



                                                                   page 3
Sommaire


    Contexte : Boiron et Agilité



    Déroulement et planification d’une itération



    Un mot sur la modélisation et la gestion des exigences




                                                              page 4
Contexte : Boiron et Agilité

       La DSI des laboratoires Boiron a introduit en 2007 les méthodes agiles
       Pour les projets de refonte du Système d’information sur la base d’architectures
        contemporaines (JEE, ESB, MDM, etc.)


       Intérêts :
           introduire des demandes d’évolutions en cours de projet
           faciliter l’acceptation des nouvelles solutions informatiques par les utilisateurs finaux


       Premier « vrai » déploiement sur un des plus gros projets de la DSI
           ARPEGE : 8700 jours


       Agilité chez BOIRON?
           Un mix d’UP, XP et de Scrum / Kanban
           Le tout mélangé avec de la teinture mère d’Arnica Montana!




                                                                                                        page 5
Quelques pratiques et outillages « agiles » Boiron
   Processus itératif et incrémental

   Recette Utilisateur à chaque fin d’itération

   Stand-up quotidien / Tableau post-it

   Gestion des exigences

   Développement par les tests (JUNIT, DBUNIT, EasyMock)

   Refactoring régulier (par les patterns)

   Bug Tracker (JIRA)

   Intégration Continue (Maven 2, Continuum, Archiva)




                                                            page 6
Inspiration de la méthodologie agile Boiron




U P e n 1 0 0 m o ts
       Le processus UP (abréviation de Unified Processus) a été créé par les mêmes
        personnes qu'UML (Rumbaugh, Booch et Jacobson) en 1997.
       UP répond aux exigences fondamentales préconisées par les créateurs d’UML :
       une méthode de développement doit être guidée par les besoins des utilisateurs
       elle doit être centrée sur l’architecture logicielle
       elle doit être itérative et incrémentale
       Centré Cas d’utilisation (use case)
       Organisé autour de 4 phases (respectées chez Boiron):
       Analyse des besoins, élaboration, construction et transition
       Vraiment agile?
       Il faut faire le tri : avons-nous vraiment besoin d’un rôle de « Responsable du contrôle du
        changement »?
                                                                                                      page 7
Inspiration de la méthodologie agile Boiron


 S c r u m e n 1 0 0 m o ts
 Scrum est un processus agile qui permet de produire la plus grande valeur métier
  dans la durée la plus courte

 Du logiciel qui fonctionne est produit à chaque « sprint » (2 à 4 semaines) = timebox
 Le métier définit les priorités. L'équipe s'organise elle-même pour déterminer la
  meilleure façon de produire les exigences les plus prioritaires

 A chaque fin de sprint : release déployable et testable par les utilisateurs finaux
 Deux rôles importants dans l’équipe Scrum:
           Product Owner et Scrum Master



                                                                                          page 8
Product Owner                                  Scrum Master




   Définit les   fonctionnalités      du      Vulgarise les valeurs       et     les
    produit                                     pratiques de Scrum
   Définit les priorités dans le              Contribue à améliorer les outils et
    backlog en fonction de la valeur            les pratiques de l’ingénierie
    « métier »
                                               Facilite une coopération poussée
   Ajuste les fonctionnalités et les           entre tous les rôles et fonctions
    priorités à chaque itération si
    nécessaire                                 Protège l'équipe des
                                                interférences extérieures
   Teste les releases
                                               Met l’accent sur la créativité et la
   Accepte ou rejette les résultats            gestion autonome des membres

                                                                                 page 9
Sommaire


    Contexte : Boiron et Agilité



    Déroulement et planification d’une itération



    Un mot sur la modélisation et la gestion des exigences




                                                              page 10
Processus itératif : pratiques Boiron



 Des itérations d’un mois calendaire
   Mais cela peut varier en fonction des
    phase du projet
          Un sprint est à durée fixe en Scrum
          Kanban


 Des recettes utilisateurs à chaque fin
  d’itération
   En période pré-production : recette toutes
    les 2 / 3 semaines

                                                 Recette Utilisateur ARPEGE – Boiron - janvier 2010




                                                                                               page 11
Une itération?
                                                24 h e u re s




                                                  Ité r a tio n
                                                   1 m o is
 B u t d e l’ité r a tio n

          R e to u r
                                L is te d e s                         P r o d u it p a r tie l
                                  tâ c h e s
  R n nto le r
   Ae uu                                                          liv r a b le e t te s ta b le
   E m obuap lla s e
     C        ong
 E m bnaulla gre
 A n le                      C oupons
    B a c k lo g
   d e p r o d u it

                                                                                      page 12
Les fonctionnalités à implémenter = Backlog de produit


                                 Backlog de produit = les exigences
                                    En UP : Use Case  Boiron
                                    En XP : User stories
                                 Une entrée du backlog de produit est un
                                  Use Case UML (inspiré d’UP)
                                    Un use Case peut se dérouler sur 1 ou 2
                                     itérations ( en Scrum, en Kanban)

                                 Leurs priorités sont revues à chaque
                                  itération
                                    Définies par le Product Owner
C e c i e s t le b a c k lo g       Mais également par le reste de l’équipe
       d e p r o d u it              (différent de Scrum)  Boiron



                                                                          page 13
Un backlog de produit Boiron


 A chaque Use Case sont associées deux               9    Monitorer des lignes de préparation   10    5         1

  attributs:                                          10   Consulter une ligne de préparation     5              4

   Une estimation en points arbitraires              11   Lancer des fabrications                5              1
     On ne parle pas encore de jours                 12   Pré-affecter la traçabilité           15              1

   Et  une priorité (métier, risque technique        13   Editer les documents de fabrication   20              1

    identifié?)                                       14   Annuler une ligne de préparation       5              2

 La liste peut évoluer au cours du projet            15   Interface avec SI téléphone
                                                               (prévenir préparation annulée)
                                                                                                  5              4



   Suite au recette utilisateur en fin d’itération   16   Mettre une ligne de préparation en     5              2
                                                               attente

 Perfectible :                                       17   Interface avec SI téléphone
                                                               (allongement délai livraison /
                                                                                                  5              4

                                                               commande)
   Chiffrage initial                                 18   Réconcilier                           10              1
                                                      19   Terminer une étape de préparation     10    5         1




                                                           Initial estimate                      Importance
                                                           exprimé en ‘points’                   ou Priority
                                                                                                       page 14
Comment planifier une itération?

                       P la n ific a tio n d ’u n e ité r a tio n
 C a p a c ité
d e l'é q u ip e
                          P é r im è tr e
 B a c k lo g            • S é a n c e s d e p la n ific a tio n ité r a tiv e s      But de
                         • A n a ly s e r e t é v a lu e r le b a c k lo g d e     l’ité r a tio n
d e p r o d u it
                           p r o d u it
                         • D é fin ir le b u t d e l’ité r a tio n
C o n d itio n s
   m é tie r              P la n
                         • D é c id e r c o m m e n t s 'y p r e n d r e
   P r o d u it            (c o n c e p tio n )                                      L is te d e s
    a c tu e l           • C r é e r la lis te d e s tâ c h e s à                  tâ c h e s d a n s
                           p a r tir d e s é lé m e n ts d u b a c k lo g                J IR A
                           d e p r o d u it
C o m p le x ité         • E s tim e r le s tâ c h e s
 Technos


                                                                                                page 15
Planification Itérative en continue sur le projet

   On calcule la vélocité de l’équipe
       Sa disponibilité réelle pour l’itération à venir
       Chaque membre 80% opérationnel sur des entrées du backlog (le reste : stand-up,
        refactoring, etc.)
   La liste des tâches est créée
       On parle de jours et non d’heure comme en Scrum
       Collectivement, pas seulement par le ScrumMaster
       Expérimentation Boiron : peer-chiffrage
       La conception de haut niveau est abordée


Traçabilité pour
                                    C o d e r la c o u c h e d e p e r s is ta n c e (1 jo u r )
Traçabilité pour                    C o d e r l'IH M (0 ,5 jo u r )
toute création ou
toute création ou                   E c r ir e le s te s t fix tu r e s (0 ,5 jo u r )
modification de lots
modification de lots                C o d e r la c la s s e L ig n e d e P r e p . (0 ,7 5
                                    jo u r )
                                    M a j le s te s ts d e p e r fo r m a n c e   (0 ,5 jo u r )

                                                                                             page 16
Vie du backlog de l’itération

   L'estimation du reste à faire est ajustée tous les
    jours (Stand-up / JIRA)
         Mise à jour du travail restant quand il est mieux
          connu
   N'importe qui peut ajouter, supprimer ou changer
    la liste des tâches en stand-up

   Si un travail n'est pas clair, définir une tâche avec
    plus de temps et la décomposer après

≠ Boiron avec Scrum :                                                     Burndown Chart Scrum


                              Changement      en   cours Estimation du reste à faire
                              d’itérations

 Scrum                                                   Utilisation de Burndown Charts

                                                         avec mise à jour quotidienne
 Boiron                                      (comme      Utilisation de JIRA (quotidien)
                                             Kanban)     + AUGEO (semaine/mois)
                                                                                            page 17
Sommaire


    Contexte : Boiron et Agilité



    Déroulement et planification d’une itération



    Un mot sur la modélisation et la gestion des exigences




                                                              page 18
Agilité et UML

   Comment documenter / modéliser un besoin ?

   2 approches semblent opposées :
       l'approche Model-Driven, préconisée par l'OMG, s'appuyant sur une modélisation
        UML très poussée visant à une génération automatique de code quasi-complète,
       les méthodes agiles mettant plus l'accent sur la production rapide de code
        opérationnel que sur la documentation et minimisant donc la modélisation en amont


   L'agilité se passe de plus en plus d'UML mais Boiron a décidé de garder cette
    approche de la modélisation
       Contrainte de validation pharmaceutique
       Traçabilité des exigences
       Facilitant pour analyser l’impact d’un changement



   La modélisation agile peut-elle exister ?


                                                                                    page 19
Exprimer le Besoin Utilisateur


 Pas trop de doc…




 Un peu d’UML…
                                 page 20
Modélisation : retour d’expériences Boiron
 On commence par saisir les exigences dans Enterprise Architect




                                                                   page 21
Modélisation : retour d’expériences Boiron
 Puis on poursuit la modélisation avec des Diagramme de cas d’utilisation




                                                                             page 22
Traçabilité des exigences



                             On lie ensuite les exigences
                              aux Use case

                             Pour obtenir une matrice de
                              couverture des exigences / UC

                             Intérêt : assurer la traçabilité
                              des exigences par rapport à
                              l’analyse
                               Essentiel
                                       pour la VALIDATION
                                PHARMACEUTIQUE




                                                         page 23
Perspective : traçabilité des exigences dans le code


     Idéal pour l’analyse d’impact d’une demande changement



     Solutions :
          Dans les commentaires?
           Pas top!


          Ecrire ses propres annotations?
           Mieux
           Une annotation = une exigence ou un use-case
           Faciliterait l’analyse d’impact outillée…




                                                               page 24
Conclusion


     Appliquer les pratiques agiles qui semblent « pragmatiques » et adaptées
      à votre contexte

     Outiller certaines d’entre elles

     Et vulgariser, former…

     Les personnes de l’équipe doivent d’approprier la méthode
         Mieux que de l’imposer!



  « Ne pas développer de dépendance spécifique à une arme ou à une école de
      combat »
                                         Miyamoto   Musachi,      Samouraï   du
          XVIIième siècle




                                                                             page 25
Lectures…

•   Ken Schwaber

    •   ADM
    •   Scrum présenté à OOPSLA 96 avec Sutherland
    •   Auteur des 3 livres sur Scrum

•   Agile and Iterative Development: A Manager’s Guide de Craig
    Larman

•   Agile Estimating and Planning de Mike Cohn

•   Agile Retrospectives d'Esther Derby et Diana Larsen

•   Agile Software Development Ecosystems de Jim Highsmith

•   User Stories Applied for Agile Software Development de Mike
    Cohn

•   Des articles toutes les semaines à www.scrumalliance.org




                                                                  page 26
Où se renseigner ?


•   www.mountaingoatsoftware.com/scrum

•   www.scrumalliance.org

•   www.controlchaos.com

•   scrumdevelopment@yahoogroups.com

•   En français :
    •   le groupe des utilisateurs de Scrum : www.frenchsug.org
    •   http://fr.groups.yahoo.com/group/frenchsug

    •   Scrum vs Kanban:
        • http://www.fabrice-aimetti.fr/dotclear/public/mes-documents/Kanban-vs-Scrum-French.pdf




                                                                                                   page 27
Sources




C e r ta in s S lid e s s o n t is s u s d ’u n e p r é s e n ta tio n d e M ik e C o h n s o u s lic e n s e lib r e

                                           www.mountaingoatsoftware.com



                                               T r a d u c tio n d e C la u d e A u b r y
                                                   www.aubryconseil.com


                                                                                                                        page 28

Contenu connexe

En vedette

Portafolio
PortafolioPortafolio
Portafolio
sumyeve
 
Effective emails
Effective emailsEffective emails
Effective emails
ochursina
 
Les plaisances dans les îles
Les plaisances dans les îlesLes plaisances dans les îles
Les plaisances dans les îles
gfonvieille
 
Plantilla pwp presentacions ii jornada de recerca de residents ud gironines
Plantilla pwp presentacions ii jornada de recerca de residents ud gironinesPlantilla pwp presentacions ii jornada de recerca de residents ud gironines
Plantilla pwp presentacions ii jornada de recerca de residents ud gironines
Maria Martinez
 
Financement des bateaux de plaisance
Financement des bateaux de plaisanceFinancement des bateaux de plaisance
Financement des bateaux de plaisance
CA Consumer Finance
 
Escuela Normal Del Estado
Escuela Normal Del EstadoEscuela Normal Del Estado
Escuela Normal Del Estado
guest438062f
 

En vedette (20)

Portafolio
PortafolioPortafolio
Portafolio
 
BOD & Lean Printing par Yves d'Aviau de Ternay
BOD & Lean Printing par Yves d'Aviau de TernayBOD & Lean Printing par Yves d'Aviau de Ternay
BOD & Lean Printing par Yves d'Aviau de Ternay
 
Effective emails
Effective emailsEffective emails
Effective emails
 
Le credoc. ali haddadou
Le credoc. ali haddadouLe credoc. ali haddadou
Le credoc. ali haddadou
 
Diapositivas
DiapositivasDiapositivas
Diapositivas
 
24ºdoming..
24ºdoming..24ºdoming..
24ºdoming..
 
Comprendre l'expérience client multi-écrans
Comprendre l'expérience client multi-écransComprendre l'expérience client multi-écrans
Comprendre l'expérience client multi-écrans
 
Str présentation-wikiamco-v9
Str présentation-wikiamco-v9Str présentation-wikiamco-v9
Str présentation-wikiamco-v9
 
BTP - 2014 10 Clauses professionnelles - moins de 10
BTP - 2014 10 Clauses professionnelles - moins de 10BTP - 2014 10 Clauses professionnelles - moins de 10
BTP - 2014 10 Clauses professionnelles - moins de 10
 
El Circulo Del Odio
El Circulo Del OdioEl Circulo Del Odio
El Circulo Del Odio
 
Volc2
Volc2Volc2
Volc2
 
Les plaisances dans les îles
Les plaisances dans les îlesLes plaisances dans les îles
Les plaisances dans les îles
 
Les fails médias sociaux de l'année 2013
Les fails médias sociaux de l'année 2013Les fails médias sociaux de l'année 2013
Les fails médias sociaux de l'année 2013
 
Plan De Salvacion
Plan De SalvacionPlan De Salvacion
Plan De Salvacion
 
Romanticismo
RomanticismoRomanticismo
Romanticismo
 
Plantilla pwp presentacions ii jornada de recerca de residents ud gironines
Plantilla pwp presentacions ii jornada de recerca de residents ud gironinesPlantilla pwp presentacions ii jornada de recerca de residents ud gironines
Plantilla pwp presentacions ii jornada de recerca de residents ud gironines
 
Financement des bateaux de plaisance
Financement des bateaux de plaisanceFinancement des bateaux de plaisance
Financement des bateaux de plaisance
 
Refaire sa-salle-de-bain
Refaire sa-salle-de-bainRefaire sa-salle-de-bain
Refaire sa-salle-de-bain
 
Magisnet
MagisnetMagisnet
Magisnet
 
Escuela Normal Del Estado
Escuela Normal Del EstadoEscuela Normal Del Estado
Escuela Normal Del Estado
 

Similaire à 201001 Agilité

Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
agnes_crepet
 
AgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFSAgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFS
Agile Toulouse
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
Harun Mouad
 

Similaire à 201001 Agilité (20)

#11 rex
#11 rex#11 rex
#11 rex
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
#3 etapes projet
#3 etapes projet#3 etapes projet
#3 etapes projet
 
PresentationMéthodologie SCRUM-2021.pptx
PresentationMéthodologie SCRUM-2021.pptxPresentationMéthodologie SCRUM-2021.pptx
PresentationMéthodologie SCRUM-2021.pptx
 
Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
 
Introduction à l'agilité numélink - 24 mai 2012 - #11 rex
Introduction à l'agilité   numélink - 24 mai 2012 - #11 rexIntroduction à l'agilité   numélink - 24 mai 2012 - #11 rex
Introduction à l'agilité numélink - 24 mai 2012 - #11 rex
 
Up1
Up1Up1
Up1
 
#7 méthodes
#7 méthodes#7 méthodes
#7 méthodes
 
20mn scrum
20mn scrum20mn scrum
20mn scrum
 
Introduction à l'agilité numélink - 24 mai 2012 - #3 etapes proj
Introduction à l'agilité   numélink - 24 mai 2012 - #3 etapes projIntroduction à l'agilité   numélink - 24 mai 2012 - #3 etapes proj
Introduction à l'agilité numélink - 24 mai 2012 - #3 etapes proj
 
Agile - Que le choc commence !
Agile - Que le choc commence !Agile - Que le choc commence !
Agile - Que le choc commence !
 
Rex Software Factories 20140117 - Ensim
Rex Software Factories 20140117 - EnsimRex Software Factories 20140117 - Ensim
Rex Software Factories 20140117 - Ensim
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 
cours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.pptcours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.ppt
 
AgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFSAgileTour Toulouse 2012 : TFS
AgileTour Toulouse 2012 : TFS
 
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D
2016-04-13 Anne Claire Jacob Poulin Gestion par projet dans un centre de R&D
 
Les Business Analysts face à l'agilité
Les Business Analysts face à l'agilitéLes Business Analysts face à l'agilité
Les Business Analysts face à l'agilité
 
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ? TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
TFS 2012 : un pas vers l'agilité... en avant ou en arrière ?
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 

Plus de lyonjug

201303 - Golo
201303 - Golo201303 - Golo
201303 - Golo
lyonjug
 
201303 - Java8
201303 - Java8201303 - Java8
201303 - Java8
lyonjug
 
201305 - Lambda by R. Forax
201305 - Lambda by R. Forax201305 - Lambda by R. Forax
201305 - Lambda by R. Forax
lyonjug
 
201301 - Focus Neo4j
201301 - Focus Neo4j201301 - Focus Neo4j
201301 - Focus Neo4j
lyonjug
 
201301 - Panorama NoSQL
201301 - Panorama NoSQL201301 - Panorama NoSQL
201301 - Panorama NoSQL
lyonjug
 
201209 Lombok & Guava
201209 Lombok & Guava201209 Lombok & Guava
201209 Lombok & Guava
lyonjug
 
201209 LT Clojure
201209 LT Clojure201209 LT Clojure
201209 LT Clojure
lyonjug
 
Présentation Granite ds lyon 2011 par William Draï
Présentation Granite ds lyon 2011 par William DraïPrésentation Granite ds lyon 2011 par William Draï
Présentation Granite ds lyon 2011 par William Draï
lyonjug
 

Plus de lyonjug (20)

DIY: Analyse statique en Java
DIY: Analyse statique en JavaDIY: Analyse statique en Java
DIY: Analyse statique en Java
 
Lightning talk LyonJUG février 2016 - Ansible
Lightning talk LyonJUG février 2016 - AnsibleLightning talk LyonJUG février 2016 - Ansible
Lightning talk LyonJUG février 2016 - Ansible
 
Introduction LyonJUG décembre 2015
Introduction LyonJUG décembre 2015Introduction LyonJUG décembre 2015
Introduction LyonJUG décembre 2015
 
Introduction LyonJUG Janvier 2016
Introduction LyonJUG Janvier 2016Introduction LyonJUG Janvier 2016
Introduction LyonJUG Janvier 2016
 
Presentation jug novembre2015
Presentation jug novembre2015Presentation jug novembre2015
Presentation jug novembre2015
 
201502 - Integration Testing
201502 - Integration Testing201502 - Integration Testing
201502 - Integration Testing
 
201311 - Middleware
201311 - Middleware201311 - Middleware
201311 - Middleware
 
201303 - Golo
201303 - Golo201303 - Golo
201303 - Golo
 
201303 - Java8
201303 - Java8201303 - Java8
201303 - Java8
 
201305 - Lambda by R. Forax
201305 - Lambda by R. Forax201305 - Lambda by R. Forax
201305 - Lambda by R. Forax
 
201301 - Focus Neo4j
201301 - Focus Neo4j201301 - Focus Neo4j
201301 - Focus Neo4j
 
201301 - Panorama NoSQL
201301 - Panorama NoSQL201301 - Panorama NoSQL
201301 - Panorama NoSQL
 
201209 Lombok & Guava
201209 Lombok & Guava201209 Lombok & Guava
201209 Lombok & Guava
 
201209 LT Clojure
201209 LT Clojure201209 LT Clojure
201209 LT Clojure
 
Spring Batch Workshop (advanced)
Spring Batch Workshop (advanced)Spring Batch Workshop (advanced)
Spring Batch Workshop (advanced)
 
Spring Batch Workshop
Spring Batch WorkshopSpring Batch Workshop
Spring Batch Workshop
 
Engagement des sociétés d'Ingénierie dans la contribution open source : un ce...
Engagement des sociétés d'Ingénierie dans la contribution open source : un ce...Engagement des sociétés d'Ingénierie dans la contribution open source : un ce...
Engagement des sociétés d'Ingénierie dans la contribution open source : un ce...
 
GlassFish, Application versioning et rolling upgrade en haute disponibilité
GlassFish, Application versioning et rolling upgrade en haute disponibilitéGlassFish, Application versioning et rolling upgrade en haute disponibilité
GlassFish, Application versioning et rolling upgrade en haute disponibilité
 
Développement dans le cloud - Sacha Labourey
Développement dans le cloud - Sacha LaboureyDéveloppement dans le cloud - Sacha Labourey
Développement dans le cloud - Sacha Labourey
 
Présentation Granite ds lyon 2011 par William Draï
Présentation Granite ds lyon 2011 par William DraïPrésentation Granite ds lyon 2011 par William Draï
Présentation Granite ds lyon 2011 par William Draï
 

201001 Agilité

  • 1. Méthodes agiles et Gestion des changements Agnès CREPET Architecte – Laboratoires Boiron JUG LYON – 19 janvier 2010 page 1
  • 2. Quelques mots me concernant…  Architecte Java EE au sein des Laboratoires Boiron  En charge de la mise en places des architectures logicielles  « Scrum Master » sur les projets  Formatrice autour des méthodes agiles :  Au sein des laboratoires Boiron  A l'École des Mines de Saint-Étienne  En parallèle du monde professionnel  Fait partie de l’association Avataria (http://www.avataria.org) : organisatrice de concerts et ... de Linux Party! page 2
  • 3. De quoi allons nous parler ce soir?  Pas une présentation théorique sur les méthodes agiles  Mais plutôt un retour d’expériences  Sur la mise en place de ces méthodologies chez Boiron  Difficultés rencontrées  Les vraies réussites  Les écarts avec ce qui est préconisé par les méthodes agiles  Focus de la présentation:  La planification itérative et la gestion des changements… page 3
  • 4. Sommaire  Contexte : Boiron et Agilité  Déroulement et planification d’une itération  Un mot sur la modélisation et la gestion des exigences page 4
  • 5. Contexte : Boiron et Agilité  La DSI des laboratoires Boiron a introduit en 2007 les méthodes agiles  Pour les projets de refonte du Système d’information sur la base d’architectures contemporaines (JEE, ESB, MDM, etc.)  Intérêts :  introduire des demandes d’évolutions en cours de projet  faciliter l’acceptation des nouvelles solutions informatiques par les utilisateurs finaux  Premier « vrai » déploiement sur un des plus gros projets de la DSI  ARPEGE : 8700 jours  Agilité chez BOIRON?  Un mix d’UP, XP et de Scrum / Kanban  Le tout mélangé avec de la teinture mère d’Arnica Montana! page 5
  • 6. Quelques pratiques et outillages « agiles » Boiron  Processus itératif et incrémental  Recette Utilisateur à chaque fin d’itération  Stand-up quotidien / Tableau post-it  Gestion des exigences  Développement par les tests (JUNIT, DBUNIT, EasyMock)  Refactoring régulier (par les patterns)  Bug Tracker (JIRA)  Intégration Continue (Maven 2, Continuum, Archiva) page 6
  • 7. Inspiration de la méthodologie agile Boiron U P e n 1 0 0 m o ts  Le processus UP (abréviation de Unified Processus) a été créé par les mêmes personnes qu'UML (Rumbaugh, Booch et Jacobson) en 1997.  UP répond aux exigences fondamentales préconisées par les créateurs d’UML :  une méthode de développement doit être guidée par les besoins des utilisateurs  elle doit être centrée sur l’architecture logicielle  elle doit être itérative et incrémentale  Centré Cas d’utilisation (use case)  Organisé autour de 4 phases (respectées chez Boiron):  Analyse des besoins, élaboration, construction et transition  Vraiment agile?  Il faut faire le tri : avons-nous vraiment besoin d’un rôle de « Responsable du contrôle du changement »? page 7
  • 8. Inspiration de la méthodologie agile Boiron S c r u m e n 1 0 0 m o ts  Scrum est un processus agile qui permet de produire la plus grande valeur métier dans la durée la plus courte  Du logiciel qui fonctionne est produit à chaque « sprint » (2 à 4 semaines) = timebox  Le métier définit les priorités. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les plus prioritaires  A chaque fin de sprint : release déployable et testable par les utilisateurs finaux  Deux rôles importants dans l’équipe Scrum:  Product Owner et Scrum Master page 8
  • 9. Product Owner Scrum Master  Définit les fonctionnalités du  Vulgarise les valeurs et les produit pratiques de Scrum  Définit les priorités dans le  Contribue à améliorer les outils et backlog en fonction de la valeur les pratiques de l’ingénierie « métier »  Facilite une coopération poussée  Ajuste les fonctionnalités et les entre tous les rôles et fonctions priorités à chaque itération si nécessaire  Protège l'équipe des interférences extérieures  Teste les releases  Met l’accent sur la créativité et la  Accepte ou rejette les résultats gestion autonome des membres page 9
  • 10. Sommaire  Contexte : Boiron et Agilité  Déroulement et planification d’une itération  Un mot sur la modélisation et la gestion des exigences page 10
  • 11. Processus itératif : pratiques Boiron  Des itérations d’un mois calendaire  Mais cela peut varier en fonction des phase du projet  Un sprint est à durée fixe en Scrum  Kanban  Des recettes utilisateurs à chaque fin d’itération  En période pré-production : recette toutes les 2 / 3 semaines Recette Utilisateur ARPEGE – Boiron - janvier 2010 page 11
  • 12. Une itération? 24 h e u re s Ité r a tio n 1 m o is B u t d e l’ité r a tio n R e to u r L is te d e s P r o d u it p a r tie l tâ c h e s R n nto le r Ae uu liv r a b le e t te s ta b le E m obuap lla s e C ong E m bnaulla gre A n le C oupons B a c k lo g d e p r o d u it page 12
  • 13. Les fonctionnalités à implémenter = Backlog de produit  Backlog de produit = les exigences  En UP : Use Case  Boiron  En XP : User stories  Une entrée du backlog de produit est un Use Case UML (inspiré d’UP)  Un use Case peut se dérouler sur 1 ou 2 itérations ( en Scrum, en Kanban)  Leurs priorités sont revues à chaque itération  Définies par le Product Owner C e c i e s t le b a c k lo g  Mais également par le reste de l’équipe d e p r o d u it (différent de Scrum)  Boiron page 13
  • 14. Un backlog de produit Boiron  A chaque Use Case sont associées deux 9 Monitorer des lignes de préparation 10 5 1 attributs: 10 Consulter une ligne de préparation 5   4  Une estimation en points arbitraires 11 Lancer des fabrications 5   1  On ne parle pas encore de jours 12 Pré-affecter la traçabilité 15   1  Et une priorité (métier, risque technique 13 Editer les documents de fabrication 20   1 identifié?) 14 Annuler une ligne de préparation 5   2  La liste peut évoluer au cours du projet 15 Interface avec SI téléphone (prévenir préparation annulée) 5   4  Suite au recette utilisateur en fin d’itération 16 Mettre une ligne de préparation en 5   2 attente  Perfectible : 17 Interface avec SI téléphone (allongement délai livraison / 5   4 commande)  Chiffrage initial 18 Réconcilier 10   1 19 Terminer une étape de préparation 10 5 1 Initial estimate Importance exprimé en ‘points’ ou Priority page 14
  • 15. Comment planifier une itération? P la n ific a tio n d ’u n e ité r a tio n C a p a c ité d e l'é q u ip e P é r im è tr e B a c k lo g • S é a n c e s d e p la n ific a tio n ité r a tiv e s But de • A n a ly s e r e t é v a lu e r le b a c k lo g d e l’ité r a tio n d e p r o d u it p r o d u it • D é fin ir le b u t d e l’ité r a tio n C o n d itio n s m é tie r P la n • D é c id e r c o m m e n t s 'y p r e n d r e P r o d u it (c o n c e p tio n ) L is te d e s a c tu e l • C r é e r la lis te d e s tâ c h e s à tâ c h e s d a n s p a r tir d e s é lé m e n ts d u b a c k lo g J IR A d e p r o d u it C o m p le x ité • E s tim e r le s tâ c h e s Technos page 15
  • 16. Planification Itérative en continue sur le projet  On calcule la vélocité de l’équipe  Sa disponibilité réelle pour l’itération à venir  Chaque membre 80% opérationnel sur des entrées du backlog (le reste : stand-up, refactoring, etc.)  La liste des tâches est créée  On parle de jours et non d’heure comme en Scrum  Collectivement, pas seulement par le ScrumMaster  Expérimentation Boiron : peer-chiffrage  La conception de haut niveau est abordée Traçabilité pour C o d e r la c o u c h e d e p e r s is ta n c e (1 jo u r ) Traçabilité pour C o d e r l'IH M (0 ,5 jo u r ) toute création ou toute création ou E c r ir e le s te s t fix tu r e s (0 ,5 jo u r ) modification de lots modification de lots C o d e r la c la s s e L ig n e d e P r e p . (0 ,7 5 jo u r ) M a j le s te s ts d e p e r fo r m a n c e (0 ,5 jo u r ) page 16
  • 17. Vie du backlog de l’itération  L'estimation du reste à faire est ajustée tous les jours (Stand-up / JIRA)  Mise à jour du travail restant quand il est mieux connu  N'importe qui peut ajouter, supprimer ou changer la liste des tâches en stand-up  Si un travail n'est pas clair, définir une tâche avec plus de temps et la décomposer après ≠ Boiron avec Scrum : Burndown Chart Scrum Changement en cours Estimation du reste à faire d’itérations Scrum Utilisation de Burndown Charts avec mise à jour quotidienne Boiron (comme Utilisation de JIRA (quotidien) Kanban) + AUGEO (semaine/mois) page 17
  • 18. Sommaire  Contexte : Boiron et Agilité  Déroulement et planification d’une itération  Un mot sur la modélisation et la gestion des exigences page 18
  • 19. Agilité et UML  Comment documenter / modéliser un besoin ?  2 approches semblent opposées :  l'approche Model-Driven, préconisée par l'OMG, s'appuyant sur une modélisation UML très poussée visant à une génération automatique de code quasi-complète,  les méthodes agiles mettant plus l'accent sur la production rapide de code opérationnel que sur la documentation et minimisant donc la modélisation en amont  L'agilité se passe de plus en plus d'UML mais Boiron a décidé de garder cette approche de la modélisation  Contrainte de validation pharmaceutique  Traçabilité des exigences  Facilitant pour analyser l’impact d’un changement  La modélisation agile peut-elle exister ? page 19
  • 20. Exprimer le Besoin Utilisateur Pas trop de doc… Un peu d’UML… page 20
  • 21. Modélisation : retour d’expériences Boiron  On commence par saisir les exigences dans Enterprise Architect page 21
  • 22. Modélisation : retour d’expériences Boiron  Puis on poursuit la modélisation avec des Diagramme de cas d’utilisation page 22
  • 23. Traçabilité des exigences  On lie ensuite les exigences aux Use case  Pour obtenir une matrice de couverture des exigences / UC  Intérêt : assurer la traçabilité des exigences par rapport à l’analyse  Essentiel pour la VALIDATION PHARMACEUTIQUE page 23
  • 24. Perspective : traçabilité des exigences dans le code  Idéal pour l’analyse d’impact d’une demande changement  Solutions :  Dans les commentaires?  Pas top!  Ecrire ses propres annotations?  Mieux  Une annotation = une exigence ou un use-case  Faciliterait l’analyse d’impact outillée… page 24
  • 25. Conclusion  Appliquer les pratiques agiles qui semblent « pragmatiques » et adaptées à votre contexte  Outiller certaines d’entre elles  Et vulgariser, former…  Les personnes de l’équipe doivent d’approprier la méthode  Mieux que de l’imposer! « Ne pas développer de dépendance spécifique à une arme ou à une école de combat » Miyamoto Musachi, Samouraï du XVIIième siècle page 25
  • 26. Lectures… • Ken Schwaber • ADM • Scrum présenté à OOPSLA 96 avec Sutherland • Auteur des 3 livres sur Scrum • Agile and Iterative Development: A Manager’s Guide de Craig Larman • Agile Estimating and Planning de Mike Cohn • Agile Retrospectives d'Esther Derby et Diana Larsen • Agile Software Development Ecosystems de Jim Highsmith • User Stories Applied for Agile Software Development de Mike Cohn • Des articles toutes les semaines à www.scrumalliance.org page 26
  • 27. Où se renseigner ? • www.mountaingoatsoftware.com/scrum • www.scrumalliance.org • www.controlchaos.com • scrumdevelopment@yahoogroups.com • En français : • le groupe des utilisateurs de Scrum : www.frenchsug.org • http://fr.groups.yahoo.com/group/frenchsug • Scrum vs Kanban: • http://www.fabrice-aimetti.fr/dotclear/public/mes-documents/Kanban-vs-Scrum-French.pdf page 27
  • 28. Sources C e r ta in s S lid e s s o n t is s u s d ’u n e p r é s e n ta tio n d e M ik e C o h n s o u s lic e n s e lib r e www.mountaingoatsoftware.com T r a d u c tio n d e C la u d e A u b r y www.aubryconseil.com page 28