Agnès Crépet

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