Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

1

Share

Download to read offline

Formation Professional Scrum Master I

Download to read offline

Support de formation pour la formation Professional Scrum Master I en vue de passer la certification PSM I.
Ce support est basé sur le scrum guide de 2017 (dernière version à jour à juillet 2020)
Pratique pour réviser avant de passer le Scrum PSM I de façon plus agréable et visuelle que le scrum guide.
Attention le support est en CC-BY mais les images utilisées pour Rôles / Artefacts / Events ne sont pas en CC-BY (à voir avec les sites s'ils autorisent l'utilisation, surtout pour une utilisation commerciale)

Related Books

Free with a 30 day trial from Scribd

See all

Formation Professional Scrum Master I

  1. 1. Basé sur le Scrum Guide, seule référence du PSM Préparation PSM 1 « Professional Scrum Master » Guillaume LAURIE - 2020 Les images ne sont pas soumises aux mêmes droits
  2. 2. Scrum Théorie, piliers, valeurs
  3. 3. Définition Ce que Scrum est : • Scrum est un framework processé permettant de développer des produits complexes • Scrum est léger, simple à comprendre, difficile à maîtriser Ce que Scrum n’est pas : • Scrum n’est pas une méthode, un process ou un outil • Scrum n’est pas une boîte à outils ou un livre de recettes
  4. 4. Mais encore ? • Scrum est composé de : • Evénements • Artéfacts • Rôles • Règles (qui décrivent les interactions entre chacun) • Scrum est basé sur : • Empirical process control theory (méthode empirique – par l’expérience) • L’itération, l’approche incrémentale et l’optimisation, le contrôle du risque
  5. 5. Utilisations de Scrum • Research and identify viable markets, technologies, and product capabilities; • Develop products and enhancements; • Release products and enhancements, as frequently as many times per day; • Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and, • Sustain and renew products.
  6. 6. Piliers de Scrum Transparence • Le travail et les résultats doivent être visibles par l’ensemble de l’équipe Scrum • L’équipe Scrum partage un langage commun et des standards • L’équipe Scrum partage la même « definition of done » Inspection • L’équipe Scrum doit régulièrement inspecter afin de détecter des variations entre l’attendu et le réaliser pour détecter les variances • Les inspections doivent être fréquentes sans pour autant gêner le travail et l’atteinte du goal Adaptation • L’équipe Scrum peut décider à tout moment de s’adapter si elle découvre qu’elle dévie et qu’elle se dirige vers un produit « inacceptable ». L’adaptation doit se faire as soon as possible sans pour autant mettre en danger le sprint goal
  7. 7. Valeurs de Scrum Commitment (engagement): les équipes s’engagent sur le résultat Courage : relève les challenges et traitent les problèmes Focus : Reste focus sur la destination, le sprint goal Openness (ouverture) : rester ouvert aux changements Respect : le respect est la base de la confiance
  8. 8. Definition of Done (DoD) Un PBI ou un incrément sont considérés comme « fini » (done) lorsqu’ils répondent à la « definition of done ». La definition of done peut donc varier beaucoup d’une équipe scrum à une autre. Le DoD permet de s’assurer que l’incrément est potentiellement releasable Le DoD peut faire partie des conventions, normes ou directives de développement – dans ce cas, elle sera respectée par toutes les équipes Scrum, sinon elles devront créer une DoD commune
  9. 9. Scrum Evénements
  10. 10. ATTENTION : Le SPRINT n’est pas un événement, il faut le considérer comme un container qui contient des événements, lorsqu’on sort d’un sprint, on entre dans un autre sprint. Source image : mailjet.com Les événements – le concept d’itération
  11. 11. Sprint planning : Max : 8h / 1 mois Equipe Scrum Input : Product Backlog + Increment Output : Sprint Goal + Sprint Backlog + plan to deliver (first days detailed) Sprint retrospective : Max : 3h / 1 mois Equipe Scrum Input : ce qui s’est bien / mal passé Output : 1 high priority improvement for the process Sprint review : Max : 4h / 1 mois Equipe Scrum / Key stakeholders Input : Livraison incrément Output : De nouvelles tâches proposées par Key Stakeholders Daily Scrum : Max : 15 min Equipe Dev Output : Point sur ce qui a été fait et ce qui sera fait + problème Refinement (non événement) : Max : 10% du temps du sprint Equipe Dev / PO Input : nouvelles tâches Output : maj backlog avec nouvelles tâches ATTENTION : Le SPRINT n’est pas un événement, il faut le considérer comme un container qui contient des événements.
  12. 12. Sprint planning : Time-box : 8h / si sprint 1 mois Qui : Equipe Scrum Input : Product Backlog + Increment Output : Sprint Goal + Sprint Backlog + plan to deliver (first days detailed) Le PO peut aider à clarifier les items. By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment. Sprint goal ? Qui le créé : Equipe dev C’est la raison d’être du sprint, la cohérence, il ne doit pas changer une fois le sprint démarré. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting.
  13. 13. Daily Scrum : Timebox : 15 min Qui : Equipe Dev Pas forcément debout mais recommandé ! L’essentiel : court et bien structuré (et focus sur le sprint goal). 3 questions que l’on trouve dans le scrum guide : Qu’as-tu fait hier ? Que fais-tu aujourd’hui ? Est-ce que tu as rencontré des problèmes qui pourraient empêcher la livraison ? Le Scrum master s’assure que la réunion ait lieu (c’est sa responsabilité en tant que garant du framework). But : éliminer les autres réunions, améliorer la communication, identifier les problèmes (impediments), facilite une prise de décision rapide…
  14. 14. Sprint review : Max : 4h / si sprint 1 mois Qui : Equipe Scrum / Key stakeholders Input : Livraison incrément – un incrément correspond au précédent incrément + les tâches répondant à la « définition of done » terminées pendant le sprint Pendant : L’occasion de collaborer sur le done réalisé pendant le sprint et écouter les nouvelles demandes des key stakeholders Output : Un backlog mis à jour et réordonné ! (De nouvelles tâches proposées par Key Stakeholders au PO) Attention, il s’agit d’un meeting informel ! Le PO peut inviter des stakeholders But : enregistrer l’avancement de l’incrément et prendre de nouvelles idées
  15. 15. Sprint retrospective : Max : 3h / 1 mois Qui : Equipe Scrum Pendant : ce qui s’est bien / mal passé Output : 1 high priority improvement for the process But : inspection du fonctionnement de l’équipe et créer un plan pour améliorer le fonctionnement pour le prochain sprint Même si les improvements peuvent être faits tout le temps, il s’agit d’un temps formel permettant d’inspecter et s’adapter
  16. 16. Product Backlog Refinement (attention, ce n’est pas un événement): Max : 10% du temps du sprint Qui : Equipe Dev / Po Pendant : Ajouter des détails aux PBI (product backlog items), estimer les tâches et ordonner le PB (product backlog) Output : maj backlog avec nouvelles tâches
  17. 17. Scrum Artéfacts
  18. 18. Product Backlog : • Responsable : Product Owner • Utilisation : Alimente le Sprint Planning • Doit être visible (accessible par l’équipe scrum) et ordonné (pour refleter les priorités du PO) • Liste toutes les fonctionnalités à developer, leurs pré-requis, ameliorations et corrections • Devient plus fourni au fur et à mesure que le produit avance • Plus un item est haut dans le Product Backlog et plus il est affiné / clair et leur estimation (à la charge de l’équipe dev) est plus precise • Rempli par le Product Owner ou à la discretion du Product Owner Le product backlog est dynamique, en changement constant – Tant qu’un produit existe, son product backlog existe 1 seul Product Backlog par projet (même si de nombreuses équipes Dev)
  19. 19. Sprint Backlog : • Responsable : Dev Team • Créé lors : du Sprint planning, alimenté en utilisant les PBI (+ le plan) • Représente : Le travail à réaliser par l’équipe dév pour atteindre le sprint goal (défini lors du sprint planning) • Est une prévision de ce que sera le prochain incrément • Doit être suffisamment clair pour permettre aux équipe de developer les fonctionnalités • Le Sprint backlog est modifié au cours du sprint • L’équipe dev maintient à jour le monitoring du travail restant (souvent au travers du burn-down chart) Seul l’équipe de dev peut modifier son contenu ! Chaque daily scrum, on fait le point sur le volume de travail restant, on alerte le PO si on n’atteindra pas le sprint goal 1 sprint goal par équipe scrum
  20. 20. Incrément : • Responsable : Product Owner • Créé lors : En ajoutant l’increment précédant + le travail fournit dans le dernier sprint • Représente : Le logiciel qui fonctionne partiellement releasable • Doit être utilisable selon les conditions du Definition of Done Seul le PO peut decider de le releaser ! Toutes les équipes Scrum travaille sur le même Incrément
  21. 21. Transparence des artéfacts : • Pilier de la démarche empirique, les increments doivent être transparents • Des artéfacts non transparents ne permettent pas d’optimiser la valeur business ni la productivité et font augmenter les risques • Le Scrum Master doit travailler avec le PO et l’équipe pour s’assurer de la transparence des artéfacts • Cela passe par l’inspection mais également par la sensibilisation et l’accompagnement au changement Source image : 4tempsdumanagement.com
  22. 22. Scrum Les rôles
  23. 23. Source image : Œil de coach IMPORTANT : Notez l’absence du “project manager” qui n’existe pas dans SCRUM et n’est pas remplacé !
  24. 24. Le Product Owner : augmenter la valeur • S’assure de créer des PBI clairs (product backlog items) et compris par l’équipe de dev • Ordonner le Product Backlog (selon l’ordre qui lui semble le plus adapté) • Optimiser la valeur de ce qui est produit par l’équipe dev • S’assurer que le Product Backlog est visible, clair et transparent et montre sur quoi porteront les prochains sprint • Est en charge du monitoring des progrès vers l’objectif en mesurant le travail accompli et restant Responsable : product backlog 1 seul Product Owner par Produit 1 seul Product Backlog par Produit
  25. 25. L’équipe de dev : Produire un incrément • S’auto organisent pour arriver à un increment à partir du product backlog (créé leur équipe par exemple) et n’ont pas besoin de quelqu’un qui leur dit quoi faire (comme le scrum master) • Cross functionnal, ils ont les compétences requises pour produire l’incrément et ne dépendent pas d’individus externes • Pas de titres, pas de divisions par spécialité, l’équipe est responsable de tout pas les individus Responsable : sprint backlog + plan / daily scrum Taille : 3 à 9 Product Owner et Scrum Master peuvent faire partie de l’équipe de dev mais ce n’est pas une bonne pratique
  26. 26. Le Scrum Master : Garant du framework • Servent-Leader, le Scrum Master N’EST PAS un manager ! Il ne donne aucun ordre, ne décide rien • S’assure que chacun dans l’équipe scrum comprend les rôles, les événements, les artéfacts, les règles • S’assure que chacun dans l’équipe scrum comprend la théorie, les pratiques et les valeurs • Aide ceux qui sont à l’extérieur de l’équipe scrum à communiquer avec l’équipe scrum (afin d’améliorer les intéractions) Responsable : Bonne application du framework et chacun comprend son rôle
  27. 27. Le Scrum Master : Au service du Product Owner • S’assure que chacun comprend ce qui est attendu (but, périmètre, domaine…) • Trouve des techniques de management du Product Backlog (mais ne les impose pas) • Aide l’équipe scrum à comprendre l’importance de PBI clairs et concis • Aide à comprendre la planification dans un process empirique (basé sur l’expérience) • S’assure que le PO comprend comment organiser son product backlog pour produire le maximum de valeur • Facilite les événements Scrum si demandé ou si besoin Responsable : S’assurer que le PO (product owner) a bien compris ses responsabilités (notamment le fait qu’il pilote le projet au travers du backlog)
  28. 28. Le Scrum Master : Au service de l’équipe dev • Coach l’équipe pour leur permettre de s’auto-organiser et être cross functionnal (non spécialisés) • Les aide à créer des incréments à forte valeur ajoutée • Enlève les obstacles (impediments) qui pourraient se placer sur le chemin et empêcher l’atteinte du sprint goal • Facilite les événements Scrum si demandé ou si besoin • Coach l’équipe de dév dans un environnement dans lequel Scrum n’est pas encore compris ni adopté Responsable : S’assurer que l’équipe de dév a bien compris ses responsabilités (notamment le fait de produire un incrément et atteindre le sprint goal)
  29. 29. Le Scrum Master : Au service de l’organisation • Aide l’organisation dans son adoption de Scrum (leading et coaching) • Planifie l’implementation de scrum dans l’organisation • Aide les employés et parties prenantes à comprendre et mettre en place scrum et le process empirique de développement de produit • Créer les changements qui permette d’améliorer la productivité de l’équipe scrum • Travailler avec les autres scrum masters pour améliorer l’efficacité de l’application de scrum dans l’organisation. Responsable : du bon déploiement de Scrum dans l’organisation
  30. 30. Scrum Points d’attention
  31. 31. NFR : Non Functionnal Requirements Les NFR sont des exigences qui ne sont pas des fonctionnalités. Il peut s’agir de sécurité ou de performances par exemple. On les traite à 3 endroits : • DoD : si ce sont des standards nécessaires à toutes les fonctionnalités • Backlog Produit : si représente une fonctionnalité • Intégrées aux critères d’acceptation des PBII
  32. 32. Concept d’auto-organisation Le concept d’auto- organisation de l’équipe de dév est au cœur de Scrum. L’équipe n’a pas de chef et n’a pas besoin de l’aide d’une personne extérieure pour lui dicter sa conduite L’équipe s’organise seule pour atteindre ses objectifs et doit s’assurer son côté cross- functionnal Donc les équipes ne doivent pas être spécialisées (tests par exemple) mais capables de gérer l’atteinte du sprint goal Les développeurs doivent être considérés comme un ensemble d’experts capables de se répartir en équipes sans aide extérieur du moment qu’on leur explique l’importance d’équipes pluridisciplinaires et le projet à réaliser
  33. 33. Annulation de Sprint Un sprint peut être annulé si son sprint goal est devenu obsolète (très rare car un sprint dure maximum un mois) Seul le PO peut annuler un Sprint (même s’il le fait à la demande des stakeholders, de l’équipe ou du Scrum Master) Les PBI qui ont atteint le « Done » (voir DoD) peuvent être review, le PO peut ainsi les accepter si releasable. Tous les PBI non terminés sont réestimés et retournent dans le Product Backlog. L’annulation de sprint est perturbant pour l’équipe et très rares
  34. 34. Alors prêt pour la certification ? Pensez à vous entraîner sur Scrum.org, 30 questions disponibles, pas toujours les mêmes (permet d’avoir une partie des questions du tests) https://www.scrum.org/open- assessments/scrum-open Entraînez-vous en utilisant également le test de Mikhail Lapshin https://mlapshin.com/index.php/scrum- quizzes/ Guillaume LAURIE - 2020 Les images ne sont pas soumises aux mêmes droits
  • SebastienDeceglie

    Oct. 7, 2020

Support de formation pour la formation Professional Scrum Master I en vue de passer la certification PSM I. Ce support est basé sur le scrum guide de 2017 (dernière version à jour à juillet 2020) Pratique pour réviser avant de passer le Scrum PSM I de façon plus agréable et visuelle que le scrum guide. Attention le support est en CC-BY mais les images utilisées pour Rôles / Artefacts / Events ne sont pas en CC-BY (à voir avec les sites s'ils autorisent l'utilisation, surtout pour une utilisation commerciale)

Views

Total views

718

On Slideshare

0

From embeds

0

Number of embeds

1

Actions

Downloads

30

Shares

0

Comments

0

Likes

1

×