Formation scrum v1.0

3 133 vues

Publié le

Formation Scrum

Publié dans : Technologie

Formation scrum v1.0

  1. 1. Formation Scrum Mahfoud Amiour Directeur de projet Expert Agile Scrum 06 63 53 43 74 mamiour@softenia-solutions.com www.softenia-solutions.com Directeur de projets Freelance 18 ans d’expériences en génie logiciel Mahfoud AMIOUR 8 ans d’expériences en gestion de projet Agile/Scrum 06 63 53 43 74mamiour@softenia-solutions.com Certifié Scrum Master : CSM www.softenia-solutions.com Certifié Product 0wner : CSPO
  2. 2. Plan de la présentation Introduction à l’agilité Généralités Scrum Le framework Scrum Les règles L’équipe Scrum Les artefacts Les événements Gestion de projet avec Scrum Estimer avec Scrum Planifier avec Scrum Pratiques d’ingénierie pour Scrum Introduction à l’agilitéIntroduction à l’agilité Approche classique Modèle en cascade Principales limitations Approche Agile Motivations Un peu d’histoire Exemples de méthodes Les valeurs Les principes Les caractéristiques © 2012 SOFTENIA Solutions 4
  3. 3. Introduction à l’agilitéL’approche classique • L’approche classique Modèle en cascade 6-12 mois Recueil Analyse Tests des & Codage & Besoins Conception Validation Produit final © 2012 SOFTENIA Solutions 5 Introduction à l’agilitéLimitations du modèle en cascade • L’approche classique • Limitations Modèle devenant inadapté Difficulté de réagir aux changements Les besoins doivent être connus à l’avance Validation trop tardive Effet tunnel o Le client doit attendre la fin du projet pour avoir une valeur métier tangible o Feedback tardif © 2012 SOFTENIA Solutions 6
  4. 4. Introduction à l’agilitéLimitations du modèle en cascade • L’approche classique Limitations Taux d’échec des projets très élevé* Seuls 16% réussissent 53% sont problématiques o Hors délais o Hors budgets o Ne répondent pas aux besoins 31% sont abandonnés *Source : Standish group (Chaos report) © 2012 SOFTENIA Solutions 7 Introduction à l’agilitéLimitations du modèle en cascade • L’approche classique • Limitations Des produits qui ne répondent pas aux besoins* 45% des fonctionnalités jamais utilisées 20% rarement utilisées 20% réellement utilisées Les raisons? Les besoins évoluent A vouloir fixer tout le périmètre dès le départ, on y inclut des choses inutiles Source : Standish group (Chaos report) © 2012 SOFTENIA Solutions 8
  5. 5. Introduction à l’agilitéL’approche Agile : Motivations • L’approche Agile • Motivations Répondre aux limitations du modèle en cascade Proposer un model mieux adapté Objectifs Respecter les délais Réduire le « time to market » Réduire les risques Améliorer la qualité Permettre d’intégrer le changement Faire plus avec le même budget Motiver les équipes de développement © 2012 SOFTENIA Solutions 9 Introduction à l’agilitéAméliorations constatés avec les méthodes • L’approche AgileAgile • Motivations Quelques chiffres* Amélioration constatée % de réponses Satisfaction de l’utilisateur 56% Amélioration de la productivité 41% Respect des délais 40% Respect du budget 16% Amélioration de la qualité 75% Satisfaction des équipes de développement 36% *Source : Enquête réalisée par le SUG 2009 © 2012 SOFTENIA Solutions 10
  6. 6. Introduction à l’agilitéUn peu d’histoire • L’approche Agile • Historique A partir de A partir de 1986 1991 1994 1995 2001 Aptitude au • Itération • Spécialisation • Pratiques Standardisation Changement • Incrément des rôles d’ingénierie • Valeurs Auto organisation • Adaptation • Prescription • Estimation • Principes Imbrication des des réunions consensuelle Phases • Processus • Reporting visuel légers Scrum, FDD, XP, The new new game RAD RAD2, BDDSM Manifeste Agile ASD © 2012 SOFTENIA Solutions 11 Introduction à l’agilitéExemples de méthodes • L’approche Agile • Exemple de méthodes Scrum eXtreme Programming Lean Kanban Rapid Application Development Dynamic Systems Development Method Feature Driven Development Adaptative Software Development Crystal Clear © 2012 SOFTENIA Solutions 12
  7. 7. Introduction à l’agilité4 valeurs Agile* • L’approche Agile • Les valeurs 1 Les individus et leurs interactions plus que les processus et les outils 4 L’adaptation au changement 2 Des logiciels opérationnels 4 valeurs 4 plus que le suivi d’un plan plus quune documentation exhaustive 3 Collaboration avec le client plus que la négociation dun contrat * Source : Manifeste Agile © 2012 SOFTENIA Solutions 13 Introduction à l’agilité12 principes Agile* • L’approche Agile • Les principes 1. Satisfaire le client 2. Accepter le changement 3. Livrer fréquemment 4. Travailler avec l’utilisateur 5. Personnes motivées 6. Dialogue en face à face 7. Le logiciel est la mesure d’avancement 8. Rythme constant 9. Excellence technique 10. La simplicité 11. Equipe auto organisée 12. Inspection régulière * Sources : Manifeste Agile © 2012 SOFTENIA Solutions 14
  8. 8. Introduction à l’agilitéCaractéristiques de l’approche Agile • Caractéristiques Un modèle de gestion de projet Itératif Incrémental Empirique Orienté valeur métier Estimation & Planification multi-niveaux © 2012 SOFTENIA Solutions 15 Introduction à l’agilitéUn processus itératif • Caractéristiques Itération Itération Itération …… Itération Produit final Produit partiel exploitable Planification Analyse Déploiement Conception Tests & QA Codage © 2012 SOFTENIA Solutions 16
  9. 9. Introduction à l’agilitéUn processus Incrémental • Caractéristiques Itération Itération Itération …. Itération Produit final Produit partiel exploitable © 2012 SOFTENIA Solutions 17 Introduction à l’agilitéUn Processus Empirique • Caractéristiques Théorie de l’empirisme La connaissance vient de l’expérience Prise de décision basée sur des éléments connus Trois piliers Transparence Inspection Adaptation S’adapter et progresser tout au long du projet : PDCA Plan DO Check Adapt © 2012 SOFTENIA Solutions 18
  10. 10. Introduction à l’agilitéUn Processus Empirique • Caractéristiques PDCA : Processus d’amélioration continue Adapt Plan Check Do Adapt Plan Check Do Pente de progrès © 2012 SOFTENIA Solutions 19 Introduction à l’agilitéUne planification multi-niveau • Caractéristiques La planification est un processus continu Plusieurs niveaux de planification Vision du produit Roadmap Release Itération Quotidien © 2012 SOFTENIA Solutions 20
  11. 11. Plan de la présentation Introduction à l’agilité Origines Généralités Scrum Caractéristiques Le framework Scrum Cycle de vie du projet Scrum Les règles L’équipe Scrum Les artefacts Les événements Gestion de projet avec Scrum Estimer avec Scrum Planifier avec Scrum Pratiques d’ingénierie pour Scrum Généralités ScrumOrigines de Scrum • Origines 1986 Nouvelle méthode : « The New New game » Début des années 90 Emploi du terme Scrum Introduction de la méthode dans plusieurs entreprises 1995 Formalisation de la méthode : Schwaber et Sutherland © 2012 SOFTENIA Solutions 22
  12. 12. Scrum : GénéralitésScrum : Caractéristiques • Caractéristiques Framework de gestion de projet Agile Itératif Incrémental Empirique Centré valeur métier Planification multi-niveaux Scrum : GénéralitésUn Framework de gestion de projet Agile • Caractéristiques Composants du Framework Règles Equipe Framework Scrum Artefacts Scrum Evénements
  13. 13. Scrum : GénéralitésProcessus Itératif • Caractéristiques Itération = Sprint Le projet avance par une série de Sprints successifs La durée du Sprint est fixe 2 à 4 semaines Scrum : GénéralitésProcessus Incrémental • Caractéristiques Chaque Sprint produit un logiciel partiel « Fini » potentiellement exploitable : Incrément Testé Validé Livrable en production
  14. 14. Scrum : GénéralitésProcessus Empirique • Caractéristiques PDCA à plusieurs niveaux Planification du Sprint Mêlée quotidienne Revue du Sprint Rétrospective du Sprint Transparence Artefacts de gestion visibles Radiateur d’information Scrum : GénéralitésOrienté valeur métier Caractéristiques On fixe Délai Coûts On vise à maximiser Périmètre
  15. 15. Scrum : GénéralitésCinq niveaux de planification • Caractéristiques Vision Roadmap Release Sprint Quotidien Release1 Backlog de Sprint1 fonctionnalités Jour J Jour J Sprint2 Release2 J J J J J J J … 1 2 3 4 5 6 7 Sprint3 Release3 Sprint4 © 2012 SOFTENIA Solutions 29 Scrum : GénéralitésCycle de vie du projet Scrum • Cycle de vie du projet Scrum • Backlog initial Phase de • Montage de l’équipe Préparation • Estimations • Architecture, etc. Planification de • Plan de la release • Nombre de Sprints la release • Périmètre fonctionnel • Dates des Sprints Déroulement des Sprints Sprint … Sprint Produit final © 2012 SOFTENIA Solutions 30
  16. 16. Scrum : GénéralitésDéroulement du Sprint • Cycle de vie du projet Scrum Planification du Sprint Déroulement des Sprints Mêlées Sprint quotidiennes Travailler sur … Le Sprint suivant Sprint Sprint Revue du Sprint Rétrospective du Sprint © 2012 SOFTENIA Solutions 31 Plan de la présentation Introduction à l’agilité Généralités Scrum Le framework Scrum Les règles L’équipe Scrum Les artefacts Les événements Gestion de projet avec Scrum Estimer avec Scrum Planifier avec Scrum Pratiques d’ingénierie pour Scrum
  17. 17. Les règlesLes règles Pratiques et procédures à suivre Issues des expériences sur des milliers de projets Quelle est l’utilité? Fixer les règles du jeu dans le projet Lier les événements, les rôles et les artefacts Introduites tout au long de la présentation © 2012 SOFTENIA Solutions 33 Les règlesExemples de règles Chaque réunion Scrum a une durée maximale La taille du Sprint est fixe Le périmètre du Sprint ne doit pas changer en cours de route © 2012 SOFTENIA Solutions 34
  18. 18. Les règlesConseil Les règles doivent être appliquées dans leur globalité Ne pas les changer avant d’être sûr de leur bonne application Se servir des réunions de rétrospective pour discuter/adapter les règles © 2012 SOFTENIA Solutions 35 Plan de la présentation Introduction à l’agilité Généralités Scrum Le framework Scrum Les règles Les rôles L’équipe Scrum Constitution de l’équipe Scrum Les artefacts Les événements Gestion de projet avec Scrum Estimer avec Scrum Planifier avec Scrum Pratiques d’ingénierie pour Scrum
  19. 19. L’équipe ScrumL’équipe Scrum : Plan Les rôles Vue d’ensemble Product Owner ScrumMaster Equipe de développement Parties prenantes Constitution de l’équipe Scrum Les membres de l’équipe Les valeurs de l’équipe Facteurs de réussite Multidisciplinarité Atelier : Team Building © 2012 SOFTENIA Solutions 37 L’équipe ScrumLes rôles Scrum • Les rôles Formalisent les responsabilités dans le processus Scrum Ce ne sont pas des positions dans lentreprise Permettent à chacun de bien connaître ses responsabilités dans le projet © 2012 SOFTENIA Solutions 38
  20. 20. L’équipe ScrumLes rôles : vue d’ensemble • Les rôles • Vue d’ensemble Product Owner ScrumMaster Equipe de Les Rôles SM développement Parties prenantes* © 2012 SOFTENIA Solutions 39 L’équipe ScrumProduct Owner : caractéristiques • Les rôles • Le Product Owner Responsable du produit Représente le client et les utilisateurs Une personne, pas un comité Disponible pour léquipe Le seul habilité à gérer et prioriser les besoins © 2012 SOFTENIA Solutions 40
  21. 21. L’équipe ScrumProduct Owner : responsabilités • Les rôles • Le Product Owner Gestion du Backlog du produit Gestion de la release Interactions avec le client Validation des résultats Collaboration avec l’équipe © 2012 SOFTENIA Solutions 41 L’équipe ScrumLe ScrumMaster : caractéristiques • Les rôles • Le ScrumMaster Responsable du processus Scrum envers le Product Owner l’équipe de développement L’organisation Leader au service de léquipe Ne possède pas dautorité hiérarchique Interface avec le management © 2012 SOFTENIA Solutions 42
  22. 22. Le Framework ScrumLe ScrumMaster : responsabilités • Les rôles • ScrumMaster Envers l’équipe de développement Coacher l’équipe Aider à l’élimination des obstacles Faciliter la tenue des réunions Scrum Guider l’équipe à créer des produits de qualité © 2012 SOFTENIA Solutions 43 Le Framework ScrumLe ScrumMaster : responsabilités • Les rôles • Le ScrumMaster Envers le PO Trouver les techniques pour gérer le backlog du produit Faciliter la tenue des événements Communiquer/rappeler la vision à l’équipe de développement © 2012 SOFTENIA Solutions 44
  23. 23. L’équipe ScrumLe ScrumMaster : responsabilités • Les rôles • Le ScrumMaster Envers l’organisation Guider l’organisation dans l’adoption de Scrum Planifier l’implémentation de Scrum Aider les employés à comprendre Scrum Agir comme un agent de changement © 2012 SOFTENIA Solutions 45 L’équipe ScrumL’équipe de développement : Caractéristiques • Les rôles • L’équipe de développement Auto-organisée et autonome Multidisciplinaire Toutes les compétences nécessaires sont présentes o Développeurs, Testeurs, Analystes, Architectes, DBA ... Responsable collectivement Taille 5-9 membres (développeurs Scrum) © 2012 SOFTENIA Solutions 46
  24. 24. L’équipe ScrumL’équipe de développement : responsabilités • Les rôles • Equipe de développement Réaliser les tâches Tenir la mêlée quotidienne Participer aux événements Scrum Définir les pratiques dingénierie Livrer des produits de qualité Estimer les éléments du Backlog Définir et gérer le planning du Sprint Identifier les tâches Estimer les tâches Tenir le planning à jour © 2012 SOFTENIA Solutions 47 L’équipe ScrumLes parties prenantes • Les rôles • Parties prenantes Rôle non officiel dans Scrum Mais indispensable Exemples Le client Les utilisateurs directs et indirects Le management Les personnes impactés par le déploiement et l’exploitation … © 2012 SOFTENIA Solutions 48
  25. 25. L’équipe ScrumL’équipe Scrum : Plan Les rôles Vue d’ensemble Product Owner ScrumMaster Equipe de développement Parties prenantes Constitution de l’équipe Scrum Les membres de l’équipe Les valeurs de l’équipe Facteurs de réussite Multidisciplinarité Atelier : Team Building © 2012 SOFTENIA Solutions 49 L’équipe ScrumConstitution de l’équipe Scrum • Constitution de l’équipe Parties prenantes ScrumMaster Product Owner SM Equipe de développement © 2012 SOFTENIA Solutions 50
  26. 26. L’équipe ScrumLes membres de l’équipe Scrum • Constitution de l’équipe Product Owner ScrumMaster Personne différente du PO Equipe de développement Profils polyvalents Chaque membre a un domaine d’excellence + des compétences partielles Profils en T © 2012 SOFTENIA Solutions 51 L’équipe ScrumLes valeurs de l’équipe • Constitution de l’équipe Partagent les mêmes valeurs Engagement Courage Respect Transparence Jouer collectif © 2012 SOFTENIA Solutions 52
  27. 27. L’équipe ScrumLes valeurs de l’équipe : L’engagement • Constitution de l’équipe Poules du projet Cochons du projet o Parties prenantes o Product Owner o ScrumMaster o Equipe de développement © 2012 SOFTENIA Solutions 53 L’équipe ScrumFacteurs de réussite • Constitution de l’équipe Doter le Product Owner d’un réel pouvoir Priorisation des exigences Prise de décision Un ScrumMaster Au service de l’équipe Non un chef Equipe de développement Autogérée Multidisciplinaire © 2012 SOFTENIA Solutions 54
  28. 28. L’équipe ScrumFacteurs de réussite • Constitution de l’équipe Equipe de développement autogérée L’équipe gère elle-même sa façon de travailler Personne ne peut dicter à l’équipe comment procéder Equipe de développement Multidisciplinaire Toutes les compétences sont présentes de façon équilibrée o Conception, codage, test, documentation, etc. Les membres sont polyvalents : Profiles en T © 2012 SOFTENIA Solutions 55 L’équipe ScrumFacteurs de réussite : Les enjeux • Constitution de l’équipe Comment transformer un groupe d’individus en une équipe cohérente est soudée? Comment bâtir une équipe polyvalente? Comment améliorer l’efficacité de l’équipe? La gestion de l’équipe doit être au centre de la transformation Agile © 2012 SOFTENIA Solutions 56
  29. 29. L’équipe ScrumMultidisciplinarité : Profiles en T • Constitution de l’équipe Les membres de l’équipe de développement o Peuvent être experts dans certaines domaines o Possèdent des compétences secondaires qui leur permettent de réaliser des tâches hors leur domaine d’excellence Exemples Profil B Profil A JAVA BDD T Conception E Test BDD Conception Architecture J S A T V S A © 2012 SOFTENIA Solutions 57 L’équipe ScrumMultidisciplinarité : Equilibre des compétences • Constitution de l’équipe Que pensez vous de cette équipe Architecture Développement BDD Tests Intégration & .NET fonctionnels conception Marie Connait Connait Connait Pierre Connait Connait Connait Marc Connait Connait Connait Connait Rémi Connait Connait Connait Céline Luc Connait Connait Equipe de généralistes © 2012 SOFTENIA Solutions 58
  30. 30. L’équipe ScrumMultidisciplinarité : Equilibre des compétences • Constitution de l’équipe Que pensez vous de cette équipe Architecture Développement BDD Tests Intégration & .NET fonctionnels conception Marie Expert Pierre Expert Expert Marc Expert Rémi Expert Expert Céline Expert Luc Expert Equipe d’experts © 2012 SOFTENIA Solutions 59 L’équipe ScrumMultidisciplinarité : Equilibre des compétence • Constitution de l’équipe Que pensez vous de cette équipe Architecture Développement BDD Tests Intégration & .NET fonctionnels conception Marie Expert Connait Connait Pierre Expert Expert Connait Marc Connait Expert Connait Connait Rémi Expert Connait Connait Expert Céline Expert Luc Expert Connait Equipe multidisciplinaire © 2012 SOFTENIA Solutions 60
  31. 31. Les rôlesAtelier : Team building • Constitution de l’équipe Scrum Objectif : Former une équipe polyvalente Time box : 1 heure © 2012 SOFTENIA Solutions 61 Plan de la présentation Introduction à l’agilité Généralités Scrum Le framework Scrum Les règles Vue d’ensemble L’équipe Scrum Artefacts transverses Les artefacts Artefacts liés à la Release Les événements Artefacts liés au Sprint Artefacts du management visuel Gestion de projet avec Scrum Estimer avec Scrum Planifier avec Scrum Pratiques d’ingénierie pour Scrum
  32. 32. Les Artefact ScrumLes artefacts : vue d’ensemble Artefacts transverses Définition de Fini : DoD (Definition of Done) Artefacts relatifs à la release Backlog de produit Elément de Backlog de produit : PBI Burndown du produit Plan de la release Artefacts relatifs au Sprint Lincrément Objectif de Sprint Backlog de Sprint Tâche Burndown du Sprint Backlog dobstacles Backlog damélioration Artefacts du management visuel Radiateur dinformation © 2012 SOFTENIA Solutions 63 Les Artefact ScrumLes artefacts relatifs à la release Artefacts transverses Définition de Fini : DoD (Definition of Done) Artefacts relatifs à la release Backlog de produit Elément de Backlog de produit : PBI Burndown du produit Plan de la release Artefacts relatifs au Sprint Lincrément Objectif de Sprint Backlog de Sprint Tâche Burndown du Sprint Backlog dobstacles Backlog damélioration Artefacts du management visuel Radiateur dinformation © 2012 SOFTENIA Solutions 64
  33. 33. Les Artefacts ScrumDéfinition de « Fini » : DoD • Définition de « Fini » : DoD Partager la même signification de « Fini » DoD = Definition of Done Exprime les critères de fin dun travail Pourquoi? Eviter le syndrome de 90% fini Fini = 100% Fini © 2012 SOFTENIA Solutions 65 Les ArtefactsQuels artefacts concernés par le DoD? • Définition de Fini : DoD Artefact Exemple de DoD Elément du Backlog de Tests d’acceptation sur environnement d’intégration produit Codage terminé Tâches Tests unitaires automatisés Tests unitaires 100% réussis Tests de non régression sur environnement de recette Incrément Release Notes élaborée Release Déploiement Pré-Prod Tests en Pré-Prod © 2012 SOFTENIA Solutions 66
  34. 34. Les Artefact ScrumLes artefacts relatifs à la release Artefacts transverses Définition de Fini : DoD (Definition of Done) Artefacts relatifs à la release Backlog de produit Elément de Backlog de produit : PBI Burndown du produit Plan de la release Artefacts relatifs au Sprint Lincrément Objectif de Sprint Backlog de Sprint Tâche Burndown du Sprint Backlog dobstacles Backlog damélioration Artefacts du management visuel Radiateur dinformation © 2012 SOFTENIA Solutions 67 Artefacts ScrumBacklog de produit • Backlog de Produit Liste déléments représentant les exigences Fonctionnalités Améliorations Correctifs Besoins non fonctionnels : performance, sécurité, etc. Seul endroit pour stocker les exigences © 2012 SOFTENIA Solutions 68
  35. 35. ArtefactsCaractéristiques • Backlog de Produit Détaillé pertinemment Détails apportés au bon moment : JIT Emergeant Evolue tout au long du projet Estimé Quelle est la taille des éléments Priorisé Dans quel ordre réaliser les éléments DEEP © 2012 SOFTENIA Solutions 69 ArtefactsNiveaux de granularité • Backlog du Produit (User) Stories Epics Thèmes © 2012 SOFTENIA Solutions 70
  36. 36. ArtefactsExemple de Backlog de produit • Backlog du Produit © 2012 SOFTENIA Solutions 71 ArtefactsEléments de Backlog de Produit : PBI • Eléments de Backlog de Produit : PBI PBI : Product Backlog Item Exigence du système Fonctionnel Non fonctionnel Performance Portabilité Sécurité Réutilisabilité, etc. Base de l’estimation et de la planification Agile
  37. 37. ArtefactsExemples de PBI • Eléments de Backlog de Produit : PBI Exemple de PBI Catégorie En tant que candidat Fonctionnel Je veux faire des recherches de postes …. En tant que candidat, Fonctionnel Je veux visualiser les détails des postes … En tant que recruteur, Fonctionnel Je veux poster des offres … Mettre à jour la version du SGBD Technique Corriger le bug Mantis 200 Correctif ArtefactsCaractéristiques des PBI • Eléments de Backlog de Produit : PBI • Caractéristiques Les PBIs doivent être INVEST Independant Negociable Testable INVEST Valuable Small Estimable © 2012 SOFTENIA Solutions 74
  38. 38. ArtefactsStructure des PBI • Eléments de Backlog de Produit : PBI Priorité Description Valeur métier PBI Taille Etat DoD Tests d’acceptation ArtefactsPriorité des PBI • Eléments de Backlog de Produit : PBI L’ordre de réalisation des PBI Critères de priorisation Valeur métier Retour sur investissement Degré de risque … Responsabilité du PO © 2012 SOFTENIA Solutions 76
  39. 39. ArtefactsDescription des PBI • Eléments de Backlog de Produit : PBI Enoncé court de l’objet du PBI : Point d’entrée « Starter » pour la conversation entre le PO et l’équipe de développement Détails apportés par les tests d’acceptation Responsabilité du PO © 2012 SOFTENIA Solutions 77 ArtefactsDescription des PBI • Eléments de Backlog de Produit : PBI Format de description Qui : le rôle bénéficiaire Quoi : L’objet Pourquoi : La valeur ajoutée Modèle des User Stories En tant que <Rôle> Je veux <Quoi> Pour <Pourquoi>
  40. 40. Artefacts ScrumDescription des PBI • Eléments de Backlog de Produit : PBI Point de départ pour la conversation autour du besoi Méthodes des 3C : Ron Jeffries Card Conversation (Description) Confirmation (Détails) ArtefactsTests d’acceptation des PBI • Eléments de Backlog de Produit : PBI Le projet est piloté par les tests d’acceptation Tests fonctionnels Conditions dacceptation Constituent la spécification du PBI • Elaborés par le PO • Exécutés par léquipe de développement • Vérifiés par le PO © 2012 SOFTENIA Solutions 80
  41. 41. ArtefactsValeur des PBI • Eléments de Backlog de Produit : PBI Chiffre représentant la valeur métier Gain en productivité Augmentation des ventes Augmentation du chiffre d’affaire, … Responsabilité du PO © 2012 SOFTENIA Solutions 81 ArtefactsTaille des PBI • Eléments de Backlog de Produit : PBI Valeur relative Reflet de plusieurs paramètres Complexité, incertitude, difficulté technique, etc. Quantité de points Base de la planification Estimation de la taille : responsabilité de l’équipe de développement © 2012 SOFTENIA Solutions 82
  42. 42. ArtefactsDoD des PBI • Eléments de Backlog de Produit : PBI Tests d’acceptation Autres conditions • Elaboré par le PO • Exécutés par léquipe de développement © 2012 SOFTENIA Solutions 83 ArtefactsEtat des PBI • Eléments de Backlog de Produit : PBI Cycle de vie possible Responsabilité : l’équipe de développement, le PO © 2012 SOFTENIA Solutions 84
  43. 43. Les Artefact ScrumLes artefacts relatifs à la release Artefacts transverses Définition de Fini : DoD (Definition of Done) Artefacts relatifs à la release Backlog de produit Elément de Backlog de produit : PBI Burndown du produit Plan de la release Artefacts relatifs au Sprint Lincrément Objectif de Sprint Backlog de Sprint Tâche Burndown du Sprint Backlog dobstacles Backlog damélioration Artefacts du management visuel Radiateur dinformation © 2012 SOFTENIA Solutions 85 ArtefactsLincrément • L’incrément Résultat du Sprint Logiciel partiel potentiellement exploitable Testé Vérifie le DoD Possibilité de déploiement en production © 2012 SOFTENIA Solutions 86
  44. 44. Artefacts ScrumObjectif du Sprint • Objectif du Sprint Phrase indiquant le but principal du Sprint Point de vue fonctionnel Exemples Sprint Objectif du Sprint Sprint 1 Mettre en place la recherche multicritères Sprint 2 Internationaliser lapplication Responsabilité du PO © 2012 SOFTENIA Solutions 87 ArtefactsBacklog de Sprint • Backlog de Sprint Planning à l’échelle du Sprint Contient Les PBI sélectionnés pour le Sprint Les Tâches de réalisation o Conception, Codage, Tests, Documentation, etc. Artefact interne à l’équipe de développement Etabli lors de la réunion de planification du Sprint Mis à jour quotidiennement Responsabilité de l’équipe de développement © 2012 SOFTENIA Solutions 88
  45. 45. ArtefactsBacklog de Sprint : Exemple • Backlog de Sprint © 2012 SOFTENIA Solutions 89 Artefacts ScrumLes tâches • Les tâches Représentent le travail à faire Conception, Analyse, codage, tests, documentation, déploiement, etc. Identification des tâches Par décomposition des PBI lors de la planification du Sprint Peuvent émerger durant le Sprint © 2012 SOFTENIA Solutions 90
  46. 46. ArtefactsStructure des tâches • Les tâches • Structure Description Réalisateur Reste à faire Durée initiale quotidien Tâche DoD Etat d’avancement © 2012 SOFTENIA Solutions 91 ArtefactsRéalisateur de la tâche • Les tâches • Structure Les tâches sont prises par les développeurs Ne sont pas assignées par le ScrumMaster : Equipe autogérée Responsabilité collective © 2012 SOFTENIA Solutions 92
  47. 47. ArtefactsDurée initiale des tâches • Les tâches • Structure Estimation initiale de la durée En heures Granularité recommandée 16h maximum Estimation collective par l’équipe de développement © 2012 SOFTENIA Solutions 93 ArtefactsEtat d’avancement des tâches • Les tâches • Structure Etats types A faire, En cours, Fini Responsabilité : équipe de développement © 2012 SOFTENIA Solutions 94
  48. 48. ArtefactsReste à faire quotidien • Les tâches • Structure Estimation du temps restant pour finir la tâche En heures Mis à jour quotidiennement Responsabilité du réalisateur © 2012 SOFTENIA Solutions 95 ArtefactsVélocité • Vélocité de l’équipe Nombre de points réalisés par l’équipe de développement à la fin du Sprint Vélocité réelle Utilité Estimer la durée du projet Estimer le nombre de points que l’équipe est capable de réaliser avant de planifier un Sprint Indice de performance de l’équipe © 2012 SOFTENIA Solutions 96
  49. 49. ArtefactsComment calculer la vélocité réelle? • Vélocité de l’équipe A la fin du Sprint Faire la somme des points des PBI « Fini » dans le Sprint Les PBI dont l’état n’est pas « Fini » ne rentrent pas dans le calcul de la vélocité Exemple PBI Taille Etat PBI1 3 Fini Vélocité = 11 PBI2 8 Fini PBI3 5 En cours © 2012 SOFTENIA Solutions 97 ArtefactsBurndown de Produit • Burndown de Produit Reste à faire pour finir la release Mis à jour à chaque fin de Sprint Permet dajuster les prévisions de livraison Responsabilité du Product Owner © 2012 SOFTENIA Solutions 98
  50. 50. ArtefactsExemple de Burndown de produit • Burndown de ProduitTaille initiale duBacklog du produitTaille restante à la finde chaque Sprint © 2012 SOFTENIA Solutions 99 ArtefactsBurndown de Sprint • Burndown de Sprint Reste à faire à chaque jour du Sprint Reste à faire Avant le Jour 1 Reste à faire Après le jour 1 Responsabilité de l’équipe de développement © 2012 SOFTENIA Solutions 100
  51. 51. ArtefactsBacklog dobstacles • Backlog d’obstacle Liste dobstacles identifiés par léquipe Scrum Géré par le ScrumMaster © 2012 SOFTENIA Solutions 101 ArtefactsBacklog damélioration • Backlog d’amélioration Liste des améliorations identifiées par léquipe Géré par le ScrumMaster © 2012 SOFTENIA Solutions 102
  52. 52. Les Artefact ScrumLes artefacts relatifs à la release Artefacts transverses Définition de Fini : DoD (Definition of Done) Artefacts relatifs à la release Backlog de produit Elément de Backlog de produit : PBI Burndown du produit Plan de la release Artefacts relatifs au Sprint Lincrément Objectif de Sprint Backlog de Sprint Tâche Burndown du Sprint Backlog dobstacles Backlog damélioration Artefacts du management visuel Radiateur dinformation © 2012 SOFTENIA Solutions 103 ArtefactsRadiateur dinformation • Radiateur d’information Mur d’affichage des artefacts du projet Utilité Rendre visible les artefacts Scrum Tableau de bord visuel du projet Permet le management visuel © 2012 SOFTENIA Solutions 104
  53. 53. ArtefactsStructure type • Radiateur d’information DoD Objectif du Sprint Backlog D’obstacles Backlog du produit Backlog du Sprint Backlog D’amélioration Burndown du produit Burndown du Sprint Vélocité © 2012 SOFTENIA Solutions 105 ArtefactsExemple • Radiateur d’information © 2012 SOFTENIA Solutions 106
  54. 54. Plan de la présentation Introduction à l’agilité Généralités Scrum Définitions Le framework Scrum Le Sprint Les règles Planification du Sprint Atelier L’équipe Scrum Mêlée quotidienne Les artefacts Atelier Les événements Revue du Sprint Gestion de projet avec Scrum Atelier Rétrospective Estimer avec Scrum Atelier Planifier avec Scrum Préparation du Backlog du Produit Pratiques d’ingénierie pour Scrum Les événementsLes Evénements Réunions, rituels, cérémonies « Time boxés »: Durée limitée Utilité Régularité dans le projet : Rythme constant Minimiser le recours aux réunions Opportunités pour appliquer la PDCA © 2012 SOFTENIA Solutions 108
  55. 55. Les événementsLes Evénements : Vue d’ensemble • Vue d’ensemble Une vue d’ensemble Sprint Réunion de planification du Sprint Mêlée quotidienne Revue du Sprint Rétrospective du Sprint Préparation du Backlog de produit © 2012 SOFTENIA Solutions 109 Les événementsLes événements : Enchainement • Enchainement Planification du Phase de Sprint Préparation Planification de Mêlées quotidiennes Travailler la release sur Le Déroulement des Sprint Sprints Sprint Revue du … Sprint Sprint Rétrospective du Sprint Sprint suivant © 2012 SOFTENIA Solutions 110
  56. 56. Les événementsLe Sprint • Le Sprint Itération dune durée fixe 2-4 semaines Facteurs déterminants dans le choix de la durée Degré d’incertitude Facilité ou non d’avoir du feedback Surcoût des itérations Stabilité des besoins © 2012 SOFTENIA Solutions 111 Les événementsDéroulement du Sprint • Le Sprint Planifier le Sprint Exécuter le travail Organiser et participer aux mêlées quotidiennes Mettre à jour les artefacts Scrum Effectuer la revue de l’incrément Faire la rétrospective du Sprint © 2012 SOFTENIA Solutions 112
  57. 57. Les événementsQuelques règles • Le Sprint La durée nest pas extensible Pendant le Sprint Léquipe ne doit pas changer Le périmètre et d’objectif ne doivent pas changer Si lobjectif devient obsolète Le PO peut abandonner le Sprint © 2012 SOFTENIA Solutions 113 Les événementsPlanification du Sprint • Réunion de Planification du Sprint Objectif : Etablir le plan du Sprint Définir l’objectif du Sprint Sélectionner les PBI prioritaires Décomposer les PBI en tâches de réalisation Vérifier la capacité de l’équipe S’engager sur le périmètre du Sprint Prendre les tâches © 2012 SOFTENIA Solutions 114
  58. 58. Les événementsDéroulement en deux parties • Planification de Sprint • Déroulement 1ère Partie 2ème Partie Entrées Entrées • Vélocité estimée • PBIs candidats au Sprint • Backlog du produit estimé et priorisé • Capacité de l’équipe Participants Participants • Equipe de développement ; PO ; SM • Equipe de développement ; PO ; SM Déroulement Déroulement •Décomposer les PBI candidats en tâches •Définir l’objectif du Sprint •Estimer les tâches •Discuter les PBI prioritaires •Prendre les tâches •Sélectionner les PBI •S’engager 4h 4h Sorties Sorties • Objectif du Sprint • Objectif du Sprint • Backlog du Sprint • PBIs candidats au Sprint © 2012 SOFTENIA Solutions 115 Les événementsCapacité de l’équipe • Planification de Sprint • Déroulement Nombre d’heures consacrées au Sprint dont dispose l’équipe de développement durant le Sprint Ne pas inclure dans le calcul de la capacité Les congés Les jours fériés Le temps des réunions, email, etc. hors projet © 2012 SOFTENIA Solutions 116
  59. 59. Les événementsCapacité de l’équipe : Exemple • Planification de Sprint • Déroulement Données du projet Durée du sprint : 10 jours ouvrés Nombre de jours fériés : 0 jour Disponibilités des membres de l’équipe de développement pendant le Sprint Capacité de l’équipe © 2012 SOFTENIA Solutions 117 Les événementsConseils • Planification de Sprint • Déroulement Pour décomposer les PBIs en tâches Commencer par établir une ébauche de la solution technique pour faire émerger les tâches o Conception participative Penser à toutes les tâches et pas uniquement aux tâches de codage o Avoir en tête la définition de « Fini » © 2012 SOFTENIA Solutions 118
  60. 60. Les événementsConseils • Planification de Sprint • Déroulement Si la durée des tâches > capacité de l’équipe Négocier avec le PO Retirer un PBI Le remplacer par un plus petit Si la durée < capacité de l’équipe Voir avec le PO pour ajouter de nouveaux PBI © 2012 SOFTENIA Solutions 119 Les événementsQuelques règles • Planification de Sprint • Déroulement Doit se tenir au début du Sprint Toute léquipe Scrum participe Time box Proportionnel à la durée du Sprint Sprint de 4 semaines : 8 heures Sprint de 2 semaines : 4 heures © 2012 SOFTENIA Solutions 120
  61. 61. EvénementsAtelier : Planification du Sprint • Planification du Sprint • Déroulement Partie 1 Objectif o Définir l’objectif du Sprint o Discuter les PBI prioritaires o Sélectionner les PBI Time box : 30 minutes Partie 2 : Elaborer le Backlog du Sprint Objectif o Identifier les tâches o Estimer les tâches o Prendre les tâches Time box : 30 minutes © 2012 SOFTENIA Solutions 121 Les événementsMêlée quotidienne • Mêlée quotidienne Objectif Synchroniser les activités de l’équipe de développement Inspecter & adapter le planning de la journée Mettre à jour le reste à faire Remonter les problèmes qui ralentissent l’équipe © 2012 SOFTENIA Solutions 122
  62. 62. Les événementsDéroulement • Mêlée quotidienne • déroulement Entrées • Backlog du Sprint Participants • Equipe de développement Déroulement Ce que j’ai fait hier Ce que je fait aujourd’hui Mes obstacles 15’ Sorties • Backlog du Sprint • Burndown du Sprint • Backlog d’obstacles 15’ © 2012 SOFTENIA Solutions 123 Les événementsQuelques règles • Mêlée quotidienne • Déroulement Réunion interne à léquipe de développement Seuls les membres de l’équipe parlent Time box 15 minutes Se fait debout Même endroit Espace projet de l’équipe Devant le radiateur d’information Même heure Matin de préférence © 2012 SOFTENIA Solutions 124
  63. 63. Les événementsQuelques précautions • Mêlée quotidienne • Déroulement Ce nest pas une réunion pour résoudre les problèmes Il ne sagit pas de rendre des comptes Ni au PO Ni au SM L’équipe de développement gère la réunion Le ScrumMaster joue le rôle de facilitateur © 2012 SOFTENIA Solutions 125 EvénementsAtelier : Mêlée quotidienne • Mêlée quotidienne • Déroulement Objectif : Pratiquer la mêlée quotidienne Time box : 15 minutes © 2012 SOFTENIA Solutions 126
  64. 64. Les événementsRevue de Sprint • Revue de Sprint Objectif Effectuer une revue de lincrément : PBI finis Recueillir le feedback Adapter le Backlog du produit si nécessaire © 2012 SOFTENIA Solutions 127 Les événementsRevue du Sprint : Déroulement • Revue de Sprint • Déroulement Entrées • Incrément • Liste des PBI Finis Participants • Equipe de développement • PO, • SM ; • Parties prenantes Déroulement • Présenter les PBIs Finis : Equipe de développement • Accepter ou refuser les PBI : PO • Recueillir le feedback • Mettre à jour le Backlog du produit • Mettre à jour le Burndown du produit • Calculer la vélocité 4h Sorties • Backlog du produit ; Burndown du produit ; Vélocité réelle © 2012 SOFTENIA Solutions 128
  65. 65. Les événementsQuelques règles • Revue de Sprint • Déroulement A organiser à la fin du Sprint Montrer uniquement les PBI Finis Informelle Pas de Slides Time box Proportionnel à la durée du Sprint 4 heures pour un Sprint de 4 semaines © 2012 SOFTENIA Solutions 129 Les événementsQuelques précautions • Revue de Sprint • Déroulement Moins dune heure de préparation Inciter les parties prenantes à donner leur feedback Les PBI non acceptés par le Product Owner doivent retourner dans le Backlog du produit © 2012 SOFTENIA Solutions 130
  66. 66. EvénementsAtelier : Revue de Sprint • Revue de Sprint Objectif Apprendre à organiser une revue de Sprint réussie Time box 30 minutes © 2012 SOFTENIA Solutions 131 Les événementsRétrospective de Sprint • Rétrospective de Sprint Objectif Inspecter le processus Améliorer le processus si nécessaire © 2012 SOFTENIA Solutions 132
  67. 67. Les événementsDéroulement • Rétrospective de Sprint • Déroulement Entrées • Sprint sortant Participants • Equipe de développement • PO • SM Déroulement • Discuter le processus Sprint • Points positifs sortant • Points négatifs • Définir un plan d’amélioration 3h Sorties Backlog d’amélioration © 2012 SOFTENIA Solutions 133 Les événementsQuelques règles • Rétrospective de Sprint • Déroulement Doit se tenir à la fin du Sprint et avant le démarrage du Sprint suivant Toute léquipe Scrum participe Time box Proportionnel à la durée du Sprint 3h pour Sprint de 4 semaines © 2012 SOFTENIA Solutions 134
  68. 68. EvénementsAtelier : Rétrospective de Sprint • Rétrospective de Sprint • Déroulement Objectif Apprendre à organiser une rétrospective réussie Time box 30 minutes © 2012 SOFTENIA Solutions 135 Les événementsPréparation du Backlog de Produit • Préparation du Backlog du Produit Objectif : préparer les PBI pour le Sprint suivant Décomposition Estimation Rendre les éléments INVEST Changement des priorité … Participants PO : Tâche de fond Equipe de développement : 5-10% du temps © 2012 SOFTENIA Solutions 136
  69. 69. Plan de la présentation Introduction à l’agilité Généralités Scrum Le framework Scrum Les règles L’équipe Scrum Les artefacts Introduction Les événements Démarche d’estimation Agile Gestion de projet avec Scrum Estimation au niveau release Estimer avec Scrum Estimation au niveau Sprint Planifier avec Scrum Pratiques d’ingénierie pour ScrumL’estimation Agile avec Scrum Estimation Agile avec Scrum Introduction à l’estimation Démarche d’estimation Agile Estimation au niveau release Estimation au niveau Sprint © 2012 SOFTENIA Solutions 138
  70. 70. Estimation AgilePourquoi estimer? • Introduction Prévoir les ressources Calculer le coût Evaluer la quantité de travail Prévoir les délais de livraison L’estimation est indispensable à la planification Estimation AgileDifficultés de l’estimation • Introduction Information incertaine et incomplète Plage d’incertitude des estimations Marge d’erreur trop importante au début du projet Il faut (re)estimer tout au long au projet
  71. 71. Estimation AgileCaractéristique de l’estimation Agile • Démarche d’estimation Agile Activité collective Faite par ceux qui réalisent le travail C’est l’équipe de développement qui estime Estimation ≠ Engagement Aide à la prise de décision Activité régulière On estime tout au long du projet Différents niveau d’estimation : Release, Sprint, au quotidien Estimation AgileLes niveaux d’estimation • Démarche d’estimation Agile ❶ Release ❷ Sprint ❸ Au quotidienQuand ? Quand ? Quand ?Phase de préparation Avant le début du Sprint Tous les joursQuoi estimer ? Quoi estimer ? Quoi estimer ?• Taille du Backlog du produit • Vélocité de l’équipe de • Reste à faire pour chaque tâche• Vélocité de l’équipe de développement développement • Durée des tâches • Taille du Backlog du produitPourquoi ? Pourquoi ? Pourquoi ?• Evaluer le périmètre • S’engager sur le contenu de • Actualiser le Burndown du Sprint fonctionnel réalisable l’incrément • Evaluer les tendances de • Actualiser & affiner les estimations l’avancement du Backlog du produit
  72. 72. Estimation AgileLa taille du Backlog de produit • Démarche d’estimation Agile • Niveau Release Taille du backlog du produit ൌ∑ tailles des PBI Taille du PBI ❶ Release Nombre entier appartenant à une échelle de valeurs relatives Quand ? o S, M, L, XL, XXL Phase de préparation o 1, 2, 3, 5, 8, 13, .. Quoi estimer ? o 0 1, 2, 3 5, 8, 30, 20, 40, 100. • Taille du Backlog du produit Reflet de plusieurs paramètres • Vélocité de l’équipe de o Complexité développement o Niveau de risque Pourquoi ? o Difficulté • Evaluer le périmètre o Incertitude, etc. fonctionnel réalisable Exprimée en points o Story points Valeur relative o Comparer les PBI les uns par rapport aux autres Estimation relative Estimation AgileL’estimation relative : Exercice • Estimation au niveau Release • Estimation relative Attribuer des points pour comparer la taille des monuments parisiens suivants Monument Taille Tour Eiffel Tour Montparnasse Arc de Triomphe Arche de la défense Notre dame Sacré Cœur Quelles sont les difficultés rencontrées?
  73. 73. Estimation AgileL’estimation relative : Techniques • Estimation au niveau Release • Estimation relative Planning Poker Séance d’estimation collective utilisant des cartes Largement utilisé dans XP et Scrum Triangulation Séance d’estimation collective basée sur la comparaisons des éléments à estimer Estimation AgileTechnique d’estimation relative : Planning • Estimation au niveau ReleasePoker • Estimation relative Estimation collective par les développeurs Les cartes représentent l’échelle de valeurs Echelle préconisée par Mike Cohn 0 1 2 3 5 8 13 20 40 100
  74. 74. Estimation AgilePlanning Poker : Déroulement • Estimation au niveau Release • Estimation relative Avant de commencer Chaque membre de l’équipe de développement reçoit un jeu de cartes Etapes Le Product Owner présente le PBI Les membres de l’équipe de développement posent des questions pour bien comprendre le PBI Chaque développeur choisit une carte représentant son estimation sans la montrer Au signal de l’animateur (ScrumMaster) les participants montrent leurs cartes au même moment En cas de divergence o On discute les estimations hautes et basses o On effectue un deuxième tour d’estimation si nécessaire Les estimations devraient converger après la discussion Répéter les étapes pour chaque PBI Estimation AgilePlanning Poker : Exemple • Estimation au niveau Release • Estimation relative Estimer la taille des PBI suivants PBI Taille estimée Un utilisateur peut chercher des livres par auteur, par titre ou par numéro ISBN Un utilisateur peut visualiser les informations détaillées du livre : Nombre de page, date de publication, résumé. Un utilisateur peut mettre les livres dans un caddie pour les payer plus tard. Un utilisateur peut supprimer des livre du caddie. Pour payer un livre l’utilisateur saisit son adresse de facturation, son adresse de livraison et les informations de sa carte de crédit Un utilisateur peut évaluer un livre Un utilisateur peut créer un compte pour mémoriser ses informations
  75. 75. Estimation AgileTechnique d’estimation relative : La • Estimation au niveau Releasetriangulation • Technique des Story points Principe Comparer les PBI les uns par rapport aux autres Positionner les BPI sur l’échelle de valeurs 1 2 3 5 8 13 … PBI PBI PBI PBI PBI PBI PBI PBI PBI Estimation AgileLa triangulation : déroulement • Estimation au niveau Release • Technique des Story points PO : Choisir un PBI de référence et le présenter à l’équipe Equipe dev + PO : Discuter le PBI de référence Equipe dev : Estimer et Positionner le PBI de référence sur le tableau de triangulation PO : Passer au PBI suivant Equipe dev + PO : Discuter et comparer le PBI avec les PBI déjà positionnés Equipe dev : Positionner le PBI sur le tableau Changer les positions existantes si nécessaire

×