DevExp 2012 methodes agiles SCRUM jesnault

3 091 vues

Publié le

[ENGLISH BELLOW]
Les journees DevExp sont comme nos DreamTech meetings a Sophia Antipolis (Le partage d'expériences), mais couvrant l'ensemble des centres de l'INRIA (à travers tout le pays). Les ingénieurs se rencontrent une fois par an pendant 2/3 jours pour présenter, discuter et partager leurs travaux/experiences/point de vue. Dans mon cas (de l'INRIA Sophia Antipolis), je ai présenté notre expérimentation de la méthode agile Scrum et comment nous avons appris à l'utiliser et à l'adapter à notre contexte (SOFAVR + les autres projets en relations).

[ENGLISH]
DevExp are like our INRIA DreamTech (share engineer experiences) but covering the whole INRIA centers (through all the country). Engineers meet 1 time a year during 2/3 days to present, share and discuss about their actual works. In my case (from INRIA Sophia Antipolis) I presented our experimentation of the SCRUM agile method and how we learnt to use it and to adapt it to our context (SOFAVR and all the others related projects).

Publié dans : Ingénierie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

DevExp 2012 methodes agiles SCRUM jesnault

  1. 1. Vulgarisation des méthodes Agiles expérimentées au SED de Sophia
  2. 2. PLAN Les méthodes agiles et notre contexte SCRUM : Les acteurs et entités manipulés SCRUM : Le sprint 0 SCRUM : La planification de sprint SCRUM : Les mêlées pour s’adapter XP : Les outils d’ingénierie SCRUM : La démo et rétrospective de sprint Conclusion, ouverture Esnault Jerome - INRIA SED DREAM - 2
  3. 3. CLIENT BESOINS CONTRAT REACTIVITE AUX Méthodes AGILES INTERACTIONS CHANGEMENTS LEAN KANBAN SCRUM XP • Amélioration continue • Augmenter la productivité • Optimiser la qualité T H E O R I E EQUIPE Esnault Jerome - INRIA SED DREAM - 3 SCIENTIFIQUE Les méthodes agiles et notre contexte
  4. 4. Les méthodes agiles et notre contexte BESOINS VISIBILITE PRODUIT / PROJET FEEDBACK Valeurs agiles Personnes et interactions Logiciel qui fonctionne Collaboration continue avec le client Adaptation au changement http://agilemanifesto.org/ T H E O R I E RELEASE ITERATIONS STORIES LIVRABLES Esnault Jerome - INRIA SED DREAM - 4 Valeurs traditionnelles Processus et outils Documentation exhaustive Négociation du contrat Suivi d’un plan STORY : Ensemble des tâches permettant de réaliser un cas d’utilisation
  5. 5. Les méthodes agiles et notre contexte Et notre point de départ ? ± 4 projets (isiVR, SOFAVR, MixedReality, VCORE) ± 3 personnes (mais forte interactions externes) 1 salle (mais interventions extérieur) 1 wiki (PmWiki centralise toutes sortes d’infos) Forte interaction entre les projets (interdépendances) Projets qui n’ont pas la même ampleur : (portée réduite à l’équipe  portée européenne) Néophyte / «Newbie» SCRUM : On apprend l’agilité en même temps qu’on la pratique P R A T I Q U E Esnault Jerome - INRIA SED DREAM - 5
  6. 6. Les méthodes agiles et notre contexte Et l’évolution de notre méthode? 1er étape : issues tracking system avec PmWiki P R A T I Q U E Centralisation √ Tracker les issues √ Dépendances entre projets ≈ Planification X Simplicité √ Esnault Jerome - INRIA SED DREAM - 6
  7. 7. Les méthodes agiles et notre contexte Et l’évolution de notre méthode? 2ème étape : AgileFant P R A T I Q U E Centralisation √ Tracker les issues √ Dépendances entre projets √ Planification √ Simplicité ≈ Esnault Jerome - INRIA SED DREAM - 7
  8. 8. P R A T I Q U E Les méthodes agiles et notre contexte Et l’évolution de notre méthode? 3ème étape : IceScrum + BugZilla Centralisation ≈ Tracker les issues √ Dépendances entre projets √ Planification √ Simplicité √ Esnault Jerome - INRIA SED DREAM - 8
  9. 9. SCRUM : Les acteurs et entités manipulés Acteurs Scrum CLIENT Le SCRUM master Equipe multidisciplinaire T H E O R I E S C R U M Responsable Scientifique EPI Responsable technique Esnault Jerome - INRIA SED DREAM - 9 Le product owner P R A T I Q U E Roulement ? Membres de l’EPI
  10. 10. SCRUM : Les acteurs et entités manipulés « Entités » manipulées dans SCRUM T H E O R I E S C R U M CLIENT / RESPONSABLE SCIENTIFIQUE B A FEATURE C K L O G S => TACHES Esnault Jerome - INRIA SED DREAM - 10 STORY STORY STORY FEATURE STORY STORY STORY EQUIPE DE DEV
  11. 11. PLANNIFICATION Thèmes Features SCRUM : Le sprint 0 Esnault Jerome - INRIA SED DREAM - 11
  12. 12. SCRUM : Le sprint 0 REUNION : SPRINT 0 ≈4h Story Story Story NECESSAIRE Story Story Story Story Release 1 IMPOR TA N C E Thème 1 Thème 2 Thème 3 Story Story Story Story Story FEATURES FEATURES Release 2 FEATURES Schéma visuel prototypique CLIENT PRODUCT OWNER BUT CLIENT : perspectives utilisateurs OBJECTIFS EQUIPE : Spécifications fonctionnelles DOMAINES FONCTIONNELS INDEPENDANTS BACKLOG PRODUIT FEATURES FEATURES Release 3 T H E O R I E S C R U M Esnault Jerome - INRIA SED DREAM - 12
  13. 13. SCRUM : Le sprint 0 REUNION : SPRINT 0 CLIENT PRODUCT OWNER BUT CLIENT : ≈4h perspectives utilisateurs OBJECTIFS EQUIPE : Spécifications fonctionnelles T H E O R I E S C R U M 1ère ESTIMATION GLOBALE (JALONNAGE) Esnault Jerome - INRIA SED DREAM - 13 Sprint 1.1 temps Release 1 Release 2 Release 3 Sprint 1.N Sprint 2.1 Sprint 2.N Sprint 3.1 Sprint 3.N
  14. 14. SCRUM : Le sprint 0 Et notre sprint 0 ? P R A T I Q U E CE QU’ON A FAIT CONSEQUENCES Pas de sprint 0 avec agileFant Pas de backlog de départ et mauvaise prise en main de l’outil Sprint « -1 » avec IceScrum (démarrage avec un backlog produit suffisant pour le Esnault Jerome - INRIA SED DREAM - 14 sprint) Première prise en main plus accessible et rapide (sprint de test) Sprint 0 d’une demi journée avec une vision sur 5 mois (release 1) => définition des features + stories associées Backlog détaillé et concentré sur la release 1. Pas de vision sur les releases suivante.
  15. 15. PLANNIFICATION Thèmes / EPIC Features DECOMPOSITION Stories SCRUM : La planification de sprint Esnault Jerome - INRIA SED DREAM - 15
  16. 16. SCRUM : La planification de sprint REUNION : Planification de sprint ≈2h TRIE BRAINSTORMING CHOISISSENT BACKLOG PRODUIT BACKLOG SPRINT N TO DO RESERVED DONE PRODUCT OWNER Sprint N : • But + Durée • Membre équipe (engagement %) • Horaire de mêlée quotidienne • Date démo/rétrospective • Liste des stories (priorisées/estimées) SCRUM MASTER EQUIPE DE DEV Story Story Story Story Story Story Story Story Story Story Story T H E O R I E S C R U M SELECTION Esnault Jerome - INRIA SED DREAM - 16
  17. 17. IMPORTANCE : Permet de prioriser (trier) les stories les Propriétés d’une story T H E O R I E S C R U M unes par rapport aux autres. VELOCITE ESTIMEE : Temps en points d’histoire, nécessaire à la réalisation de la story. POKER PLANNING Esnault Jerome - INRIA SED DREAM - 17 PORTEE Définit la qualité externe attendue de cette story. SCRUM : La planification de sprint
  18. 18. SCRUM : La planification de sprint REUNION : Planification de sprint / Durée T H E O R I E S C R U M Définir la durée du sprint (idéalement 2 à 4 semaines) : CLIENT + PRODUCT OWNER CLIENT + Vélocité disponible Sprint N VELOCITE ESTIMEE EQUIPE Combien de stories nous pouvons faire avec la vélocité de notre sprint ? Esnault Jerome - INRIA SED DREAM - 18 SPRINT N = X Résultats sprint N-1 Comment estimer notre vélocité pour ce sprint ? PRODUCT OWNER EQUIPE • Trop court = • Trop long =
  19. 19. Sprint 1 (exemple) : • 3 personnes à 100% + 1 personne à 50% • Durée du sprint de 2 semaines ouvrées • Résultats sprint 1-1 …?!... prenons 70% pour commencer • Vélocité estimée du sprint : (2 x 5jrs x 3pers + 5jrs x 1 pers) x 70% = 24 points d’histoire Story 1 7pt Story 2 5pt Story 6pt Story 4 6pt Et notre planification de sprint ? BACKLOG DE FIN DU SPRINT 1 : TO DO RESERVED DONE P R A T I Q U E Esnault Jerome - INRIA SED DREAM - 19 3 Story 2 5pt Story 4 6pt Story 1 7pt Story 5 4pt Story 3 6pt 24 pts à utiliser 12 pts réelle accomplis Résultats: 50% BACKLOG PRODUIT : SCRUM : La planification de sprint
  20. 20. P R A T I Q U E SCRUM : La planification de sprint Et notre planification de sprint ? CE QU’ON A FAIT CONSEQUENCES On rempli le bac à sable d’IceScrum en attente de validation Pas d’influence, libre à tous et accessible tout le temps Brainstorming autour d’IceScrum (1machine) pour discuter des stories à valider dans le backlog Esnault Jerome - INRIA SED DREAM - 20 produit Backlog produit cohérent avec la vision de l’équipe à l’instant t… On met à jour le backlog de sprint en fonction de notre but et estimation de sprint puis on met à jour le tableau physique (post-it) …surestimation, pas de discutions autour de l’importance, la portée (pas de redécoupage), ni d’interaction autour du tableau lors des mêlées
  21. 21. ADAPTATION PLANNIFICATION DECOMPOSITION Taches Esnault Jerome - INRIA SED DREAM - 21 Thèmes / EPIC Features Stories ≈ 15jrs ≈24h ≈5mois releases sprints mêlées SCRUM : Les mêlées pour s’adapter
  22. 22. SCRUM : Les mêlées pour s’adapter Stand up : Adaptation / Mêlée IMPOR TA N C E Sérialisations Parallélisations Story t t t Story t t t t Story Story t t t t t Story t t t t t = Taches TO DO RESERVED DONE ≈15 min But : … INDICATEURS Non planifiés : … Suivant : … SCRUM MASTER Mêlée jour N : • Ou en est on ? • Gestion du temps : Tâches urgentes/récurrentes • Gestion du personnel : Décomposition des stories en taches et attribution … • Gestion de problèmes (obstacles) : stories techniques… EQUIPE DE DEV T H E O R I E S C R U M Esnault Jerome - INRIA SED DREAM - 22
  23. 23. P R A T I Q U E SCRUM : Les mêlées pour s’adapter Communication sur les sprints 100 50 0 Day 1 Day 3 Day 5 Day 7 surcharge Day 9 Day 11 Day 13 Day 15 100 50 0 Day 1 Day 3 Day 5 Day 7 Day 9 Day 11 Day 13 Day 15 équilibré BURN DOWN CHART : Vélocité estimée (pts) par rapport à la durée du sprint BAC A SABLE INFOS SPRINT -1 INDICATEURS Limiter les obstacles Préparer la suite T H E O R I E S C R U M - 23 Sous estimation Esnault Jerome - INRIA SED DREAM 100 50 0 Day 1 Day 3 Day 5 Day 7 Day 9 Day 11 Day 13 Day 15
  24. 24. ADAPTATION PLANNIFICATION DECOMPOSITION Taches Tests Esnault Jerome - INRIA SED DREAM - 24 Thèmes / EPIC Features Stories ≈ 15jrs ≈24h ≈5mois releases sprints mêlées XP: Les outils d’ingénierie
  25. 25. P R A T I Q U E XP : Les outils d’ingénierie eXtreme Programming : outils • Normes de développement • Conception simple • Programmation en binôme • Refactoring • Responsabilité collective du code • Intégration continue • Livraisons fréquentes • Planification itérative • Tests unitaires • Tests de recette • Documentation  Coding rules dispo sur notre WIKI  Design pattern (BOUML, Yuml pour WIKI)  Implication des débutants, revues de code  SCM GIT avec workflow  BugZilla  Jenkins et CMake  Demos, packaging avec CPack  IceScrum  TODO : CTest ?  Tests d’acceptations  Doxygen T H E O R I E X P Esnault Jerome - INRIA SED DREAM - 25
  26. 26. XP : Les outils d’ingénierie Pratiques eXtrem Programming : nos outils Dépôts SCM GIT / SVN PmWiki Jabber Chat API Doc HowTo Doc Continuous build From #id-Bug msg commit See sofa model : http://www.sofa-framework.org/SOFA%20day%20-%20Dec%202011%20-%20software%20engineering.pdf P R A T I Q U E Esnault Jerome - INRIA SED DREAM - 26 Doxygen Jenkins Status build Mailling Planifications Features / stories Mailling IceScrum BugTracker Features request Mailling BugZilla ? CMake / QMake
  27. 27. PLANNIFICATION DECOMPOSITION ≈ 15jrs DEMO RETROSPECTIVE ADAPTATION mêlées ≈24h releases sprints ≈5mois Esnault Jerome - INRIA SED DREAM - 27 Thèmes / EPIC Features Stories Taches Tests
  28. 28. SCRUM : La démo et rétrospective de sprint REUNION : Démo / rétrospective PRODUCT OWNER Démo / Rétrospective sprint N : ≈1h • Invitation libre à une demo du livrable obtenu par le sprint (scénario utilisateur simple) • Comment c’était? • Ou on en est (point de vue release) ? • Améliorations par rapport au sprint - 1 ? • Analyse des indicateurs : identification des freins, report de stories non finies • Analyse des activités non prévus (finis ou non) : modification du backlog ? • Points à améliorer au prochain sprint SCRUM MASTER EQUIPE DE DEV INVITES RETOUR CLIENT SUR LE LIVRABLE (affinage de la vision du projet) La boucle est bouclée T H E O R I E S C R U M Esnault Jerome - INRIA SED DREAM - 28
  29. 29. ADAPTATION releases PLANNIFICATION DECOMPOSITION sprints mêlées ≈ 15jrs DEMO RETROSPECTIVE ≈24h ≈5mois Esnault Jerome - INRIA SED DREAM - 29 Thèmes / EPIC Features Stories Taches Tests
  30. 30. P R A T I Q U E Conclusion Notre contexte : • Plus de projets que de personnel expérimentant l’agilité • Disponibilité et niveau d’engagement sur les projets très variables • Projets de différentes ampleurs (collaborations internes/externes) et interdépendants C’est notre besoin qui formate l’outils et pas l’outils qui formate notre besoin ! L’évolution de notre méthode et de nos outils : • Expérimentation « stricte » de SCRUM (méthode et outils) et couplage à des outils XP • Pour notre contexte : BESOIN D’ADAPTER NOTRE MANIERE DE TRAVAILLER MOINS NORMATIVE ET PLUS AAPTATIVE • Pas de rôles bien définis • Tableau physique peu utilisé • Capacité pas encore stabilisée • Pas de démos (que lorsque nécessaire) • Rétrospectives ne sont pas encore prises en compte dans les sprints suivants • Pas de lien entre notre outil de gestion de bug et notre outil de planification Il n’existe pas une unique bonne manière de travailler, il faut expérimenter en fonction du contexte Esnault Jerome - INRIA SED DREAM - 30
  31. 31. Réflexion autour du stress Définition : Ensemble des réactions non spécifiques d'un organisme, biologiques ou psychologiques, lorsque cet organisme est soumis à un nouveau stimulus. [granddictionnaire.com] Performance Stress optimal = challenge Stress positif Stress négatif Niveau de stress - 31 Esnault Jerome - INRIA SED DREAM
  32. 32. Références • pdf: SCRUM depuis les tranchées - Henrik Kniberg traduit par Claude Aubry • ppt: Agile tour Toulouse 2011 : Agilité à grande échelle – Claude Aubry • ppt: Agile tour Lille 2011 : L’agilité situationnelle – Claude Aubry • pdf: KANBAN & SCRUM tirer le meilleur des deux – Henrik Kniberg, Mattias Skarin et traduit par Claude Aubry, Antoine Vernois, Fabrice Aimetti • pdf: Lean depuis les tranchées – Henrik Kniberg et traduit par Claude Aubry, Sylvain Fraissé, Nicolas Mereaux, Antoine Vernois et Fabrice Aimetti • book: SCRUM le guide pratique de la méthode agile la plus populaire – Claude Aubry • blog : www.openagile.net • bolg : bootstrapping an agile project in the cloud • site : www.IceScrum.org • site : www.aubryconseil.com • site : www.qualitystreet.fr • site : http://referentiel.institut-agile.fr/kanban.html • pdf : 10 kanban boards and their context • ppt : Management 3.0 : Leading Agile Developers, developing Agile Leaders – Jurgen Appelo • book: Management de Projet fondamentaux, méthodes, outils – Jean-Claude Corbel Esnault Jerome - INRIA SED DREAM - 32
  33. 33. MERCI
  34. 34. Méthodes traditionnelles Analyse / Etude Codage Recette Spécification Conception Test Validation Ces phases ne s’enchainent pas vraiment séquentiellement (sans réel retour) Portées et délais fixes pour chaque phase (généralement non respectées) Pas de critère de complétion des phases (deadLine = finie) Non implication du client dans le projet Mécontentement généralisé T H E O R I E Esnault Jerome - INRIA SED DREAM - 35
  35. 35. • Optimiser la qualité ? « Un produit ou service de qualité est un produit dont les caractéristiques lui permettent de satisfaire les besoins exprimés ou implicites des consommateurs". l’AFNOR (Association Française de NORmalisation) Affinage régulier de la « zone de satisfaction du client » et de la direction de l’équipe N critères de satisfaction client = univers du projet à N dimensions objectif fixe T H E O R I E délais Esnault Jerome - INRIA SED DREAM - 36 perf coût t0 t1
  36. 36. “Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients” Veronique Messager Rota - Gestion de projet : Vers les méthodes agiles Valeurs traditionnelles Processus et outils Documentation exhaustive Négociation du contrat Suivi d’un plan BESOINS VISIBILITE FEEDBACK Valeurs agiles Personnes et interactions Logiciel qui fonctionne Collaboration continue avec le client Adaptation au changement http://agilemanifesto.org/ T H E O R I E PRODUIT / PROJET RELEASE ITERATIONS STORIES LIVRABLES Esnault Jerome - INRIA SED DREAM - 37
  37. 37. « Entités » manipulées dans SCRUM client équipe finies dans une release FEATURES STORIES TASKS finies dans un sprint Product Backlog : Detailed Estimated Evolutionary Prioritized User Story (objectif du client) / Technical Story (objectifs de l’équipe) : En tant que « Utilisateur », je veux « fonction », dans le but de Sprint Backlog : Splitted stories Health indicators S TOR I E S Obstacles gestion Regular revieview Testable tasks « résultat attendu ». T H E O R I E S C R U M • Le backlog produit contient tous les éléments (définies ou à venir) du projet . • Chaque backlog de sprint contient toutes les stories (sélectionnées depuis le backlog produit) à finir dans un sprint. Esnault Jerome - INRIA SED DREAM - 38
  38. 38. Agile et outsourcing Logiciel de méthodes agiles via plateforme internet (iceScrum-AgileFant) Efficacité de la communication Conversation face à face avec support (tableau) + cafè? Visio conférence Conversation face à face Echange de mails Chat écrit Papier Enregistrement video Documentation en ligne Enregistrement audio Chat audio Richesse de la communication static dynamique Risques : • meeting plus long et moins interactif • barrière de la culture et de la langue T H E O R I E Esnault Jerome - INRIA SED DREAM - 39
  39. 39. Conclusion cela permet d'éviter « l'effet tunnel » Les points positifs : • Méthode à flux tirés et non poussés • Méthode itérative et incrémentielle • Méthode participative et adaptative (flexible) T • Communication et coopération efficace et riche H E Les risques : • Si taille de l'équipe > 10 et dispatchée O R I E => organisation difficile (cohésion de groupe, qualité de comm…) ? => besoin de décomposer en scrum de scrum (équipes de 7-10 max) • Réticence à l’évolutivité, réactions aux changements (Procrastination) => appréhension à faire évoluer (refactoring) un code qui marche déjà => besoin d’outils XP (coding rules, SCM, intégration continue, tests…) • Le turnover => impact directement la capacité / stabilité de l’équipe Esnault Jerome - INRIA SED DREAM - 40
  40. 40. Nos ouvertures : KANBAN Passage à une méthode moins normative et plus adaptative : KANBAN • Ne pas imposer de rôle précis ni de livrable quotidien, planifier le TAF (Travail A Faire) au fur et à mesure et ne livrer que lorsque c’est demandé. • Utiliser un tableau KANBAN pour toute la durée du projet plutôt que d’avoir un tableau de sprint par itération. => impliquerait d’avoir un découpage régulier ( ± même taille) des éléments à faire. • Limiter le TAF (Travail A Faire) de chaque étape du workflow plutôt que de chaque itération permettra d’identifier plus rapidement les goulets d’étranglements et de réagir plus vite. • Autoriser les changements au court d’une itération (en respectant la règle ci-dessus) plutôt que d’essayer de fixer une itération (avec des stories non modifiables). • Utiliser le burndown chart le temps d’un jalon/release plutôt que pour une itération ET / OU le diagramme de flux cumulés (pour modifier les capacités). Continuer d’adapter, d’expérimenter et de faire évoluer vers notre propre méthode ! Esnault Jerome - INRIA SED DREAM - 41 T H E O R I E K A N B A N
  41. 41. KANBAN : exemple Exemple de diagramme de flux cumulé Backlog Dev Test/Déploiement Prod Capacité moyenne : 1 item/jour 6 jours dont 3 en test Esnault Jerome - INRIA SED DREAM - 42 T H E O R I E K A N B A N 30 25 20 15 10 5 0 9 items 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Nombre d’items (TAF) Jours Objectif : Lisser le flux et limiter le travail à la capacité « disponible » : minimiser le nombre d’éléments séjournant dans les files.
  42. 42. Limiter la phase de TEST/DEPLOIEMENT à 2 éléments : BACKLOG RESERVED TEST/DEP A Esnault Jerome - INRIA SED DREAM - 43 T H E O R I E K A N B A N DEV WIP DONE PROD C B D E F H 3 4 L M N O P I dépend de G et On a besoin de J et K J E et F sont terminés, on prend G C ne compile pas et D dépend de C, on est bloqué 2 H est terminé, on ne peut pas commencer un autre item (limite à 4) On vient en renfort ! I Protection contre les perturbations K G

×