More Related Content Similar to Formation scrum v1.0 Similar to Formation scrum v1.0 (20) Formation scrum v1.01. 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 74
mamiour@softenia-solutions.com Certifié Scrum Master : CSM
www.softenia-solutions.com
Certifié Product 0wner : CSPO
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. 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. 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. 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 Agile
Agile • 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. 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. 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 qu'une documentation exhaustive
3 Collaboration avec le client
plus que la négociation d'un 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. 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. 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. 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. 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 Scrum
Origines 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. Scrum : Généralités
Scrum : 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és
Un Framework de gestion de projet Agile • Caractéristiques
Composants du Framework
Règles
Equipe
Framework Scrum Artefacts
Scrum
Evénements
13. Scrum : Généralités
Processus 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és
Processus Incrémental • Caractéristiques
Chaque Sprint produit un logiciel partiel « Fini »
potentiellement exploitable : Incrément
Testé
Validé
Livrable en production
14. Scrum : Généralités
Processus 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és
Orienté valeur métier Caractéristiques
On fixe
Délai Coûts
On vise à maximiser Périmètre
15. Scrum : Généralités
Cinq 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és
Cycle 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. Scrum : Généralités
Dé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. Les règles
Les 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ègles
Exemples 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. Les règles
Conseil
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. L’équipe Scrum
L’é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 Scrum
Les rôles Scrum • Les rôles
Formalisent les responsabilités dans le processus Scrum
Ce ne sont pas des positions dans l'entreprise
Permettent à chacun de bien connaître ses responsabilités
dans le projet
© 2012 SOFTENIA Solutions 38
20. L’équipe Scrum
Les 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 Scrum
Product 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. L’équipe Scrum
Product 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 Scrum
Le 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 d'autorité hiérarchique
Interface avec le management
© 2012 SOFTENIA Solutions 42
22. Le Framework Scrum
Le 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 Scrum
Le 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. L’équipe Scrum
Le 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 Scrum
L’é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. L’équipe Scrum
L’é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 d'ingé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 Scrum
Les 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. L’équipe Scrum
L’é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 Scrum
Constitution de l’équipe Scrum • Constitution de l’équipe
Parties prenantes
ScrumMaster Product Owner
SM
Equipe de
développement
© 2012 SOFTENIA Solutions 50
26. L’équipe Scrum
Les 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 Scrum
Les valeurs de l’équipe • Constitution de l’équipe
Partagent les mêmes valeurs
Engagement
Courage
Respect
Transparence
Jouer collectif
© 2012 SOFTENIA Solutions 52
27. L’équipe Scrum
Les 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 Scrum
Facteurs 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. L’équipe Scrum
Facteurs 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 Scrum
Facteurs 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. L’équipe Scrum
Multidisciplinarité : 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 Scrum
Multidisciplinarité : 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. L’équipe Scrum
Multidisciplinarité : 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 Scrum
Multidisciplinarité : 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. Les rôles
Atelier : 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. Les Artefact Scrum
Les 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
L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles
Backlog d'amélioration
Artefacts du management visuel
Radiateur d'information
© 2012 SOFTENIA Solutions 63
Les Artefact Scrum
Les 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
L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles
Backlog d'amélioration
Artefacts du management visuel
Radiateur d'information
© 2012 SOFTENIA Solutions 64
33. Les Artefacts Scrum
Dé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 d'un travail
Pourquoi?
Eviter le syndrome de 90% fini
Fini = 100% Fini
© 2012 SOFTENIA Solutions 65
Les Artefacts
Quels 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. Les Artefact Scrum
Les 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
L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles
Backlog d'amélioration
Artefacts du management visuel
Radiateur d'information
© 2012 SOFTENIA Solutions 67
Artefacts Scrum
Backlog 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. Artefacts
Caracté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
Artefacts
Niveaux de granularité • Backlog du Produit
(User) Stories
Epics
Thèmes
© 2012 SOFTENIA Solutions 70
36. Artefacts
Exemple de Backlog de produit • Backlog du Produit
© 2012 SOFTENIA Solutions 71
Artefacts
Elé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. Artefacts
Exemples 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
Artefacts
Caracté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. Artefacts
Structure des PBI • Eléments de Backlog de Produit :
PBI
Priorité
Description Valeur métier
PBI Taille
Etat
DoD
Tests
d’acceptation
Artefacts
Priorité 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. Artefacts
Description 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
Artefacts
Description 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. Artefacts Scrum
Description 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)
Artefacts
Tests d’acceptation des PBI • Eléments de Backlog de Produit :
PBI
Le projet est piloté par les tests d’acceptation
Tests fonctionnels
Conditions d'acceptation
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. Artefacts
Valeur 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
Artefacts
Taille 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. Artefacts
DoD 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
Artefacts
Etat 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. Les Artefact Scrum
Les 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
L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles
Backlog d'amélioration
Artefacts du management visuel
Radiateur d'information
© 2012 SOFTENIA Solutions 85
Artefacts
L'incré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. Artefacts Scrum
Objectif 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 l'application
Responsabilité du PO
© 2012 SOFTENIA Solutions 87
Artefacts
Backlog 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. Artefacts
Backlog de Sprint : Exemple • Backlog de Sprint
© 2012 SOFTENIA Solutions 89
Artefacts Scrum
Les 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. Artefacts
Structure 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
Artefacts
Ré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. Artefacts
Duré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
Artefacts
Etat 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. Artefacts
Reste à 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
Artefacts
Vé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. Artefacts
Comment 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
Artefacts
Burndown de Produit • Burndown de Produit
Reste à faire pour finir la release
Mis à jour à chaque fin de Sprint
Permet d'ajuster les prévisions de livraison
Responsabilité du Product Owner
© 2012 SOFTENIA Solutions 98
50. Artefacts
Exemple de Burndown de produit • Burndown de Produit
Taille initiale du
Backlog du produit
Taille restante à la fin
de chaque Sprint
© 2012 SOFTENIA Solutions 99
Artefacts
Burndown 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. Artefacts
Backlog d'obstacles • Backlog d’obstacle
Liste d'obstacles identifiés par l'équipe Scrum
Géré par le ScrumMaster
© 2012 SOFTENIA Solutions 101
Artefacts
Backlog d'amélioration • Backlog d’amélioration
Liste des améliorations identifiées par l'équipe
Géré par le ScrumMaster
© 2012 SOFTENIA Solutions 102
52. Les Artefact Scrum
Les 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
L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles
Backlog d'amélioration
Artefacts du management visuel
Radiateur d'information
© 2012 SOFTENIA Solutions 103
Artefacts
Radiateur d'information • 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. Artefacts
Structure 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
Artefacts
Exemple • Radiateur d’information
© 2012 SOFTENIA Solutions 106
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énements
Les 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. Les événements
Les 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énements
Les é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. Les événements
Le Sprint • Le Sprint
Itération d'une 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énements
Dé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. Les événements
Quelques règles • Le Sprint
La durée n'est pas extensible
Pendant le Sprint
L'équipe ne doit pas changer
Le périmètre et d’objectif ne doivent pas changer
Si l'objectif devient obsolète
Le PO peut abandonner le Sprint
© 2012 SOFTENIA Solutions 113
Les événements
Planification 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. Les événements
Dé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énements
Capacité 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. Les événements
Capacité 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énements
Conseils • 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. Les événements
Conseils • 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énements
Quelques 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. Evénements
Atelier : 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énements
Mê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. Les événements
Dé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énements
Quelques 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. Les événements
Quelques précautions • Mêlée quotidienne
• Déroulement
Ce n'est pas une réunion pour résoudre les problèmes
Il ne s'agit 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énements
Atelier : 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. Les événements
Revue de Sprint • Revue de Sprint
Objectif
Effectuer une revue de l'incrément : PBI finis
Recueillir le feedback
Adapter le Backlog du produit si nécessaire
© 2012 SOFTENIA Solutions 127
Les événements
Revue 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. Les événements
Quelques 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énements
Quelques précautions • Revue de Sprint
• Déroulement
Moins d'une 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. Evénements
Atelier : 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énements
Rétrospective de Sprint • Rétrospective de Sprint
Objectif
Inspecter le processus
Améliorer le processus si nécessaire
© 2012 SOFTENIA Solutions 132
67. Les événements
Dé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énements
Quelques 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. Evénements
Atelier : 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énements
Pré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. 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 Scrum
L’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. Estimation Agile
Pourquoi 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 Agile
Difficulté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. Estimation Agile
Caracté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 Agile
Les niveaux d’estimation • Démarche d’estimation Agile
❶ Release ❷ Sprint ❸ Au quotidien
Quand ? Quand ? Quand ?
Phase de préparation Avant le début du Sprint Tous les jours
Quoi 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 produit
Pourquoi ? 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. Estimation Agile
La 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 Agile
L’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. Estimation Agile
L’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 Agile
Technique d’estimation relative : Planning • Estimation au niveau Release
Poker • 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. Estimation Agile
Planning 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 Agile
Planning 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. Estimation Agile
Technique d’estimation relative : La • Estimation au niveau Release
triangulation • 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 Agile
La 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
76. Estimation Agile
Triangulation : Exemple • Estimation au niveau Release
• Estimation relative
Estimer la taille des PBI suivants (Dice game)
N° PBI
1 Lancer un dé jusqu’à obtenir 1
2 Lancer un dé jusqu’à obtenir 1, 3 ou 5
3 Lancer deux dés jusqu’à obtenir 1 et 2
4 Lancer un dé jusqu’à obtenir 2, 4 ou 6
5 Lancer un dé jusqu’à obtenir plus de 4
6 Lancer deux dés jusqu’à obtenir plus de 6
7 Lancer deux dés jusqu’à obtenir un double 6
Estimation Agile
Estimer la vélocité de l’équipe • Estimation au niveau Release
• Estimer la vélocité
Objectif : Estimer la quantité de points
réalisable par l’équipe durant un Sprint
❶ Release
Quand ?
Phase de préparation
Quoi estimer ?
• Taille du Backlog du produit
• Vélocité de l’équipe de
développement
Pourquoi ?
• Evaluer le périmètre
fonctionnel réalisable
© 2012 SOFTENIA Solutions 152
77. Estimation Agile
Vélocité au début du projet • Estimation au niveau Release
• Estimer la vélocité
• Prendre le nombre d’heures disponibles de l’équipe sur un Sprint capacité
• Choisir un PBI de petite taille taille
• Décomposer en tâches
• Estimer collectivement la durée de chaque tâche en heures
• Calculer la somme des durées de toutes les tâches identifiées durée
• Appliquer la règle des trois pour obtenir la vélocité Vélocité
capacité * taille
Vélocité =
durée
© 2012 SOFTENIA Solutions 153
Estimation Agile
Vélocité au début du projet : Exemple Estimation au niveau Release
Données du projet
Capacité = 360 heures
PBI Taille • Tâche 1 : 15h
• Tâche 2: 10h
PBI 1 3 • Tâche 3 : 15h
PBI 2 8 ________________
durée= 40h
PBI 3 5
Quelle est la vélocité de l’équipe?
capacité * taille 360 * 3
Vélocité = = = 27 Pts
durée 40
© 2012 SOFTENIA Solutions 154