Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Initiation Scrum

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 45 Publicité

Initiation Scrum

Télécharger pour lire hors ligne

Formation "Initiation Scrum" (sur 1 ou 2 jours)
- comprendre les principes agile
- découverte de SCRUM (les rôles, les livrables, les évènements)
- expérimenter par la pratique

Formation "Initiation Scrum" (sur 1 ou 2 jours)
- comprendre les principes agile
- découverte de SCRUM (les rôles, les livrables, les évènements)
- expérimenter par la pratique

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Initiation Scrum (20)

Publicité

Plus récents (20)

Initiation Scrum

  1. 1. Formation Initiation Agilité - SCRUM Frantz DEGRIGNY frantz.degrigny@keyconsulting.fr mars 2017
  2. 2. • Cochez la bonne réponse • Relisez cette page à la fin de la journée. Vos réponses sont elles toujours les mêmes ? Vrai Faux Les équipes agiles font peu de planning L’agilité n’est pas adaptée pour un projet à budget fixe Les développeurs n’ont pas les compétences humaines nécessaire pour parler avec les clients Déplacer des personnes entre les projets aide à diffuser l’expertise et améliore l’organisation Les équipes agiles n’écrivent pas de documentation Certaines personnes ont besoin d’être dirigées Les équipes agiles n’ont pas besoin de spécifications Ceci est un exercice 2 min
  3. 3. • Qui a déjà utilisé L’agilité ? • Qui a déjà travaillé en équipe auto-organisée (sans chef) ? • Qui a déjà conduit un projet, dirigé une équipe ? • Qui connait SCRUM ? • Prenez un post-it et marquez 1 chose que vous voulez apprendre dans ce stage
  4. 4. - nom 1. La capacité de répondre rapidement à une demande changeante tout en contrôlant le risque 2. Flexibilité, la capacité à s’adapter rapidement, efficacement et de manière délibérée Le courage d’être assez honnête pour admettre qu’écrire des logiciels sur mesure est complexe et ne peut pas être parfaitement planifié car le besoin change inévitablement
  5. 5. • 3x plus de chances de succès ! • Une équipe très agile peut espérer 20% d’économies 14% 57% 29% Cycle en V 42% 49% 9% Agile Succès total Ok, mais avec des problèmes Echecs Source : The CHAOS Manifesto © 2011
  6. 6. 10 % 10 % Prix total = 110% Valeur = 90% Périmètre contractuel 1 - Cycle en V imprévus inutiles Prix total = 100% Valeur = 100% Périmètre initial 2 - Agile 10 % imprévus 10 % inutiles gaspillage avenant (v1.1) Expérience : en moyenne 20% d’écart à la fin
  7. 7. 1 - Cycle en V 2 - Agile Expérience : plus un bug est corrigé tard, plus il coûte cher Coût des bugs Fonctionalités Bugs Imprévus Fonctionalités Bugs Imprévus Inutile Temps passé Temps passé
  8. 8. Visibilité temps temps Capacité à prendre en compte les changements Valeur métier livrée temps Risque temps Cycle en V Scrum
  9. 9. Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu’une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L’adaptation au changement plus que le suivi d’un plan Source : http://agilemanifesto.org/ importantEssentiel Nous reconnaissons la valeur des éléments de droite, mais privilégions ceux de gauche !!
  10. 10. Transparence Toute méthode empirique nécessite de la transparence pour ses ajustements successifs Courage Affronter les vrais problèmes, oser des solutions innovantes nécessite du courage Respect Le respect de chacun est essentiel pour que le groupe collabore efficacement Responsabilité Faire sa part de travail et savoir reconnaitre ses torts Engagement Une valeur essentielle si on souhaite réussir un projet quel qu’il soit Humilité C’est une valeur utile pour éviter de s’acharner sur des choses qui, visiblement, ne fonctionnent pas bien. Confiance La confiance dans les autres est nécessaire à la bonne collaboration (de toute façon, on a prévu des moyens de s’adapter si des choses ne fonctionnent pas bien) Ouverture L’ouverture d’esprit est nécessaire pour profiter des tous les points de vue
  11. 11. Planning Analyse Conception Code Tests Livraison Revue Planning Revue Analyse Conception Code Tests Livraison Planning Revue Analyse Conception Code Tests Livraison Planning Revue Analyse Conception Code Tests Livraison Scrum Cycle en V Logiciel opérationnel disponible
  12. 12. L’intelligence collective émerge de principe simples mais souvent contre-intuitifs : • Fail fast and enjoy the fun ! • YAGNI (You Ain't Gonna Need It) • KISS (Keep It Simple and Stupide) • If it hurts, do it more often ! • Simplicity (the art of maximizing the amount of work not done) is essential • DRY (Don’t Repeat Yourself) • Perfection is when nothing can be removed, (not when you cannot add something more!) • It’s important ? : Do it always ; It’s not ? : do it never !
  13. 13. Equipe projet (Scrum team) = PO + Scum Master + DEV team Product Owner • Pilote le projet, à l’aide du Product Backlog • Optimise la valeur métier du produit fini Scrum Master • Garant de la méthode et de l’ambiance de travail • Protège l’équipe des perturbations externes • Aide l’équipe à s’auto-organiser et aide le PO à tenir son rôle Equipe de réalisation (DEV team) • Elle s’auto-organise • Livre des incréments terminés (potentiellement livrables) • Regroupe toutes les compétences nécessaires au projet
  14. 14. « Chaque Sprint, vous pouvez nous donner quelque chose de nouveau à faire » Equipe de réalisation « Chaque Sprint, nous vous laissons travailler sur nos besoins les plus importants » Clients FLEXIBILITÉ STABILITÉ
  15. 15. Sprint Sprint Planning Revue de Sprint guidée par Réalisation Daily Scrum Rétrospective du sprint 1 2 3 4 5 6 7 travail créatif et collaboratif 2 - 8h 1 à 4 semaines 1 - 4h 45min - 3h
  16. 16. • Product Owner • Scrum Master • Equipe de réalisation 3 Rôles 3 Artéfacts • Product Backlog • Sprint Backlog • Incrément 5 Evènements • Sprint Planning • Sprint • Daily Scrum • Revue de sprint • Rétrospective
  17. 17. ID Catégorie Module Titre Description Risque Business Value Points Charge ROI estimé 1.1 Back-Office éditorial Accueil Période d'essai 5 2 2,5 1.2 Back-Office éditorial Accueil Authentification ! 3 4 0,8 3Back-Office éditorial Parution PDF à destination d'un imprimeur 1 4 0,3 6.1 Application de lecture Publication Gestion des parutions (CRUD) 3 4 0,8 6.2 Application de lecture Kiosque Visualisation des publications abonné !! 4 2 2 6.3 Application de lecture Authentification Limitation du nombre d'appareils 1 3 0,3 23Back-Office éditorial Page de couverture Informations en surimpression 2 4 0,5 25Back-Office éditorial Article Multimédia / Publicité 2 4 0,5 27Back-Office éditorial Article Chapeau de l'article 2 3 0,7 28Back-Office éditorial Article Héritage d'article 3 4 0,8 8.2 Back-Office commercial Abonnement Souscription !!! 4 2 2 8.4 Back-Office commercial Abonnement Interfaçage WS ADV 2 4 0,5 31Back-Office commercial Ayants droits Imports de fichiers plats (csv / txt) 1 3 0,3 43Back-Office commercial Abonnement Upload des documents 3 3 1 44Back-Office Administration Contenu illicite Notification ! 1 2 0,5 45Back-Office Administration Contenu illicite Workflow état notification 1 2 0,5 47Back-Office Administration Divers Archivage / suppression 2 3 0,7 priorité
  18. 18. exigence exigence 0-6 mois 6-12 mois 12+ mois Futur Si rien ne change, alors … Idée vague Idée Idée exigence exigence exigence exigence exigence exigence Sprint 1 Sprint 2+3 Sprint ≥ 4
  19. 19. Analyse, évaluation et sélection des items du Product Backlog Définition de l’objectif et du périmètre du sprint Décomposition en plan d’action sous forme de tâches Sprint Backlog Standards Conventions Normes Définition de terminé Equipe de réalisation Capacité + Vélocité Product Backlog priorisé et estimé Durée : 6h pour un sprint de 3 semaines
  20. 20. Analyse, évaluation et sélection des items du Product Backlog Définition de l’objectif et du périmètre du sprint Décomposition en plan d’action sous forme de tâches Sprint Backlog Standards Conventions Normes Définition de terminé Equipe de réalisation Capacité + Vélocité Product Backlog priorisé et estimé Durée : 6h pour un sprint de 3 semaines Erreurs à éviter • Les items du backlog ne sont pas prêts pour la réalisation • Les items sont non chiffrés • Pas de critères d’acceptances • L’équipe ne connait pas sa capacité de production
  21. 21. • Tous les jours • 15 min • Même lieu, même heure • Suivi du Reste à Faire (ex. BurnDown chart) • Synchronisation de l’équipe et du travail en cours : • Qu’as-tu terminé hier ? • As-tu des problèmes ? • Que vas-tu faire aujourd’hui ? Scrum Master + Equipe de réalisation • Planning pour la journée • Pb ou questions à traiter hors séance • Reste à faire réévalué
  22. 22. • Tous les jours • 15 min • Même lieu, même heure • Suivi du Reste à Faire (ex. BurnDown chart) • Synchronisation de l’équipe et du travail en cours : • Qu’as-tu terminé hier ? • As-tu des problèmes ? • Que vas-tu faire aujourd’hui ? Scrum Master + Equipe de réalisation • Planning pour la journée • Pb ou questions à traiter hors séance • Reste à faire réévalué Erreurs à éviter • Parler en même temps • Tenter de résoudre un pb en séance • Se moquer / Juger • Avoir des réactions non productives
  23. 23. • Daily Scrum : Un plan pour chaque journée ! • Propriété collective du code :  Quick Design Session  Pas de « chasse gardée » • Intégration continue • Tests automatisés  Tests unitaires  Tests fonctionnels (Critères d’acceptance) • Qualité industrielle :  Respect conventions + Bonnes pratiques  Modules fonctionnels (AB testing, Design for failure…)  Relecture de code (Pair programming, Sonar…) • Documentation (Wiki + Quick Doc Sessions)
  24. 24. Présentation de l’état du projet et de l’incrément (démonstration) Recherche du feedback Mise en place d’une stratégie pour la suite du projet Product Backlog + Road Map à jour Contexte projet Product Backlog Sprint Backlog Incrément Tâches Comité de pilotage Durée : 3h pour un sprint de 3 semaines
  25. 25. Présentation de l’état du projet et de l’incrément (démonstration) Recherche du feedback Mise en place d’une stratégie pour la suite du projet Product Backlog + Road Map à jour Contexte projet Product Backlog Sprint Backlog Incrément Tâches Erreurs à éviter • Démo de plus d’une heure • La démo n’est pas une recette • Pas de critères d’acceptance • Le contexte projet n’est pas pris en compte • Pas de vision stratégique à plus d’un sprint Comité de pilotage Durée : 3h pour un sprint de 3 semaines
  26. 26. Etablir une vision partagée de l’efficacité actuelle de l’équipe Identifier 1 ou 2 leviers d’amélioration Identifier et choisir 1 ou 2 actions réalisables durant le prochain sprint Plan d’action pour s’améliorer Bilan de la dernière Rétro Bilan de la Revue Durée : 2h15 pour un sprint de 3 semaines
  27. 27. Etablir une vision partagée de l’efficacité actuelle de l’équipe Identifier 1 ou 2 leviers d’amélioration Identifier et choisir 1 ou 2 actions réalisables durant le prochain sprint Plan d’action pour s’améliorer Bilan de la dernière Rétro Bilan de la Revue Durée : 2h15 pour un sprint de 3 semaines Erreurs à éviter • Parler tous en même temps • Régler ses comptes • Cacher les problèmes • Essayer de résoudre les pb en séance • Etablir un plan d’action top ambitieux
  28. 28. • Exploiter au maximum chaque opportunité • Se débarrasser du monolithe • Une meilleure qualité • Une véritable réactivité au service du métier • Des personnes plus heureuses avec un travail qui a du sens • Un flot continue de haute valeur ajoutée L’Espoir La triste réalité • Une dette technique importante • Des mauvaises habitudes de codage • Pas de temps dédié pour les tests • Le micro-management des managers qui empêche l’auto-organisation • Des clients finaux qui ne peuvent avoir des livraisons que tous les 15 mois car elles sont trop ambitieuses, trop chères, trop risquées, et prennent tellement de temps à être implémentées Scrum c’est léger, simple, facile à comprendre, mais généralement difficile à maîtriser. Soyez préparés !
  29. 29. 1. Y a-t-il un Product Owner identifié, pilotant le projet ? 2. Y a-t-il une équipe de réalisation de 3 à 9 membres ? 3. Y a-t-il un Scrum Master nommé ? 4. Y a-t-il un Product Backlog ordonné et priorisé ? 5. Y a-t-il un Sprint Backlog montrant le reste à faire pour le sprint en cours ? 6. Chaque sprint dure entre 1 et 4 semaines ? 7. Le logiciel produit est-il potentiellement livrable à la fin de chaque Sprint ? 8. Est-ce que l’équipe créé un plan pour le Sprint durant une réunion de Sprint Planning ? 9. Est-ce que l’équipe créé un plan pour chaque journée durant le Daily Scrum ? 10.Est-ce que l’incrément est inspecté par les « stakeholders » (direction, utilisateurs…) durant la Revue de Sprint ? 11.Est-ce que l’équipe projet (ou Scrum Team = DEV + PO + SM) effectue une Rétrospective à la fin de chaque Sprint ?
  30. 30. Questions…?
  31. 31. Exigences : • Une ville verte, belle et agréable à vivre • Les logement individuels et collectifs • Une ville à la pointe de la technologie • Faible impact environnemental • Des transports en communs performants • Des facilités pour les commerces et les entreprises • Des bâtiments pour les services administratifs • Des équipements collectifs : • Loisirs • Education • Santé • Une ville facile à identifier • Des voies de communication : rues, routes et ponts
  32. 32. 1. Identifier les items et créer le Product Backlog 2. Evaluer et prioriser les items du Product Backlog 3. Estimer l’effort à fournir pour la réalisation 4. Etablir une road map 5. Faire le sprint planning du 1er sprint
  33. 33. 1. Identifier des items permettant de répondre aux exigences 2. Créez 1 post-it par item • Vous devriez avoir entre 10 et 15 items 15 min Ne cherchez pas la perfection, faites au mieux !
  34. 34. Votre équipe à 300 balles de ping-pong à dépenser 1. Donnez une valeur (nb de balles) à chaque item 2. Deux items ne peuvent pas avoir la même valeur 3. Ecrivez cette valeur relative sur chaque post-it 4. Triez 15 min
  35. 35. 1. Choisissez un item d’une taille moyenne et donner lui la valeur « 5 » 2. Chacun prend un set de carte de planning poker jusqu’à 20 3. Votez pour donner une valeur d’effort (de réalisation) pour chaque item note : cet effort est relatif • Si les votes sont proches, choisissez la valeur la plus haute • Si les votes sont trop différents : argumentez 4. Ecrivez l’effort sur chaque post-it 5. Faites la somme de l’effort total 15 min
  36. 36. priorité 20 min 1. Répartissez les items sur une carte en 2D 2. Tracer des lignes pour déterminer le périmètre des 4 premier sprints thèmes catégories items fonctionnalités important, nécessaire accessoire, de l’ordre du confort Sprint 2 Sprint 1 Sprint 3 Backlog
  37. 37. 10 min 1. Pour le sprint 1 et 2, décomposez les items en post-it avec une charge de travail relative ≤ 3 2. Pour les sprint 3 et 4 décomposez les items en post-it avec une charge de travail relative ≤ 8
  38. 38. 150 min 6 sprints de 25 min : • 5 min Planning • 10 min Réalisation • 5 min Revue • 5 min Rétrospective
  39. 39. 10 min J’ai passé une journée très intéressante à apprendre tout ces trucs de SCRUM. Mais quand je vais retourner à mon poste je vais toujours devoir livrer toutes les fonctionnalités du périmètre commandé en tenant les délais et les coûts. Quel est le rapport de tout ceci avec ma mission au quotidien ?
  40. 40. • Lisez le SCRUM Guide : http://scrumguides.org/ • Evaluez cette formation : http://tinyurl.com/kc-satisfaction-scrum READ THE GUIDE
  41. 41. MERCI POUR VOTRE ATTENTION

×