DevExp 2012 methodes agiles SCRUM jesnault
•
4 j'aime•3,956 vues
[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).
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à DevExp 2012 methodes agiles SCRUM jesnault
Similaire à DevExp 2012 methodes agiles SCRUM jesnault (20)
Dernier
Dernier (8)
DevExp 2012 methodes agiles SCRUM jesnault
- 1. Vulgarisation des méthodes Agiles expérimentées au SED de Sophia
- 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. 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. 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. 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. 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. 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. 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. 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. 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. PLANNIFICATION Thèmes Features SCRUM : Le sprint 0 Esnault Jerome - INRIA SED DREAM - 11
- 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. 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. 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. PLANNIFICATION Thèmes / EPIC Features DECOMPOSITION Stories SCRUM : La planification de sprint Esnault Jerome - INRIA SED DREAM - 15
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. MERCI
- 35. 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
- 36. • 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
- 37. “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
- 38. « 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
- 39. 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
- 40. 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
- 41. 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
- 42. 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.
- 43. 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
Notes de l'éditeur
- LEAN n’est donc pas en soi une méthode de gestion de projet. Il s’agit plus certainement d’un cadre de travail, regroupant des méthodes telles que RAD (rapid development software), Scrum et XP, KANBAN… mais surtout des valeurs. Cependant nous noterons que ces méthodes ont des points en commun tels que les cycles de développement itératif, incrémental et adaptatif. La grande idée derrière Agile est de concevoir un produit qui satisfait le client et ses besoins au lieu de satisfaire les termes d’un contrat. Cela implique une plus grande interaction avec le client afin d’obtenir une grande réactivité face à des demandes. Agile permet donc d’obtenir des logiciels de meilleur qualité et adaptés au besoin réel. L’accent est donc mis sur la réactivité au changement et l’interaction entre les individus. Dès lors MOE (maitre d’œuvre – chargé de projet) et MOA (maitre d’ouvrage – propriétaire/commanditaire) sont en phase pour arriver ensemble à un objectif commun, avec un travail d’équipe. Notez que si Agile est essentiellement appliquée à la conception de logiciels, on notera cependant une tendance à l’appliquer dans le cadre général de management agile, qui met l’accent sur l’amélioration continue de la qualité (MTQS - Managerial Technical Qualifications ou Lean - http://www.logistiqueconseil.org/Articles/Logistique/Lean-management.htm). LEAN: S’applicant pour tous domaines/secteurs d’activités. Le Lean management est de ce fait une technique de gestion essentiellement concentrée vers la réduction des pertes générés à l’intérieur d’une organisation, pour une production et un rendement plus justes (apparu dans les année 70 avec l’entreprise Toyota). réduire la durée des cycles de production, diminuer les stocks, augmenter la productivité, optimiser la qualité. Le Lean management repose sur le facteur humain. Il suggère que le personnel travaille dans un état d’esprit orienté vers la diminution du gaspillage et des pertes (de temps, de matières, d’argent …). La motivation et les comportements des hommes sont nécessaires pour une application efficace. (5M, PDCA, QQOQCP…) Le Lean ne vous donne pas un ensemble spécifique de techniques pour gérer le travail, mais plutôt un ensemble de principes destinés à vous aider à décider comment livrer le plus de valeur avec le moindre effort, et comment continuer à améliorer vos techniques actuelles. Les principes du Lean englobent donc l'utilisation de Scrum et Kanban ainsi que d'autres méthodes de gestion du travail. Parfois, les gens sont frustrés parce que le Lean ne fournit pas un ensemble de règles sur la façon de faire les choses, mais plutôt un ensemble d'outils de réflexion (principes). Pour ces personnes, Scrum et/ou Kanban constituent de très bons points de départ. Mais le Lean fera que chaque entreprise mettre d'abord en oeuvre ces techniques, les améliorera constamment, et après quelques années, Scrum et Kanban auront évolué et changé en quelque chose de très différent de ce qu'il y avait au départ. KANBAN: (définition brut) : Kanban : Terme japonais qui signifie étiquette, fiche ou carte. Méthode de gestion des réapprovisionnements d'origine japonaise consistant à créer un circuit d'étiquettes, les unes accompagnant les conteneurs des produits gérés, les autres s'accumulant sur un tableau jusqu'au déclenchement du réapprovisionnement. Le Kanban permet de gérer visuellement les flux de matériel et l'ordonnancement des cellules de travail. Basé sur le principe de production à flux tiré (la production à déjà commencée avant la réception de commande de manière à spécialiser le produit plus rapidement sur la base des précédant travaux; à l’inverse de la production à flux poussé => prévision de vente et on produit ensuite tout d’un coup suivant un cycle séquentiel), le kanban permet d'optimiser les stocks en cours et de diminuer la taille des lots. Le tableau de KANBAN est unique durant toute la durée du projet et chaque colone du tableau (TO DO, SELECTED, IN PROGRESS, DONE, DEPLOY) limite le nombre d’entrées. Principe du flux continue limité : Un exemple de mesures de sous-optimisation est le fait de s'assurer dans certaines entreprises que tout le monde est occupé tout le temps ; et généralement cela se fait en demandant aux gens de travailler sur plusieurs choses en même temps. Pourtant, cette stratégie entraîne un énorme gaspillage car un taux d'utilisation élevé crée l'équivalent des embouteillages et ralentit tout au fur et à mesure que le temps dépensé pour passer d'une tâche à une autre augmente. SCRUM : Scrum est une méthode de développement agile orientée gestion de projet informatique (« haut niveau ») dont les ressources sont régulièrement actualisées. La méthode Scrum tire son nom du monde du rugby, scrum = mêlée. Le principe de base étant d'être toujours prêt à réorienter le projet au fil de son avancement. C'est une approche dynamique et participative de la conduite du projet. Scrum est essentiellement une méthode permettant d'accomplir un travail cadencé par itérations. Kanban est une méthode permettant d'accomplir un travail en limitant les travaux en cours et en gérant les flux. Certains travaux (en particulier créatifs) sont plus efficacement traités avec des itérations, alors que d'autres travaux (en particulier naturellement séquentiels) sont plus naturellement gérés avec Kanban. En règle générale, vous devez utiliser l'une ou l'autre de ces techniques, mais pas les deux en même temps pour le même travail. Déterminer la meilleure technique de gestion du travail dans un contexte donné devrait être réalisé en menant des expériences et en mesurant les résultats aux différents niveaux d'un système. XP: 'Extreme Programming (XP) est une méthode de développement logiciel (« bas niveau »), c'est-à-dire un ensemble de pratiques/outils destinées à organiser le travail d'une équipe de développement (orienté équipe de dev). Ces pratiques se focalisent sur la construction proprement dite du logiciel, en aval des phases préparatoires d'études d'opportunité ou de faisabilité (cf. lean). L'heure est à l'économie et à l'efficacité. XP propose un ensemble de pratiques organisées autour des principes suivants : Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines). L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des développements. L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses membres. L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au produit un niveau de robustesse très élevé. Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides. Source : http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/04/09/Entretien-avec-Mary-Poppendieck-sur-le-Lean-Scrum-Kanban-et-le-Leadership
- “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 L’agilité, c’est d’abord des Valeurs (4) et des PRINCIPES (12)… * Les individus et les interactions plutôt que les processus et les outils * Des fonctionnalités opérationnelles plutôt qu’une documentation exhaustive * Collaboration avec le client plutôt que la contractualisation des relations * Acceptation du changement plutôt que la conformité aux plans * Satisfaire le client est la priorité * Accueillir les demandes de changement « à bras ouverts » * Livrer le plus souvent possible des versions opérationnelles de l’application * Assurer une coopération permanente entre Client et Equipe projet * Construire des projets autour d’individus motivés * Privilégier la conversation en face à face * Mesurer l’avancement du projet en termes de fonctionnalités de l’application * Faire avancer le projet à un rythme soutenable et constant * Porter une attention continue à l’excellence technique et à la conception * Favoriser la simplicité * Responsabiliser les équipes: les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées. * Ajuster, à intervalles réguliers, son comportement, ses processus pour être plus efficace Source : http://www.qualitystreet.fr/2009/06/21/agile-et-lean-booster-dinnovation/ source: http://www.qualitystreet.fr/2007/11/20/methodes-agiles-un-belle-definition/ STORY exemple : En tant qu’internaute, je veux pouvoir me loguer sur le wiki de l’équipe afin d’y ajouter des informations. TACHES exemple: Créer un formulaire et une interface utilisateur; enregistrer les utilisateurs dans une base de donnée, autoriser la lecteur et l’écriture sur le wiki.
- Interventions dans différents projets Personnel qui varie régulièrement entre les personnes à engagement variable (50%) et les invités Cœur de l’équipe dans une salle mais collaborations externe régulières
- Suffi pas d’un point de vue visibilité => plannification Peu de fonctionnalités :pas d’évolution de l’outils possible (ou besoin de dev derrière)
- Les + : Les - :
- La méthode SCRUM est planifiée selon 3 niveaux. Le fait qu’il n’y ait pas beaucoup de niveaux permet de simplifier la planification et son organisation. Les 3 niveaux différents sont le projet, les release (version du projet) et les sprints (moment de travail). Le directeur de produit Le directeur de produit est la personne qui représente le client à l’intérieur même de l’équipe : c’est lui qui définit l’ordre et la priorité de chaque fonctionnalité. En cas de besoin d’orientation du projet, c’est à lui que revient cette responsabilité. Une fois encore, le terme de directeur n’est pas à associer au sens hiérarchique du terme : il travaille en étroite collaboration avec l’équipe. Le SCRUM master Il collabore avec le directeur de produit. Il veille au respect des valeurs de la méthode SCRUM. Il protège l’équipe des « éléments perturbateurs ». Equipe : D'une taille allant de 4 à 10 personnes idéalement multidisciplinaire pour favoriser le partage de connaissance (l'équipe regroupe tous les rôles habituellement nécessaires à un projet, à savoir l'architecte, le concepteur, le développeur, le testeur, etc.) L'équipe s'organise elle-même et elle reste inchangée pendant toute la durée d'un sprint. Membre de l’EPI mais peu varier d’un sprint à l’autre Source: http://www.pentalog.fr/offre/methodologie_agile_scrum.htm
- L’abreviation pour définir le backlog : DEEP [source: http://www.qualitystreet.fr/2010/02/05/dans-scrum-mon-backlog-de-produit-est-deep/] Autres sources : http://www.qualitystreet.fr/2008/08/25/des-user-stories-de-qualite/ Exemple de user story : http://www.mountaingoatsoftware.com/scrum/sprint-backlog Feature L'élaboration de la vision du produit passe par l'identification des features. Le terme features est abondamment utilisé dans le domaine de l'ingénierie des exigences [2]. Il y a même une méthode agile qui l'utilise dans son nom : Feature driven development ou FDD. Elles apportent suffisamment de valeurs pour être release (finie dans une release). Theme Un theme est une collection de stories, et peu donc regrouper plusieurs features. L'intérêt des themes est évident quand il s'agit de définir les priorités : c'est bien plus facile à faire sur 5 à 10 themes que sur des dizaines de stories. Epic Une epic est une grosse story. Elle est en attente de décomposition en stories "normales". L'intérêt d'avoir des epics est qu'il ne sert à rien de décomposer trop tôt : il est préférable de le faire au dernier moment raisonnable. On pourrait dire épopée ? épisode ? Activités => taches techniques => matière brute de travail 1 Activity = N tasks : “Read an email message” is a task, “Managing email” is an activity.
- Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
- Le(s) Objectif(s) (le « Quoi ? ») => La valeur ajoutée, les spécifications fonctionnelles Le but (le « Pourquoi ?») => Les perspectives utilisateurs Plus l’importance est forte et plus le niveau de détail des stories/EPICS sont élevés (éventuellement découpées). PROCEDURE : identifier les themes, en regroupant éventuellement des features pour en obtenir de 5 à 10 et en les consolidant de façon à constituer des domaines fonctionnels indépendants. Les themes seront utilisés dans le backlog comme attribut des stories. décider des priorités entre les themes, par une session de priority poker ou un autre moyen comme la sélection de themes basée sur des critères de satisfaction[4]. pour les 1 ou 2 themes les plus prioritaires, décomposer en stories détaillées (normales), en pratiquant par exemple un story workshop. Les stories, avec leur theme, sont placées dans le backlog. pour les autres themes, la ou les features correspondant deviennent des epics, ordonnés en utilisant les priorités définies sur les themes. Source: http://www.aubryconseil.com/post/2007/10/04/305-features-themes-epics-et-stories http://www.openagile.net/?page_id=52
- Le(s) Objectif(s) (le « Quoi ? ») => La valeur ajoutée, les spécifications fonctionnelles Le but (le « Pourquoi ?») => Les perspectives utilisateurs Plus l’importance est forte et plus le niveau de détail des stories/EPICS sont élevés (éventuellement découpées). PROCEDURE : identifier les themes, en regroupant éventuellement des features pour en obtenir de 5 à 10 et en les consolidant de façon à constituer des domaines fonctionnels indépendants. Les themes seront utilisés dans le backlog comme attribut des stories. décider des priorités entre les themes, par une session de priority poker ou un autre moyen comme la sélection de themes basée sur des critères de satisfaction[4]. pour les 1 ou 2 themes les plus prioritaires, décomposer en stories détaillées (normales), en pratiquant par exemple un story workshop. Les stories, avec leur theme, sont placées dans le backlog. pour les autres themes, la ou les features correspondant deviennent des epics, ordonnés en utilisant les priorités définies sur les themes. Source: http://www.aubryconseil.com/post/2007/10/04/305-features-themes-epics-et-stories http://www.openagile.net/?page_id=52
- On apprend en même temps qu’on pratique. 1- On savait pas qu’il y avait une grosse réunion de planification prévisionnel pour définir et estimer les jalons du projet. 2- IceScrum est plus accessible est intuitif à utiliser (moins de paramètres à régler mais plus de contraintes SCRUM à respecter) 3- Lancement de nos premiers sprints avec IceScrum en commençant par le sprint 0
- Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
- BACKLOG PRODUIT (TO DO for FEATURES) BACKLOG SPRINT N (TO DO for SPRINT) Source : http://www.openagile.net/?page_id=52
- Portée : Qualité externe => est ce qui est perçu par les utilisateurs du système (une interface utilisateur lente et pas intuitive est un exemple de mauvaise qualité externe). product owner peut diminuer la portée ou la écouper en 2 stories pour influencer les choix de l’équipe. Qualité interne => non négociable => fait référence à des points qui habituellement ne sont pas visibles par l’utilisateur, mais qui ont un profond effet sur la maintenabilité du système. La cohérence de la conception, la couverture de test, la lisibilité du code, les remaniements (refactoring)… Estimation : 1er Facteur de focalisation pour commencer environ 70% Importance : product owner peut influencer l’équipe en changeant l’ordre de priorité des sorties Selection pour prochain sprint : Valeur métier (quelles fonctionnalités seraient le plus appréciées par le client) Connaissance (quelles fonctionnalités apporteront de la connaissance et par conséquent, réduiront les risques) Utilisation des ressources (équilibrer les domaines fonctionnels pour donner du travail à tout le monde) Dépendances (quelles fonctionnalités sont à construire les unes par rapport aux autres) Testabilité (quelles fonctionnalités devraient être développées ensemble pour un test logique) VELOCITE: Mesure permettant d’estimer la capacité. CAPACITE : Quantité d’éléments livrés par sprint.
- Trop court = client + product owner content (visu/affinage du produit ) équipe plus bridée (plus de meeting/livrables, moins de résolution de problèmes, stress) Trop long = client + product owner bridée (intervention moins régulière/confiance) équipe plus libre (monté en puissance de l’équipe, meilleur qualité de support) En partant de cette vélocité et du total de points à réaliser, on peut déterminer le nombre de sprints qui seront nécessaires pour terminer le projet (ou la release en cours). L'intérêt, c'est qu'on a une vision de plus en plus fiable (retours d'expérience de sprint en sprint) de la date d'aboutissement du projet, tout en permettant d'aménager les items de backlog du produit en cours de route.
- Facteur de focalisation pour sprint 2 = 12/24 = 50%
- Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
- http://www.aubryconseil.com/post/Scrum-et-les-taches-urgentes http://www.openagile.net/?page_id=52
- Planifier et mesurer l’avancement : Gantt VS Burn down Chart Les personnes habituées aux méthodes en cascades et autres cycles en V peuvent désormais se demander de quelle manière on peut mesurer et se rendre compte de l’avancement d’un projet Agile. En effet vous noterez l’absence jusqu’à présent de tout diagramme de Gantt, Pert ou assimilé. En effet un diagramme de Gantt n’est pas approprié car il est généralement conçut en début de projet. Puis une personne est chargée de l’annoter avec l’état d’avancement et la mesure des écarts (généralement le chef de projet). Enfin, une fois le projet terminé, il est temps de rendre compte des erreurs d’appréciations dans l’évaluation et la planification préliminaire. On note donc trois moments dévoreurs de la ressource temps : création du diagramme de Gantt maintenance et suivie du diagramme de Gantt rendre comptes des erreurs et des écarts Ce diagramme de Gantt doit être maintenu grâce à un logiciel, et est très souvent visible uniquement par le chef de projet, qui devra par ailleurs aller chercher les informations sur l’avancement auprès des développeurs. Ces derniers seront très certainement réticents à prendre du temps pour mesurer leur progression. Pour eux, cette tâche n’apporte pas de valeur au produit (et ils n’ont pas complètement tort). Nous avons vu que la méthode Scrum implique une planification courte, par Sprints de 1 à 3 semaines, qui se répètent de manière itérative (pas de planification à moyen ou long terme). Au sein de ces sprints, chaque développeur est maître de son temps, et effectue lui-même l’étude de l’avancée de ses travaux. Il n’existe pas d’outil imposé pour le suivi d’un projet Scrum. Cependant, on peut utiliser un élément très visuel, et surtout visible par tous, tels qu’un tableau d’avancement de sprint associé à un burn down chart. Les fonctionnalités à implémenter sont classés dans ce tableau d’avancement selon trois colonnes : à faire, en cours, fait. Quand au burn down chart, il s’agit d’une courbe qui donne une indication de l’avancée par rapport au temps. Source : http://blog.vincentbrouillet.com/post/2010/05/30/Comparaison-gestion-de-projet-Agile-VS-traditionnel-pour-SAAS%3A-%28Partie-2/3%29
- Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
- http://www.aubryconseil.com/post/2007/01/11/154-discussion-sur-les-merites-du-pair-programming http://seanron.free.fr/index.php?article7/la-methode-agile-scrum-et-extreme-programming http://www.slideshare.net/jcgrosjean/methodes-agiles-scrum-et-xp-pdjsqli-presentation?type=powerpoint http://www.regismedina.com/articles/fr/extreme-programming Réductionnisme : http://www.merriam-webster.com/dictionary/reductionism
- Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
- Quelques post-it : - arrêter la réunion du matin - réunion du matin trop tard (9h30) - réunion du matin à faire sous timer (chronométrage ! ) [dure actuellement entre 15 et 25 min] - faire la réunion tous les 2 jours - faire une réunion par semaine - ralentir le rythme des réunions - estimation des taches incorrecte - tests insuffisamment définis sur les tâches de conception, de programmation - à confirmer : les réunions de revues avec les clients, l'aide sur les tâches annexes - des oublis de tâches au tableau de sprint
- Les sprints La méthode SCRUM est une méthode itérative, le projet avance par « à-coups », ces moments de travail qui font avancer le projet sont les itérations de la méthode, elles sont appelées dans le jargon usuel des sprints. Les sprints sont à longueur variables et s’étendent sur une durée de 1 semaine à 3 semaines. Pour optimiser les sprints, des objectifs réalisables avec un but précis sont définis. Une liste de fonctionnalités est également définie par le directeur de produit avec l’équipe. Ces différentes fonctionnalités seront décomposées en sous fonctionnalité si elles demandent trop de temps. La daily SCRUM En théorie, chaque journée commence par une courte réunion de 15 minutes. Chaque membre de l’équipe dit ce qu’il a fait, ce qu’il compte faire et les difficultés éventuelles qu’il rencontre. Chacun a un temps de parole et ne peut être interrompu. Durant cette réunion le SCRUM master est présent, il peut prendre note des difficultés rencontrées par l’équipe et de l’état d’avancement. Les releases Les releases sont des versions du projet pas obligatoirement finies, mais utilisables. Comme nous l’avons vu précédemment sur le schéma, les releases sont composés d’un certain nombre de sprints. Une fois encore le nombre de sprints est à adapter en fonction du projet et de son équipe
- 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) Communication et coopération efficace et riche Cela permet d'éviter « l'effet tunnel » Les risques : Si taille de l'équipe > 10 et dispatché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 Projets: isiVR, SOFA, SOFAVR, MR, VCORE, CMAKETOOLS, NIEVE, DogPhobia… Dispo très variables : beaucoup de CP, interventions dans d’autres projets, réunions non prévisibles… A vouloir trop utiliser le formalisme SCRUM, la méthode et les outils nous ont formaté alors qu’il ne correspond pas tout à fait notre contexte. FINAL: Garder une methode souple au début, puis l’adapter à notre contexte. Attention: C’est notre besoin qui formate l’outils et pas l’outils qui formate notre besoin ! Tableau physique peu utilisé : (communication indirecte par les interactions dans IceScrum) Capacité pas encore stabilisée (sur-estimation lors des planifications de sprint)
- AGILE: Ca nous aide Ca nous organise Mais ca prend u temps Il faut que l’équipe complète s’investisse Peu engendrer du stress négatif (conflit sur la manière de bosser, conflit de perssone, conflits hierarchique, pression (trop de travail)? http://sebastienboyer.wordpress.com/2012/03/18/ http://www.granddictionnaire.com/btml/fra/r_motclef/index800_1.asp http://www.lfsm.org/IMG/pdf/intervention_Patrick_Legeron.pdf http://www.travailler-mieux.gouv.fr/IMG/pdf/livreblancstress.pdf LES STRESSEURS LIÉS AU CONTENU DU TRAVAIL Pénibilité physique Pénibilité mentale Charge de travail Responsabilités LES STRESSEURS LIÉS AU CONTEXTE DE TRAVAIL Changements Incertitudes Organisation de l’entreprise Conflits de valeurs LES STRESSEURS LIÉS À L’INDIVIDU Non adéquation des compétences au poste Frustrations matérielles Frustrations psychologiques Absence d’intérêt LES STRESSEURS LIÉS AUX DIFFICULTÉS RELATIONNELLES Avec la hiérarchie Avec les pairs Avec les individus sous sa responsabilité Avec le public et/ou les clients
- Source : http://dchaffiol.free.fr/info/chefprj/art_xp_t.htm Autres : http://dchaffiol.free.fr/info/blagues/art_bg_cycleEnV.htm http://blog.vincentbrouillet.com/post/2011/01/30/Comparaison-gestion-de-projet-Agile-VS-traditionnel-pour-SAAS%3A-%28Partie-1/3%29 http://www.aubryconseil.com/post/2007/01/23/162-le-cycle-de-vie-en-v-n-existe-pas
- La qualité est donc une notion relative basée sur le besoin. On doit en général rechercher davantage une qualité optimum, qu’une qualité maximum. "la qualité, c'est la conformité aux exigences". « les exigences de qui ? », « Ce qui est apprécié d’une personne », mais comment ce manifeste ce sentiment chez cette personne? Pour répondre aux critères de qualité, il faut donc tester auprès du client : - si les résultats obtenus lui sont satisfaisant , - ce que l'on veut définir ou redéfinir comme résultat à atteindre. Il faut également se demander, une fois ses "intentions" précisées, si l'on sait comment s'y diriger, pour satisfaire ses intentions. On ne va pas vers un objectif fixe, on se dirige vers un ou plusieurs buts qui forment la "zone de satisfaction du client", zone sans cesse affinée avec lui (le client). Parce que la satisfaction du client dépend de critères multiples, définissant chacune une "dimension". On en connaît, les plus classiques : le coût et les délais. Mais il y en a plein d'autres : la qualité de service (performance, temps d'indisponibilité minimal, etc...). Définir une solution unique qui répond du premier coup à tout ces critères revient à vouloir définir un point et un chemin précis dans un univers (ou hypercube) à n-dimensions : c'est très compliqué. Il est plus simple de se mettre d'accord sur une "zone" générale de ce même hypercube (dont chacune des dimensions représente un axe binaire de critère de satisfaction client), et de viser cette zone en se définissant un « vecteur » dont on affinera régulièrement la direction. Pour mettre en place une tel qualité il faut communiquer avec le client, avoir le courage de prendre une direction générale pour aller simplement vers cette zone et vérifier régulièrement auprès du client si l'on va toujours dans le sens qu'il souhaite. De cette dernière phrase découlent les 4 valeurs fondamentales : la communication, le courage, la simplicité et le feedback. Oui, la qualité revient donc à placer en objectif prioritaire le fait que quelqu'un apprécie son travail. Cette appréciation est mise dans un mécanisme de feedback, sachant que le contenu même du travail reste libre : on fait ce que l'on veut pourvu que l'on ait un retour régulier et une appréciation positive. Si l'appréciation n'est pas positive, il ne faut pas avoir peur du changement. Plus simplement, on brise le mythe de conception qui définirait la solution atteignable que via un "process balistique" (on vise, on tire... et on espère atteindre l'objectif initialement visé!) : XP voit la qualité comme un process de pilotage "à tête chercheuse". Source : http://dchaffiol.free.fr/info/chefprj/art_xp_t.htm
- L’agilité, c’est d’abord des Valeurs (4) et des PRINCIPES (12)… * Les individus et les interactions plutôt que les processus et les outils * Des fonctionnalités opérationnelles plutôt qu’une documentation exhaustive * Collaboration avec le client plutôt que la contractualisation des relations * Acceptation du changement plutôt que la conformité aux plans * Satisfaire le client est la priorité * Accueillir les demandes de changement « à bras ouverts » * Livrer le plus souvent possible des versions opérationnelles de l’application * Assurer une coopération permanente entre Client et Equipe projet * Construire des projets autour d’individus motivés * Privilégier la conversation en face à face * Mesurer l’avancement du projet en termes de fonctionnalités de l’application * Faire avancer le projet à un rythme soutenable et constant * Porter une attention continue à l’excellence technique et à la conception * Favoriser la simplicité * Responsabiliser les équipes: les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées. * Ajuster, à intervalles réguliers, son comportement, ses processus pour être plus efficace Source : http://www.qualitystreet.fr/2009/06/21/agile-et-lean-booster-dinnovation/ source: http://www.qualitystreet.fr/2007/11/20/methodes-agiles-un-belle-definition/
- L’abreviation pour définir le backlog : DEEP [source: http://www.qualitystreet.fr/2010/02/05/dans-scrum-mon-backlog-de-produit-est-deep/] Autres sources : http://www.qualitystreet.fr/2008/08/25/des-user-stories-de-qualite/ Exemple de user story : http://www.mountaingoatsoftware.com/scrum/sprint-backlog Feature L'élaboration de la vision du produit passe par l'identification des features. Le terme features est abondamment utilisé dans le domaine de l'ingénierie des exigences [2]. Il y a même une méthode agile qui l'utilise dans son nom : Feature driven development ou FDD. Elles apportent suffisamment de valeurs pour être release (finie dans une release). Theme Un theme est une collection de stories, et peu donc regrouper plusieurs features. L'intérêt des themes est évident quand il s'agit de définir les priorités : c'est bien plus facile à faire sur 5 à 10 themes que sur des dizaines de stories. Epic Une epic est une grosse story. Elle est en attente de décomposition en stories "normales". L'intérêt d'avoir des epics est qu'il ne sert à rien de décomposer trop tôt : il est préférable de le faire au dernier moment raisonnable. On pourrait dire épopée ? épisode ? Activités => taches techniques => matière brute de travail 1 Activity = N tasks : “Read an email message” is a task, “Managing email” is an activity.
- Agile et outsourcing L’outsourcing consiste externaliser la partie développement, c'est-à-dire l’écriture du code. Le plus souvent on outsource vers des pays à faible coûts tels que l’Inde, la Chine ou même la Russie, ou encore l’Argentine. Ces pays ont à disposition une main d’ouvre compétente pour effectuer le développement. D’une manière générale, le management du projet, l’étude et l’analyse des besoins et la conception sont effectués sur place. L’écriture du code est réalisée par une équipe « outsourcée ». Ce mode de fonctionnement est "plus facile" à concevoir lorsque le projet est très spécifié. Il "suffit" alors de remettre à l’équipe de développement toute la documentation qui a été produite, et il ne leur reste plus qu’à implémenter et valider les résultats. Que le résultat soit en adéquation avec les specifications est un autre debat (voir Partie 1: Défauts des méthodes traditionnelles). Cependant, le challenge est tout autre avec une méthode Agile. Agile c’est la capacité à s’adapter et à réagir rapidement face au changement. Dès lors, on a une contradiction : comment communiquer au quotidien efficacement entre deux équipes distantes, issus de différentes cultures? Comment, par exemple, mener à bien une réunion de type « daily standup meeting » (littéralement réunion journalière où on se tient debout) ? La solution est de se reposer sur les technologies de communication et les outils de travail collaboratif à distance. La plupart des réunions peuvent être réalisées en utilisant des outils de visioconférence. En fait un simple micro-casque et un logiciel comme Skype permettent déjà de franchir beaucoup d’obstacles liés à la distance. De plus on peut utiliser des outils tels que IceScrum ou AgileFant qui permettent de gérer des projets Agile via une plateforme Internet. Chaque membre de l’équipe est invité à se connecter quotidiennement sur la plateforme afin de communiquer sur sa progression et d’estimer le temps nécessaire pour les tâches qui lui sont allouées. Bien sûr les personnes n’ont aucun visu, ce qui constitue un frein à l’interaction et donc à la coordination. Les meetings sont aussi souvent plus longs car il faut nécessairement être beaucoup plus descriptif. Deux problèmes majeurs surviennent souvent : la médiocre qualité des communications et la barrière de la langue. En Inde, par exemple, se pose le problème de la qualité des connexions Internet (et aussi électriques) qui viennent interrompre fréquemment les communications. En chine, le problème de la langue se pose. Les développeurs chinois parlent peu ou mal l’anglais. Souvent, les communications orales ne sont pas possibles et il est nécessaire de les remplacer par l’écrit, qui est beaucoup moins efficace. Enfin, le plus gros problème auquel on fait face en outsourcing est l’incompréhension due à des différences culturelles (le fameux « oui » respectueux Indien qui n’a pas la valeur du oui occidental). Source : http://blog.vincentbrouillet.com/post/2010/06/06/Comparaison-gestion-de-projet-Agile-VS-traditionnel-pour-SAAS%3A-%28Partie-3/3%29
- Valeurs scrum : Confiance Courage Transparence Humilité Congruence En psychothérapie, congruence est le terme employé par Carl Rogers pour indiquer une correspondance exacte entre l'expérience et la prise de conscience Avantages Scrum se différencie des autres méthodes de développement par ses avantages qui font de ce procédé une réponse pragmatique aux contraintes actuelles des chefs de produits : Méthode itérative et incrémentielle : cela permet d'éviter "l'effet tunnel", c'est-à-dire le fait de ne voir le résultat qu'à la livraison finale et rien ou presque rien pendant toute la phase de développement, si fréquent dans les développements avec le cycle en V. Adaptabilité maximale pour du développement de produits et d'applications : la composition séquentielle du contenu des sprints permet d'ajouter une modification ou une fonctionnalité qui n'était pas prévue au départ. C'est principalement cela qui rend cette méthode "agile". Méthode participative : chaque membre de l'équipe est invité à s'exprimer et il peut participer à toutes les décisions prises sur le projet. Il est donc plus impliqué et plus motivé. Augmentation de la communication : en travaillant dans la même salle de développement, ou en étant connecté avec différents moyens de communication, l'équipe peut communiquer facilement et échanger sur les obstacles afin de les supprimer au plus tôt. Maximisation de la coopération : les échanges quotidiens entre le client et l'équipe permettent un rapprochement et une entraide se met logiquement en place. Augmentation de la productivité : en supprimant certaines "contraintes" des méthodes classiques comme la documentation ou la formalisation exagérée, SCRUM permet d'augmenter la productivité de l'équipe. En ajoutant à cela la qualification de chaque module permettant d'en déterminer un chiffrage, chacun peut se positionner par rapport à la productivité moyenne de l'équipe. Risques et solutions La méthodologie SCRUM n'est pas une réponse miracle à tous les problèmes inhérents au développement de logiciels informatiques. Il faut rester vigilant sur les risques ci-dessous, risques qui possèdent néanmoins, une réponse systématique puisée dans l'extrapolation de la méthode : Taille de l'équipe : généralement limitée à 7 ou 10 personnes, la taille de l'équipe peut devenir un obstacle si elle dépasse ces préconisations. L'organisation des réunions devient alors impossible et les fondements mêmes de la méthode sont alors mises à mal. La solution consiste à réaliser des Scrum de Scrum. Il s'agit ici de constituer de scinder le projet en équipes de taille recommandée et d'ajouter une instance de niveau supérieure regroupant les ScrumMaster de chaque Scrum. Qualité des développements : Plus le nombre d'équipes augmente, plus la qualité est difficile à maîtriser. Ce postulat est d'autant plus vrai dès lors que le projet est réparti sur plusieurs sites. Les risques sont particulièrement liés à la qualité du code et au nombre de défauts répertoriés au moment de l'intégration. Pour cela, il est important d'avoir une politique qualité rigoureuse et un plan qualité projet qui définit précisément les règles du projet. Des audits de code fréquents et la mise en place d'indicateurs mesurant la performance des développeurs permettent de minimiser ce risque. Concludion: http://www.aubryconseil.com/post/Les-valeurs-de-l-agilite http://www.pentalog.fr/offre/methodologie_agile_scrum.htm
- 1 - plus de réunion de sprint mais mêlées quotidienne importantes 2 - 3 – Si un problème persiste ou si plusieurs elements sont en attente de traitement pour la prochaine étape du workFlow : cela permet de mobiliser ses troupe pour les terminer et passer à autre chose (minimiser les pertes (de temps, d’argents tout en étant capable de livrer des éléments en production) et maximiser le rendement)
- Sur 15 jours la capacité de l’équipe est de 15 éléments soit en moyenne 1 élément par jour (Courbe violette de prod). Le 4ème jour les 9 premiers items ont mis 6 jours pour passer du backlog à la prod dont 50% du temps en phase de test/deploiement… On pourrait limiter le TAF en phase de test/deploiement pour fluidifier (lisser) le flux et concentrer les efforts dans cette phase pour dépiler plus rapidement les items et les passer en prod.
- Estimations peuvent être XS, S, M, XL, XXL … Pourquoi une limite de 4 dans la colonne DEV ? Supposons qu’il y ai 3 éléments dans la colonne DONE (et donc 1 élément dans la colonne Work In Progress), il y à donc une capacité excédentaire (des développeurs qui pourraient commencer de nouveaux éléments), mais qui ne peuvent pas à cause de la limite KANBAN. Cela les incitent donc fortement à aider à livrer des choses en production en vidant les colonnes DONE et TEST/DEPLOIEMENT et à maximiser le flux (effet positif et progressif). Limite KANBAN trop faible => les gens sont inoccupés => mauvaise productivité Limite KANBAN trop elevé => taches non traitées => mauvais temps de cycle Principe du flux continue limité : Un exemple de mesures de sous-optimisation est le fait de s'assurer dans certaines entreprises que tout le monde est occupé tout le temps ; et généralement cela se fait en demandant aux gens de travailler sur plusieurs choses en même temps. Pourtant, cette stratégie entraîne un énorme gaspillage car un taux d'utilisation élevé crée l'équivalent des embouteillages et ralentit tout au fur et à mesure que le temps dépensé pour passer d'une tâche à une autre augmente.