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
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