201001 agilité

Méthodes agiles et Gestion des changements

Agnès CREPET

Architecte – Laboratoires Boiron

JUG LYON – 19 janvier 2010

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!

http://www.avataria.org/

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…

Sommaire

Contexte : Boiron et Agilité

Déroulement et planification d’une itération

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


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!

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)

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

Inspiration de la méthodologie agile Boiron

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

S c r u m e n 1 0 0 m o ts

Inspiration de la méthodologie agile Boiron

Product Owner Scrum Master

Définit les fonctionnalités du produit

Définit les priorités dans le backlog en fonction de la valeur « métier »

Ajuste les fonctionnalités et les priorités à chaque itération si nécessaire

Teste les releases

Accepte ou rejette les résultats

Vulgarise les valeurs et les pratiques de Scrum

Contribue à améliorer les outils et les pratiques de l’ingénierie

Facilite une coopération poussée entre tous les rôles et fonctions

Protège l'équipe des interférences extérieures

Met l’accent sur la créativité et la gestion autonome des membres

Sommaire




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

Une itération?

A n n u le r

E m b a l la g e

R e to u r

I t é r a t io n1 m o is

R e to u r

B u t d e l’i t é r a t io n

L is t e d e st â c h e s

P r o d u i t p a r t ie l l iv r a b le e t t e s t a b le

B a c k lo gd e p r o d u i t

C o u p o n sE m b a l la g e

C o u p o n s

A n n u le r

2 4 h e u r e s

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

Mais également par le reste de l’équipe (différent de Scrum) Boiron

C e c i e s t le b a c k lo g d e p r o d u i t

Un backlog de produit Boiron

A chaque Use Case sont associées deux attributs:

Une estimation en points arbitraires On ne parle pas encore de jours

Et une priorité (métier, risque technique identifié?)

La liste peut évoluer au cours du projet

Suite au recette utilisateur en fin d’itération

Perfectible :

Chiffrage initial

9 Monitorer des lignes de préparation 10 5 1

10 Consulter une ligne de préparation 5 4

11 Lancer des fabrications 5 1

12 Pré-affecter la traçabilité 15 1

13 Editer les documents de fabrication 20 1

14 Annuler une ligne de préparation 5 2

15 Interface avec SI téléphone (prévenir préparation annulée)

5 4

16 Mettre une ligne de préparation en attente

5 2

17 Interface avec SI téléphone (allongement délai livraison / commande)

5 4

18 Réconcilier 10 1

19 Terminer une étape de préparation 10 5 1

Initial estimate exprimé en ‘points’ Importance

ou Priority

P la n i f ic a t io n d ’u n e i t é r a t io n

P é r im è t r e

• S é a n c e s d e p la n i f ic a t io n i t é r a t iv e s• A n a ly s e r e t é v a lu e r le b a c k lo g d e

p r o d u i t• D é f in i r le b u t d e l’i t é r a t io n

P la n

• D é c id e r c o m m e n t s 'y p r e n d r e (c o n c e p t io n )

(

• C r é e r la l is t e d e s t â c h e s à p a r t i r d e s é lé m e n t s d u b a c k lo g d e p r o d u i t

• E s t im e r le s tâ c h e s

B u t d e l’i t é r a t io n

L is t e d e s tâ c h e s d a n s

J IR A

C o n d i t io n sm é t ie r

C a p a c i t éd e l 'é q u ip e

B a c k lo gd e p r o d u i t

C o m p le x i t éT e c h n o s

P r o d u i ta c t u e l

Comment planifier une itération?

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 toute création ou modification de lots

Traçabilité pour toute création ou modification de lots

C o d e r la c o u c h e d e p e r s is t a n c e (1 jo u r)

(

C o d e r l 'IH M (0 ,5 jo u r )

(

E c r i r e le s te s t f ix t u r e s (0 ,5 jo u r)

(

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 t s d e p e r f o rm a n c e (0 ,5 jo u r )

(

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 d’itérations

Estimation du reste à faire

Scrum Utilisation de Burndown Charts

avec mise à jour quotidienne

Boiron Utilisation de JIRA (quotidien)

+ AUGEO (semaine/mois)

(commeKanban)

Sommaire




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 ?

Pas trop de doc…

Un peu d’UML…

Exprimer le Besoin Utilisateur

Modélisation : retour d’expériences Boiron On commence par saisir les exigences dans Enterprise Architect

Modélisation : retour d’expériences Boiron

Puis on poursuit la modélisation avec des Diagramme de cas d’utilisation

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

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…

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

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

Où se renseigner ?

• www.mountaingoatsoftware.com/scrum

• www.scrumalliance.org

• www.controlchaos.com

• [email protected]

• 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

http://www.mountaingoatsoftware.com/scrum

http://www.scrumalliance.org/

http://www.controlchaos.com/

mailto:[email protected]

http://www.frenchsug.org/

http://fr.groups.yahoo.com/group/frenchsug






Sources

T r a d u c t io n d e C la u d e A u b r y

www.aubryconseil.com

C e r t a in s S l id e s s o n t is s u s d ’u n e p r é s e n t a t io n d e M ik e C o h n s o u s l ic e n s e l ib r e

www.mountaingoatsoftware.com

201001 agilité

Technology