SlideShare ist ein Scribd-Unternehmen logo
1 von 51
Sylvain Gallioz et Fabrice Thomas
17/06/2014
21/07/2014
1Mastère spécialisé : Management par Projets
 Etat des lieux
 Qu’est-ce que l’agilité ?
 Scrum
 Rôles
 Artefacts
 Certification
 Annexes
21/07/2014 2
S. Gallioz et F. Thomas, 2014
21/07/2014
3
Taux de succès des projets informatiques en 2009 de
32%
 Source : enquête Standish Group sur 8000 projets
Etat des lieux
21/07/2014 4
Fonctionnalités utilisées d’un SI en %
(source: Standish Group Study reported at XP2002 by Jim Johnsonn, chairman)
Peu de fonctionnalités développées réellement utilisées
 45% de fonctionnalités jamais utilisées
S. Gallioz et F. Thomas, 2014
Etat des lieux
21/07/2014 5
La stabilité est la norme
• Les prévisions précises sont possibles
• L’important c’est de maintenir le cap
• Plus de rigueur et de contrôle augmentent
le niveau de sécurité et la probabilité de
réussir
Le changement est la norme
• L’incertitude et la complexité taxent la précision de
nos prévisions
• Il faut saisir les opportunités et encourager le
changement
• Plus de flexibilité augmente le niveau d’adaptation
aux changements et la probabilité de réussir et de se
dépasser
S. Gallioz et F. Thomas, 2014
 Le périmètre fonctionnel du projet n’est pas très clair et risque de bouger au
cours du projet
 Il y a de forts risques de ne pas réussir facilement à répondre au besoin du
client, et il peut être salutaire de valider régulièrement avec le client ce qui est
réalisé par l’équipe
 Il y a de forts risques techniques et il peut être salutaire d’avoir la capacité de
traiter ces risques techniques par une validation technique régulière du
produit
 Il est nécessaire de livrer très rapidement une première version, quitte à livrer
une première version ne contenant que les fonctionnalités primordiales
21/07/2014 6
S. Gallioz et F. Thomas, 2014
21/07/2014
7
Qu’est-ce que l’agilité ?
Personnes et interactions plutôt que processus et outils
Logiciel fonctionnel plutôt que documentation complète
Collaboration avec le client plutôt que négociation de contrat
Réagir au changement plutôt que suivre un plan
Le Manifeste agile est un texte rédigé par 17 experts du
développement d'applications informatiques - Février 2001
S. Gallioz et F. Thomas, 2014 8
 Notre plus haute priorité est de satisfaire le client en livrant rapidement et
régulièrement des fonctionnalités à grande valeur ajoutée.
 Accueillez positivement les changements de besoins, même tard dans le projet. Les
processus agiles exploitent le changement pour donner un avantage compétitif au client.
 Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à
quelques mois et une préférence pour les plus courts.
 Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble
quotidiennement tout au long du projet.
 Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le
soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
 La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de
développement et à l’intérieur de celle-ci est le dialogue en face à face.
 Un logiciel opérationnel est la principale mesure d’avancement.
 Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les
commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir
indéfiniment un rythme constant.
 Une attention continue à l'excellence technique et à une bonne conception renforce
l’agilité.
 La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
 Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-
organisées.
 À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et
modifie son comportement en conséquence.
21/07/2014 9S. Gallioz et F. Thomas, 2014
Qu’est-ce que l’agilité ?
21/07/2014 10
Valeur Métier
(valeur pour l’utilisateur)
Approche Agile
Approche classique
Temps
Itérations (livraison régulière des nouvelles fonctionnalités réalisées)
Fin élaboration Fin réalisation Fin recette
DéploiementDéploiement
Déploiement
Déploiement
Déploiement
S. Gallioz et F. Thomas, 2014
21/07/2014
11
Scrum
21/07/2014 12
State of Agile Survey (VersionOne) - 2014
S. Gallioz et F. Thomas, 2014
Ken Schwaber et Jeff Sutherland sont les concepteurs de Scrum
Scrum
21/07/2014 13
Scrum est un cadre de travail qui a été
employé pour gérer le développement
de produit complexe depuis le début
des années 1990
Scrum n’est pas une procédure ou
une technique pour construire des
produits
L’équipe et Le rôle des membres,
Les évènements,
Les artéfacts,
Les règles.
Le Cadre
Scrum
Chaque élément du cadre répond
à un but spécifique et est
essentiel à la réussite et à
l'utilisation de Scrum.
S. Gallioz et F. Thomas, 2014
Transparence Inspection Adaptation
21/07/2014 14
Approche Itérative & Incrémentale
Théorie de contrôle des processus
empiriques
1 2 3
S. Gallioz et F. Thomas, 2014
Scrum
21/07/2014 15
5 Evénements
3
artéfacts
3 rôles
Product Owner
Scrum Master
Equipe de réalisation
Backlog du produit
Backlog du Sprint
Incrément
Sprint
Planification du Sprint
Daily Scrum
Revue du sprint
Rétrospective de Sprint
S. Gallioz et F. Thomas, 2014
Scrum
21/07/2014 16
Planification Revue Sprint
Rétrospective
Un but unique et commun :
Produire au plus tôt un maximum de valeur métier
par incréments de grande qualité et industrialisés
S. Gallioz et F. Thomas, 2014
21/07/2014
17
Scrum
21/07/2014 18
Sur quel type de contrôle de processus est basé Scrum ?
Hybride
Définie
Complexe
EmpiriqueA
B
C
D
Scrum
21/07/2014 19
Quel sont les 3 piliers de la théorie du contrôle empirique de
processus ?
Planification, de démonstration, rétrospective
Le respect des personnes, Kaizen, élimination du gaspillage
L'inspection, la transparence, l'adaptation
Transparence, l'élimination des déchets, KaizenA
B
C
D
21/07/2014
20
Rôles
21/07/2014 21
Une équipe auto-organisée
et pluridisciplinaire
Flexibilité - Créativité - Productivité
• Exprimer clairement les éléments du backlog,
• Hiérarchiser les éléments en fonction des objectifs,
• S’assurer de la valeur du travail,
• Rendre visible le backlog,
• S’assurer que l’équipe comprend les éléments du backlog
Product Owner (PO) est chargé
de maximiser la valeur du
produit et du travail de l’équipe
L’équipe réalise les incréments
du produits
• Elle est auto-organisée. Elle est autonome dans la réalisation de l’incrément
• Tous les membres ont le titre de développeurs (indépendamment du travail à réaliser)
• La responsabilité appartient à l’équipe dans son ensemble (solidarité)
• Il n’existe pas de sous décomposition
• Taille de l’équipe entre 4 et 9 développeurs
Scrum Master (SM) est
responsable de la
compréhension et de
l’application de Scrum
• Il est au service du Product Owner
• Il est au service de l’équipe de réalisation
• Il est au service de l’organisation
S. Gallioz et F. Thomas, 2014
Rôles
21/07/2014 22
Au service du Product
Owner
Au service de l’équipe Au service de l’organisation
• Trouve des techniques pour la
gestion efficace du backlog,
• Communique clairement la vision,
les objectifs et les éléments du
backlog à l’équipe,
• Enseigne à l’équipe de
développement comment créer des
éléments backlog,
• Comprend la planification du
produit ,
• Comprend et pratique l’agilité,
• Facilite des l’événements à la
demande ou quand c’est
nécessaire.
• Aide l’équipe à apprendre comment
s’auto-organiser,
• Enseigne et mène l’équipe à livrer
des produits de haute valeur,
• Protège l’équipe des obstacles
pouvant nuire à l’équipe,
• Facilite des l’événements à la
demande ou quand c’est
nécessaire,
• Accompagne l’équipe dans les
événements organisationnels où
Scrum n’est pas encore adopté et
compris.
• Accompagne l’organisation dans ses
effort d’adoption de Scrum,
• Planifie des mises en œuvres de
Scrum au sein de l’organisation,
• Aide à la compréhension Scrum au
travers de l’organisation,
• Provoque le changement qui est
susceptible d’accroitre la
productivité de l’équipe,
• Travaille avec d’autre Scrum Master
dans le but d’améliorer l’efficacité
les pratiques de Scrum dans
l’organisation.
S. Gallioz et F. Thomas, 2014
21/07/2014
23
Scrum
21/07/2014 24
Qui est responsable de l'enregistrement des estimations de
travail pendant un Sprint ?
Le Scrum Master
l'équipe de développement
Le plus jeune membre de l'équipe
Le Product OwnerA
B
C
D
21/07/2014
25
 Un backlog est une liste de fonctionnalités (Story) de plusieurs types : user,
technical, defect
 Il existe deux backlogs :
 Product Backlog : il recense les stories du projet, priorisées en fonction de la
valeur métier que rapporte
 Sprint Backlog : à partir des stories sélectionnées et détaillées par le PO, les
développeurs identifient les tâches unitaires qui les composent
 Le Product Backlog est géré par le Product Owner
 Le Sprint Backlog est géré :
 par le Product Owner pour les aspects fonctionnels
 par l’équipe pour les aspects techniques (découpage en tâches)
 L’incrément est la somme de toutes les fonctionnalités terminées pendant
un sprint. Il s’additionne aux autres incréments
Artefacts
21/07/2014 26
S. Gallioz et F. Thomas, 2014
Artefacts
21/07/2014 27
N° Priorité Item Critère
d’acceptation
Estimation Release Sprint Statut
42 3 En tant qu’acheteur
en ligne, je veux
pouvoir supprimer
un article de mon
panier
L’article est
supprimé du
panier quand je
clique sur
« Supprimer ». Je
peux voir que
l’article ne fait
plus parti de mon
panier
5 2 Terminé
… …
Priorité Haute
Priorité Basse
Les fonctions peuvent être ajoutées, repriorisées et supprimées à tout moment.
La préparation est une activité à temps partiel (pendant le Sprint) et elle ne doit
pas prendre plus de 10% de la capacité de l’équipe.
S. Gallioz et F. Thomas, 2014
21/07/2014 29
Sprint Revue
Rétrospective
Planification
Mêlée
quotidienne
Réalisation
Backlog Incrément
Sprint
MêléePlanning Revue Rétro.
S. Gallioz et F. Thomas, 2014
 Bloc de temps : de 1 semaine à 4 semaines
 A la fin du bloc : Incrément produit « Terminé »
 Durée constante
 Contenu :
◦ Réunion de planification,
◦ Mêlées quotidiennes,
◦ Période de réalisation,
◦ Revue de Sprint,
◦ Rétrospective.
 Pendant le Sprint :
◦ Aucun changement : équipe, objectifs et qualité,
◦ Le contenu peut être renégocié entre PO et l’équipe
 Annulation (objectif du sprint obsolète) : Responsabilité du PO
21/07/2014 30S. Gallioz et F. Thomas, 2014
 Toute l’équipe Scrum
 Réunion de 8h pour un sprint d’un mois
 Deux parties :
◦ Qu’est ce qui sera livré dans l’incrément résultant du
prochain Sprint ?
◦ Comment le travail nécessaire pour réaliser l’incrément
sera-t-il accompli ?
 Définir des tâches d’une journée ou moins
21/07/2014 31S. Gallioz et F. Thomas, 2014
 Bloc de temps : 15 minutes
 Objectif : Synchroniser et planifier la journée
 Tous les jours et uniquement l’équipe de réalisation
 A la même heure et au même endroit
 Questions à traiter par chacun des membres :
◦ Ce qu’il a réalisé depuis la dernière réunion
◦ Ce qu’il réalisera avant la prochaine réunion
◦ Les difficultés qu’il rencontre
21/07/2014 32
Le Scrum Master
• S’assure que la mêlée a lieu
• Aider l’équipe sur la tenue de
la mêlée
• Veille à l’application des
règles
S. Gallioz et F. Thomas, 2014
 Bloc de temps : 4h pour un sprint de 4 semaines
 Objectif : inspecter l’incrément du produit et adapter le
backlog si nécessaire.
 Qui ? : Equipe Scrum et partie prenantes
 Points abordés :
◦ Le PO identifie ce qui a été « terminé » et le reste
◦ L’Equipe de réalisation discute de ce qui s’est bien déroulé et des problèmes
rencontrés et comment ils ont été résolus
◦ L’équipe de réalisation démontre le travail et répond aux questions
◦ Le PO discute du backlog produit et détermine des dates probable d’achèvement
◦ L’ensemble du groupe convient de ce qu’il faut faire pour la suite
21/07/2014 33S. Gallioz et F. Thomas, 2014
 Bloc de temps : 3h pour un sprint de 4 semaines
 Objectif : inspecter et créer un plan d’améliorations
 Quand : Après la revue de sprint
 Points abordés :
◦ Inspecter la manière dont le dernier sprint s’est déroulé en ce qui concerne
les personnes, les relations, les processus et les outils,
◦ Identifier et ordonner les éléments majeurs qui se sont bien déroulés et les
améliorations potentielles
◦ Créer un plan pour améliorer les processus de travail de l’équipe Scrum
21/07/2014 34S. Gallioz et F. Thomas, 2014
21/07/2014
35
Scrum
21/07/2014 36
Quelle est la principale raison pour le Scrum Master d'être à la
mêlée quotidienne?
Pour s'assurer que chaque membre de l'équipe répond aux trois
questions dans le bon ordre de l'équipe.
Pour écrire toutes les modifications apportées à l'arriéré Sprint, y
compris l'ajout de nouveaux éléments, et le suivi des progrès sur le
traitement non sélectif.
Pour recueillir l'état ​​et la progression à signaler à la direction.
Il n'a pas à être là, il doit seulement s’assurer que l'équipe de
développement a une mêlée quotidienne
A
B
C
D
Scrum
21/07/2014 37
Pourquoi le Scrum quotidien se déroule au même moment et au
même endroit ?
La cohérence de réduire la complexité et les frais généraux.
Le Product Owner l'exige
Les salles sont difficiles à réserver et cela permet de les réserver à
l'avance
L'endroit peut être nomméA
B
C
D
Scrum
21/07/2014 38
Quand commence le prochain Sprint ?
Immédiatement après la prochaine planification de sprint
Lundi prochain
Immédiatement après la conclusion du précédent Sprint
Lorsque le Product Owner est prêtA
B
C
D
21/07/2014 39
Sprint 3
MêléePlanning Revue Rétro.
Sprint 3Sprint 2Sprint 1 Sprint 4 Sprint 5
Incrément
Incrément
Incrément
Incrément
Backlog
Produit
Backlog
Produit
Backlog
Produit Backlog
Produit
Backlog
Produit
Sprint
Backlog
Feedback
Inspiré du guide : The scrum master training manual
- MP Management Plaza
S. Gallioz et F. Thomas, 2014
21/07/2014 40
 Nombre de questions : 80
 Temps : 60 minutes
 Ou : En ligne sur le site Srcum.org
 Coût : 100 $
 Condition d’obtention : 85 % de bonnes réponses
21/07/2014
41
 Planning Poker
 Le Feeling Board
 User Story
 Story Board
 Burndown Chart
 Risk Board
 Maturité Scrum
21/07/2014 42S. Gallioz et F. Thomas, 2014
 Elle est déterminée démocratiquement par l’équipe pendant une
séance de « planning poker »
 Elle reste une estimation
21/07/2014 43
• Un jeu de carte est remis aux participants
• L’équipe définit un étalon (story pour laquelle l’équipe
définit en commun une valeur arbitraire)
• Le PO présente une nouvelle story
• Les membres interrogent le PO pour comprendre la story
• Chaque participant choisit qui correspond le mieux selon
lui à l’estimation
• Tous les participants dévoilent en même temps leurs
cartes et discutent des différences
• A la suite, le groupe ré-estime la story jusqu’à trouver un
accord
• Le PO passe à la story suivante …
S. Gallioz et F. Thomas, 2014
 Une façon simple et efficace de savoir si l’équipe va bien
 Un tableau au mur, avec une case pour chaque jour du sprint
 Chaque soir, chaque membre de l’équipe met une gommette dans la
case de la journée :
 Gommette verte : j’ai passé une bonne journée
 Gommette orange journée moyenne
 Gommette rouge : journée pénible
21/07/2014 44
lundi mardi mercredi jeudi vendredi
S. Gallioz et F. Thomas, 2014
En tant que acheteur, je veux pouvoir supprimer un article de mon panier
afin de corriger une erreur
21/07/2014 45
20
56
En tant qu’acheteur en
ligne, je veux pouvoir
supprimer un article de
mon panier afin de
corriger une erreur
Release:2 id.:43
Qui Action
Résultat
Une priorité métier
Macro : Must / Should / Could /
Wish
Micro : 1, 2, 3, 4, 5, 6 …
Une valeur métier
10, 20, 30, …
Une complexité technique
1, 2, 3, 5, 8, 13, 21, 34, 55, 89
Critères d’acceptation :
L’article est supprimé du panier quand je
clique sur « Supprimer ». Je peux voir que
l’article ne fait plus parti de mon panier
S. Gallioz et F. Thomas, 2014
 Techniques pour la collaboration :
 Management visuel sur les murs, ateliers collaboratifs
 Co-localisation des équipes de travail
 Equipes dédiées
21/07/2014 46
Objectif Stories A faire En cours Fini Obstacles
Ecrire l’objectif
du sprint
Tâches
S. Gallioz et F. Thomas, 2014
 Le burndown chart montre la taille de ce qui reste à faire dans le
backlog, sprint après sprint ou jour après jour
21/07/2014 47
S. Gallioz et F. Thomas, 2014
21/07/2014 48
http://www.qualitystreet.fr/2009/04/04/risk-board-la-gestion-agile-des-risques-conforme-a-cmmi-et-a-pmi/
QualityStreet – Blog Pro de Jean Claude Grosjean
S. Gallioz et F. Thomas, 2014
21/07/2014 49S. Gallioz et F. Thomas, 2014
21/07/2014 50
Domaines Thèmes Détails OUI /NON
Note
thème
Note
Domaine
L'équipe partage le même langage O
L'équipe partage la même définition des termes N
L'avancement du processus est visible O
L'équipe passe en revue le Backlog et le plan du Sprint N
L'équipe passe en revue l'état d'avancement en fonction de l'objectif à atteindre O
les revues sont réalisées par une personne expérimentée et extérieur à l'équipe N
Des actions sont prises si les processus ont besoins d'être ajustés O
Des actions sont prises si le produit résultant sera inacceptable O
Un et un seul Backlog par produit O
Le PO le met à jour très régulièrement O
Il est toujours bien rangé par priorité O
Tout le monde s'en sert N
Il comprend bien des stories (pas des tâches) O
Les stories techniques sont dans le Backlog O
Les bugs sont dans le Bakclog O
Chaque Story a ses tests d'acceptation O
Un et un seul plan par Sprint O
Il est facilement visible O
Il est mis à jour quotidiennement N
Une tâche fait en moyenne un jour N
Une tâche est liée à une Story O
Le reste à faire est estimé par l'équipe O
Il est mis à jour tous les jours O
Il est affiché et visible O
Il sert à décider sur l'objectif du Sprint O
Il est mis à jour à chaque fin de Sprint O
Il est affiché et visible N
Il sert à décider sur l'objectif de la release O
Backlog du produit
Plan de Sprint
Burndown de Sprint
Burndown de release
Artefacts
4,4
3,3
5,0
3,3
Principes
3
3,3
1,7
5
2
Transparence
Inspection
Adaptation
S. Gallioz et F. Thomas, 2014
Scrum : le guide pratique de la méthode agile la plus populaire –
Claude Aubry (édition Dunod)
Guide Scrum : https://www.scrum.org/Scrum-Guide
21/07/2014
51

Weitere ähnliche Inhalte

Was ist angesagt?

Scrum les principes de base
Scrum les principes de base Scrum les principes de base
Scrum les principes de base Sirine Barguaoui
 
présentation de soutenance PFE
présentation de soutenance PFEprésentation de soutenance PFE
présentation de soutenance PFEKarim Labidi
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: ScrumChaymaMghazli
 
MÃthode-agile-SCRUM.pptx
MÃthode-agile-SCRUM.pptxMÃthode-agile-SCRUM.pptx
MÃthode-agile-SCRUM.pptxJaweherBN
 
Formation Professional Scrum Master I
Formation Professional Scrum Master IFormation Professional Scrum Master I
Formation Professional Scrum Master IGuillaume LAURIE
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPSarah
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: ScrumChaymaMghazli
 
Présentation de l’agilité
Présentation de l’agilitéPrésentation de l’agilité
Présentation de l’agilitéJean Yves Klein
 
Gestion de projets agiles avec scrum
Gestion de projets agiles avec scrumGestion de projets agiles avec scrum
Gestion de projets agiles avec scrumPierre E. NEIS
 
Rapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelBelwafi Bilel
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
Soutenance de fin d’étude promotion srs 2012
Soutenance de fin d’étude promotion srs 2012Soutenance de fin d’étude promotion srs 2012
Soutenance de fin d’étude promotion srs 2012jedjenderedjian
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testahmed oumezzine
 

Was ist angesagt? (20)

Scrum les principes de base
Scrum les principes de base Scrum les principes de base
Scrum les principes de base
 
Méthodes agiles
Méthodes agilesMéthodes agiles
Méthodes agiles
 
présentation de soutenance PFE
présentation de soutenance PFEprésentation de soutenance PFE
présentation de soutenance PFE
 
Méthodes agiles & Scrum
Méthodes agiles & ScrumMéthodes agiles & Scrum
Méthodes agiles & Scrum
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: Scrum
 
MÃthode-agile-SCRUM.pptx
MÃthode-agile-SCRUM.pptxMÃthode-agile-SCRUM.pptx
MÃthode-agile-SCRUM.pptx
 
Scrum Guide
Scrum GuideScrum Guide
Scrum Guide
 
Formation Professional Scrum Master I
Formation Professional Scrum Master IFormation Professional Scrum Master I
Formation Professional Scrum Master I
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XP
 
Introduction à Scrum
Introduction à ScrumIntroduction à Scrum
Introduction à Scrum
 
Methodes agile
Methodes agileMethodes agile
Methodes agile
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: Scrum
 
Présentation de l’agilité
Présentation de l’agilitéPrésentation de l’agilité
Présentation de l’agilité
 
Gestion de projets agiles avec scrum
Gestion de projets agiles avec scrumGestion de projets agiles avec scrum
Gestion de projets agiles avec scrum
 
Rapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilel
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
Méthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XPMéthodes Agiles - La Méthode XP
Méthodes Agiles - La Méthode XP
 
Soutenance de fin d’étude promotion srs 2012
Soutenance de fin d’étude promotion srs 2012Soutenance de fin d’étude promotion srs 2012
Soutenance de fin d’étude promotion srs 2012
 
Methodes agiles
Methodes agilesMethodes agiles
Methodes agiles
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 

Ähnlich wie Présentation des principes Scrum

Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Dominic Danis
 
Le scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheurLe scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheursebastien_fournel
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmseagnes_crepet
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de ScrumPyxis Technologies
 
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)Taoufik Fekhar
 
Faire de l'agile versus "Etre" agile pour les ESN
Faire de l'agile versus "Etre" agile pour les ESNFaire de l'agile versus "Etre" agile pour les ESN
Faire de l'agile versus "Etre" agile pour les ESNErnst Perpignand
 
Scrum - presentation du role de scrum master
Scrum -  presentation du role de scrum masterScrum -  presentation du role de scrum master
Scrum - presentation du role de scrum masterFrançois-Xavier BRAVO
 
Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013agnes_crepet
 
Du Manifeste Agile à Scrum
Du Manifeste Agile à ScrumDu Manifeste Agile à Scrum
Du Manifeste Agile à ScrumXavier Warzee
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_finalagnes_crepet
 
Scrum 2020 : concepts et principes
Scrum 2020 : concepts et principesScrum 2020 : concepts et principes
Scrum 2020 : concepts et principesMICHRAFY MUSTAFA
 
Agilité et la gestion du changement mboisvert - 15 octobre 2013
Agilité et la gestion du changement   mboisvert - 15 octobre 2013Agilité et la gestion du changement   mboisvert - 15 octobre 2013
Agilité et la gestion du changement mboisvert - 15 octobre 2013Pyxis Technologies
 
Module 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptxModule 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptxtestuser715939
 

Ähnlich wie Présentation des principes Scrum (20)

Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010
 
Le scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheurLe scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheur
 
Corescrum fr-v1.1
Corescrum fr-v1.1Corescrum fr-v1.1
Corescrum fr-v1.1
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmse
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
 
Méthodes agile
Méthodes agileMéthodes agile
Méthodes agile
 
Les pratiques Scrum
Les pratiques ScrumLes pratiques Scrum
Les pratiques Scrum
 
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
Agile/Scrum Workshop @ ESI (Breaking Science Day 2018)
 
Faire de l'agile versus "Etre" agile pour les ESN
Faire de l'agile versus "Etre" agile pour les ESNFaire de l'agile versus "Etre" agile pour les ESN
Faire de l'agile versus "Etre" agile pour les ESN
 
Agilite Scrum
Agilite Scrum Agilite Scrum
Agilite Scrum
 
Initiation Scrum
Initiation ScrumInitiation Scrum
Initiation Scrum
 
Scrum - presentation du role de scrum master
Scrum -  presentation du role de scrum masterScrum -  presentation du role de scrum master
Scrum - presentation du role de scrum master
 
Atam2014 manager agile
Atam2014 manager agileAtam2014 manager agile
Atam2014 manager agile
 
Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
 
Du Manifeste Agile à Scrum
Du Manifeste Agile à ScrumDu Manifeste Agile à Scrum
Du Manifeste Agile à Scrum
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Scrum 2020 : concepts et principes
Scrum 2020 : concepts et principesScrum 2020 : concepts et principes
Scrum 2020 : concepts et principes
 
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise AgileBrochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
 
Agilité et la gestion du changement mboisvert - 15 octobre 2013
Agilité et la gestion du changement   mboisvert - 15 octobre 2013Agilité et la gestion du changement   mboisvert - 15 octobre 2013
Agilité et la gestion du changement mboisvert - 15 octobre 2013
 
Module 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptxModule 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptx
 

Présentation des principes Scrum

  • 1. Sylvain Gallioz et Fabrice Thomas 17/06/2014 21/07/2014 1Mastère spécialisé : Management par Projets
  • 2.  Etat des lieux  Qu’est-ce que l’agilité ?  Scrum  Rôles  Artefacts  Certification  Annexes 21/07/2014 2 S. Gallioz et F. Thomas, 2014
  • 4. Taux de succès des projets informatiques en 2009 de 32%  Source : enquête Standish Group sur 8000 projets Etat des lieux 21/07/2014 4 Fonctionnalités utilisées d’un SI en % (source: Standish Group Study reported at XP2002 by Jim Johnsonn, chairman) Peu de fonctionnalités développées réellement utilisées  45% de fonctionnalités jamais utilisées S. Gallioz et F. Thomas, 2014
  • 5. Etat des lieux 21/07/2014 5 La stabilité est la norme • Les prévisions précises sont possibles • L’important c’est de maintenir le cap • Plus de rigueur et de contrôle augmentent le niveau de sécurité et la probabilité de réussir Le changement est la norme • L’incertitude et la complexité taxent la précision de nos prévisions • Il faut saisir les opportunités et encourager le changement • Plus de flexibilité augmente le niveau d’adaptation aux changements et la probabilité de réussir et de se dépasser S. Gallioz et F. Thomas, 2014
  • 6.  Le périmètre fonctionnel du projet n’est pas très clair et risque de bouger au cours du projet  Il y a de forts risques de ne pas réussir facilement à répondre au besoin du client, et il peut être salutaire de valider régulièrement avec le client ce qui est réalisé par l’équipe  Il y a de forts risques techniques et il peut être salutaire d’avoir la capacité de traiter ces risques techniques par une validation technique régulière du produit  Il est nécessaire de livrer très rapidement une première version, quitte à livrer une première version ne contenant que les fonctionnalités primordiales 21/07/2014 6 S. Gallioz et F. Thomas, 2014
  • 8. Qu’est-ce que l’agilité ? Personnes et interactions plutôt que processus et outils Logiciel fonctionnel plutôt que documentation complète Collaboration avec le client plutôt que négociation de contrat Réagir au changement plutôt que suivre un plan Le Manifeste agile est un texte rédigé par 17 experts du développement d'applications informatiques - Février 2001 S. Gallioz et F. Thomas, 2014 8
  • 9.  Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.  Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.  Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.  Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.  Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.  La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.  Un logiciel opérationnel est la principale mesure d’avancement.  Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.  Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité.  La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.  Les meilleures architectures, spécifications et conceptions émergent d'équipes auto- organisées.  À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. 21/07/2014 9S. Gallioz et F. Thomas, 2014
  • 10. Qu’est-ce que l’agilité ? 21/07/2014 10 Valeur Métier (valeur pour l’utilisateur) Approche Agile Approche classique Temps Itérations (livraison régulière des nouvelles fonctionnalités réalisées) Fin élaboration Fin réalisation Fin recette DéploiementDéploiement Déploiement Déploiement Déploiement S. Gallioz et F. Thomas, 2014
  • 12. Scrum 21/07/2014 12 State of Agile Survey (VersionOne) - 2014 S. Gallioz et F. Thomas, 2014
  • 13. Ken Schwaber et Jeff Sutherland sont les concepteurs de Scrum Scrum 21/07/2014 13 Scrum est un cadre de travail qui a été employé pour gérer le développement de produit complexe depuis le début des années 1990 Scrum n’est pas une procédure ou une technique pour construire des produits L’équipe et Le rôle des membres, Les évènements, Les artéfacts, Les règles. Le Cadre Scrum Chaque élément du cadre répond à un but spécifique et est essentiel à la réussite et à l'utilisation de Scrum. S. Gallioz et F. Thomas, 2014
  • 14. Transparence Inspection Adaptation 21/07/2014 14 Approche Itérative & Incrémentale Théorie de contrôle des processus empiriques 1 2 3 S. Gallioz et F. Thomas, 2014
  • 15. Scrum 21/07/2014 15 5 Evénements 3 artéfacts 3 rôles Product Owner Scrum Master Equipe de réalisation Backlog du produit Backlog du Sprint Incrément Sprint Planification du Sprint Daily Scrum Revue du sprint Rétrospective de Sprint S. Gallioz et F. Thomas, 2014
  • 16. Scrum 21/07/2014 16 Planification Revue Sprint Rétrospective Un but unique et commun : Produire au plus tôt un maximum de valeur métier par incréments de grande qualité et industrialisés S. Gallioz et F. Thomas, 2014
  • 18. Scrum 21/07/2014 18 Sur quel type de contrôle de processus est basé Scrum ? Hybride Définie Complexe EmpiriqueA B C D
  • 19. Scrum 21/07/2014 19 Quel sont les 3 piliers de la théorie du contrôle empirique de processus ? Planification, de démonstration, rétrospective Le respect des personnes, Kaizen, élimination du gaspillage L'inspection, la transparence, l'adaptation Transparence, l'élimination des déchets, KaizenA B C D
  • 21. Rôles 21/07/2014 21 Une équipe auto-organisée et pluridisciplinaire Flexibilité - Créativité - Productivité • Exprimer clairement les éléments du backlog, • Hiérarchiser les éléments en fonction des objectifs, • S’assurer de la valeur du travail, • Rendre visible le backlog, • S’assurer que l’équipe comprend les éléments du backlog Product Owner (PO) est chargé de maximiser la valeur du produit et du travail de l’équipe L’équipe réalise les incréments du produits • Elle est auto-organisée. Elle est autonome dans la réalisation de l’incrément • Tous les membres ont le titre de développeurs (indépendamment du travail à réaliser) • La responsabilité appartient à l’équipe dans son ensemble (solidarité) • Il n’existe pas de sous décomposition • Taille de l’équipe entre 4 et 9 développeurs Scrum Master (SM) est responsable de la compréhension et de l’application de Scrum • Il est au service du Product Owner • Il est au service de l’équipe de réalisation • Il est au service de l’organisation S. Gallioz et F. Thomas, 2014
  • 22. Rôles 21/07/2014 22 Au service du Product Owner Au service de l’équipe Au service de l’organisation • Trouve des techniques pour la gestion efficace du backlog, • Communique clairement la vision, les objectifs et les éléments du backlog à l’équipe, • Enseigne à l’équipe de développement comment créer des éléments backlog, • Comprend la planification du produit , • Comprend et pratique l’agilité, • Facilite des l’événements à la demande ou quand c’est nécessaire. • Aide l’équipe à apprendre comment s’auto-organiser, • Enseigne et mène l’équipe à livrer des produits de haute valeur, • Protège l’équipe des obstacles pouvant nuire à l’équipe, • Facilite des l’événements à la demande ou quand c’est nécessaire, • Accompagne l’équipe dans les événements organisationnels où Scrum n’est pas encore adopté et compris. • Accompagne l’organisation dans ses effort d’adoption de Scrum, • Planifie des mises en œuvres de Scrum au sein de l’organisation, • Aide à la compréhension Scrum au travers de l’organisation, • Provoque le changement qui est susceptible d’accroitre la productivité de l’équipe, • Travaille avec d’autre Scrum Master dans le but d’améliorer l’efficacité les pratiques de Scrum dans l’organisation. S. Gallioz et F. Thomas, 2014
  • 24. Scrum 21/07/2014 24 Qui est responsable de l'enregistrement des estimations de travail pendant un Sprint ? Le Scrum Master l'équipe de développement Le plus jeune membre de l'équipe Le Product OwnerA B C D
  • 26.  Un backlog est une liste de fonctionnalités (Story) de plusieurs types : user, technical, defect  Il existe deux backlogs :  Product Backlog : il recense les stories du projet, priorisées en fonction de la valeur métier que rapporte  Sprint Backlog : à partir des stories sélectionnées et détaillées par le PO, les développeurs identifient les tâches unitaires qui les composent  Le Product Backlog est géré par le Product Owner  Le Sprint Backlog est géré :  par le Product Owner pour les aspects fonctionnels  par l’équipe pour les aspects techniques (découpage en tâches)  L’incrément est la somme de toutes les fonctionnalités terminées pendant un sprint. Il s’additionne aux autres incréments Artefacts 21/07/2014 26 S. Gallioz et F. Thomas, 2014
  • 27. Artefacts 21/07/2014 27 N° Priorité Item Critère d’acceptation Estimation Release Sprint Statut 42 3 En tant qu’acheteur en ligne, je veux pouvoir supprimer un article de mon panier L’article est supprimé du panier quand je clique sur « Supprimer ». Je peux voir que l’article ne fait plus parti de mon panier 5 2 Terminé … … Priorité Haute Priorité Basse Les fonctions peuvent être ajoutées, repriorisées et supprimées à tout moment. La préparation est une activité à temps partiel (pendant le Sprint) et elle ne doit pas prendre plus de 10% de la capacité de l’équipe. S. Gallioz et F. Thomas, 2014
  • 28.
  • 29. 21/07/2014 29 Sprint Revue Rétrospective Planification Mêlée quotidienne Réalisation Backlog Incrément Sprint MêléePlanning Revue Rétro. S. Gallioz et F. Thomas, 2014
  • 30.  Bloc de temps : de 1 semaine à 4 semaines  A la fin du bloc : Incrément produit « Terminé »  Durée constante  Contenu : ◦ Réunion de planification, ◦ Mêlées quotidiennes, ◦ Période de réalisation, ◦ Revue de Sprint, ◦ Rétrospective.  Pendant le Sprint : ◦ Aucun changement : équipe, objectifs et qualité, ◦ Le contenu peut être renégocié entre PO et l’équipe  Annulation (objectif du sprint obsolète) : Responsabilité du PO 21/07/2014 30S. Gallioz et F. Thomas, 2014
  • 31.  Toute l’équipe Scrum  Réunion de 8h pour un sprint d’un mois  Deux parties : ◦ Qu’est ce qui sera livré dans l’incrément résultant du prochain Sprint ? ◦ Comment le travail nécessaire pour réaliser l’incrément sera-t-il accompli ?  Définir des tâches d’une journée ou moins 21/07/2014 31S. Gallioz et F. Thomas, 2014
  • 32.  Bloc de temps : 15 minutes  Objectif : Synchroniser et planifier la journée  Tous les jours et uniquement l’équipe de réalisation  A la même heure et au même endroit  Questions à traiter par chacun des membres : ◦ Ce qu’il a réalisé depuis la dernière réunion ◦ Ce qu’il réalisera avant la prochaine réunion ◦ Les difficultés qu’il rencontre 21/07/2014 32 Le Scrum Master • S’assure que la mêlée a lieu • Aider l’équipe sur la tenue de la mêlée • Veille à l’application des règles S. Gallioz et F. Thomas, 2014
  • 33.  Bloc de temps : 4h pour un sprint de 4 semaines  Objectif : inspecter l’incrément du produit et adapter le backlog si nécessaire.  Qui ? : Equipe Scrum et partie prenantes  Points abordés : ◦ Le PO identifie ce qui a été « terminé » et le reste ◦ L’Equipe de réalisation discute de ce qui s’est bien déroulé et des problèmes rencontrés et comment ils ont été résolus ◦ L’équipe de réalisation démontre le travail et répond aux questions ◦ Le PO discute du backlog produit et détermine des dates probable d’achèvement ◦ L’ensemble du groupe convient de ce qu’il faut faire pour la suite 21/07/2014 33S. Gallioz et F. Thomas, 2014
  • 34.  Bloc de temps : 3h pour un sprint de 4 semaines  Objectif : inspecter et créer un plan d’améliorations  Quand : Après la revue de sprint  Points abordés : ◦ Inspecter la manière dont le dernier sprint s’est déroulé en ce qui concerne les personnes, les relations, les processus et les outils, ◦ Identifier et ordonner les éléments majeurs qui se sont bien déroulés et les améliorations potentielles ◦ Créer un plan pour améliorer les processus de travail de l’équipe Scrum 21/07/2014 34S. Gallioz et F. Thomas, 2014
  • 36. Scrum 21/07/2014 36 Quelle est la principale raison pour le Scrum Master d'être à la mêlée quotidienne? Pour s'assurer que chaque membre de l'équipe répond aux trois questions dans le bon ordre de l'équipe. Pour écrire toutes les modifications apportées à l'arriéré Sprint, y compris l'ajout de nouveaux éléments, et le suivi des progrès sur le traitement non sélectif. Pour recueillir l'état ​​et la progression à signaler à la direction. Il n'a pas à être là, il doit seulement s’assurer que l'équipe de développement a une mêlée quotidienne A B C D
  • 37. Scrum 21/07/2014 37 Pourquoi le Scrum quotidien se déroule au même moment et au même endroit ? La cohérence de réduire la complexité et les frais généraux. Le Product Owner l'exige Les salles sont difficiles à réserver et cela permet de les réserver à l'avance L'endroit peut être nomméA B C D
  • 38. Scrum 21/07/2014 38 Quand commence le prochain Sprint ? Immédiatement après la prochaine planification de sprint Lundi prochain Immédiatement après la conclusion du précédent Sprint Lorsque le Product Owner est prêtA B C D
  • 39. 21/07/2014 39 Sprint 3 MêléePlanning Revue Rétro. Sprint 3Sprint 2Sprint 1 Sprint 4 Sprint 5 Incrément Incrément Incrément Incrément Backlog Produit Backlog Produit Backlog Produit Backlog Produit Backlog Produit Sprint Backlog Feedback Inspiré du guide : The scrum master training manual - MP Management Plaza S. Gallioz et F. Thomas, 2014
  • 40. 21/07/2014 40  Nombre de questions : 80  Temps : 60 minutes  Ou : En ligne sur le site Srcum.org  Coût : 100 $  Condition d’obtention : 85 % de bonnes réponses
  • 42.  Planning Poker  Le Feeling Board  User Story  Story Board  Burndown Chart  Risk Board  Maturité Scrum 21/07/2014 42S. Gallioz et F. Thomas, 2014
  • 43.  Elle est déterminée démocratiquement par l’équipe pendant une séance de « planning poker »  Elle reste une estimation 21/07/2014 43 • Un jeu de carte est remis aux participants • L’équipe définit un étalon (story pour laquelle l’équipe définit en commun une valeur arbitraire) • Le PO présente une nouvelle story • Les membres interrogent le PO pour comprendre la story • Chaque participant choisit qui correspond le mieux selon lui à l’estimation • Tous les participants dévoilent en même temps leurs cartes et discutent des différences • A la suite, le groupe ré-estime la story jusqu’à trouver un accord • Le PO passe à la story suivante … S. Gallioz et F. Thomas, 2014
  • 44.  Une façon simple et efficace de savoir si l’équipe va bien  Un tableau au mur, avec une case pour chaque jour du sprint  Chaque soir, chaque membre de l’équipe met une gommette dans la case de la journée :  Gommette verte : j’ai passé une bonne journée  Gommette orange journée moyenne  Gommette rouge : journée pénible 21/07/2014 44 lundi mardi mercredi jeudi vendredi S. Gallioz et F. Thomas, 2014
  • 45. En tant que acheteur, je veux pouvoir supprimer un article de mon panier afin de corriger une erreur 21/07/2014 45 20 56 En tant qu’acheteur en ligne, je veux pouvoir supprimer un article de mon panier afin de corriger une erreur Release:2 id.:43 Qui Action Résultat Une priorité métier Macro : Must / Should / Could / Wish Micro : 1, 2, 3, 4, 5, 6 … Une valeur métier 10, 20, 30, … Une complexité technique 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 Critères d’acceptation : L’article est supprimé du panier quand je clique sur « Supprimer ». Je peux voir que l’article ne fait plus parti de mon panier S. Gallioz et F. Thomas, 2014
  • 46.  Techniques pour la collaboration :  Management visuel sur les murs, ateliers collaboratifs  Co-localisation des équipes de travail  Equipes dédiées 21/07/2014 46 Objectif Stories A faire En cours Fini Obstacles Ecrire l’objectif du sprint Tâches S. Gallioz et F. Thomas, 2014
  • 47.  Le burndown chart montre la taille de ce qui reste à faire dans le backlog, sprint après sprint ou jour après jour 21/07/2014 47 S. Gallioz et F. Thomas, 2014
  • 49. 21/07/2014 49S. Gallioz et F. Thomas, 2014
  • 50. 21/07/2014 50 Domaines Thèmes Détails OUI /NON Note thème Note Domaine L'équipe partage le même langage O L'équipe partage la même définition des termes N L'avancement du processus est visible O L'équipe passe en revue le Backlog et le plan du Sprint N L'équipe passe en revue l'état d'avancement en fonction de l'objectif à atteindre O les revues sont réalisées par une personne expérimentée et extérieur à l'équipe N Des actions sont prises si les processus ont besoins d'être ajustés O Des actions sont prises si le produit résultant sera inacceptable O Un et un seul Backlog par produit O Le PO le met à jour très régulièrement O Il est toujours bien rangé par priorité O Tout le monde s'en sert N Il comprend bien des stories (pas des tâches) O Les stories techniques sont dans le Backlog O Les bugs sont dans le Bakclog O Chaque Story a ses tests d'acceptation O Un et un seul plan par Sprint O Il est facilement visible O Il est mis à jour quotidiennement N Une tâche fait en moyenne un jour N Une tâche est liée à une Story O Le reste à faire est estimé par l'équipe O Il est mis à jour tous les jours O Il est affiché et visible O Il sert à décider sur l'objectif du Sprint O Il est mis à jour à chaque fin de Sprint O Il est affiché et visible N Il sert à décider sur l'objectif de la release O Backlog du produit Plan de Sprint Burndown de Sprint Burndown de release Artefacts 4,4 3,3 5,0 3,3 Principes 3 3,3 1,7 5 2 Transparence Inspection Adaptation S. Gallioz et F. Thomas, 2014
  • 51. Scrum : le guide pratique de la méthode agile la plus populaire – Claude Aubry (édition Dunod) Guide Scrum : https://www.scrum.org/Scrum-Guide 21/07/2014 51