201001 Agilité

961 views
873 views

Published on

Agnès Crépet

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
961
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

201001 Agilité

  1. 1. Méthodes agiles et Gestion des changements Agnès CREPETArchitecte – Laboratoires Boiron JUG LYON – 19 janvier 2010 page 1
  2. 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. 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. 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. 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. 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. 7. Inspiration de la méthodologie agile BoironU 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 quUML (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. 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 sorganise 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. 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. 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. 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. 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. 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 OwnerC 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. 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. 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 nd 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 nC 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 itC o m p le x ité • E s tim e r le s tâ c h e s Technos page 15
  16. 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éeTraç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 lIH M (0 ,5 jo u r )toute création outoute 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 lotsmodification 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. 17. Vie du backlog de l’itération Lestimation du reste à faire est ajustée tous les jours (Stand-up / JIRA)  Mise à jour du travail restant quand il est mieux connu Nimporte qui peut ajouter, supprimer ou changer la liste des tâches en stand-up Si un travail nest 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. 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. 19. Agilité et UML Comment documenter / modéliser un besoin ? 2 approches semblent opposées :  lapproche Model-Driven, préconisée par lOMG, sappuyant 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 laccent sur la production rapide de code opérationnel que sur la documentation et minimisant donc la modélisation en amont Lagilité se passe de plus en plus dUML 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. 20. Exprimer le Besoin Utilisateur Pas trop de doc… Un peu d’UML… page 20
  21. 21. Modélisation : retour d’expériences Boiron On commence par saisir les exigences dans Enterprise Architect page 21
  22. 22. Modélisation : retour d’expériences Boiron Puis on poursuit la modélisation avec des Diagramme de cas d’utilisation page 22
  23. 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. 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. 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. 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 dEsther 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. 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. 28. SourcesC 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

×