Méthodes agiles

SCRUM

V. Deslandres © – Licence pro DEVOPS, IUT Lyon1

 2
Sommaire
¡ L’équipe de SCRUM, les rôles ----- 3

¡ Le cycle de SCRUM et les cérémonies ----- 5

¡ La vision --- 10

¡ La capture des exigences : construire le backlog Produit ----- 13

¡ Les User Stories : format, tests d’acceptation ----- 16

¡ Prioriser les US ---- 23

¡ Estimer les US ----- 29

¡ Management visuel ----- 35

(c) V. Deslandres, IUT Lyon

 3
SCRUM : les rôles

Porte la vision Produit, - Animateur

définit le backlog, donne - Permet à l’équipe d’avancer
les retours des users - Pas un chef, peut être SM
tournant

EQUIPE

Responsable du
développement
(c) V. Deslandres, IUT Lyon
 4

SCRUM : les rôles

¡ Product Owner (PO) : représentant du Client /

utilisateur
¡ Chargé de maximiser la valeur du produit et du
i pe 8 travail de l'équipe de développement
u
L’éq : max to ¡ Répond à toutes les questions sur le produit
R U M ; au
SC bres e
m é
me rganis ¡ Scrum Master (SM) : « protecteur » de l’équipe
o
¡ Animateur
¡ Permet à l’équipe d’avancer
¡ Pas un chef, peut être SM tournant

¡ Développeurs / DBA / graphistes / testeurs

(c) V. Deslandres, IUT Lyon

 5
Scrum – Cycle 1/5

1. Backlog produit (ou catalogue des besoins)

n Besoins priorisés par le product owner
n Besoins estimés par l’équipe, qui évoluent et sont affinés
5
La méthode Scrum
 6
Scrum – Cycle 2/5

2. Backlog de sprint
n Extrait du backlog produit

n Besoins éclatés en tâches, planification

6
La méthode Scrum
 7
Scrum – Cycle 3/5

3. Sprint
n Développement des fonctionnalités du backlog de sprint

n Aucune modification du backlog de sprint possible

La méthode Scrum
 Scrum – Cycle 4/5 8

4. Mêlée quotidienne
n Point de contrôle quotidien de l’équipe

n Interventions régulées – 2 min. par personne

8
La méthode Scrum
 Scrum – Cycle 5/5 9

Vision du
Produit

5. Incrément logiciel : livré au product owner à la

fin du sprint.
9
La méthode Scrum
 10

ÉTAPE 0 : LA VISION

¡ Le cap : si vous ne savez pas où vous voulez aller, où irez-

vous?

¡ Sans vision, les retards sont pris en tout début de projet ;

l’équipe est alors hésitante, refusant de prendre le risque de
se fourvoyer dans une mauvaise direction…

¡ On peut adapter le cap en fonction du feedback

¡ Objectifs :
¡ situer ce produit dans l’organisation
¡ lui donner un sens (raison d’être du produit)

(c) V. Deslandres, IUT Lyon

 11

Qui fait quoi ? (RACI)

Définir la vision
Product Utilisateurs,
Développeurs
Owner Manager

Autorité X

Rédige X X

Conseille X

Est Informé X X

(c) V. Deslandres, IUT Lyon

 Caractéristiques Méthodes 12
Agiles
¡ Les itérations sont bornées dans le temps

¡ Les réunions sont bornées dans le temps

¡ Tout est borné !

¡ Et donc le coût est prévisible et a moins de

chance d’être dépassé

(c) V. Deslandres, IUT Lyon

 13

LA CAPTURE des EXIGENCES

(c) V. Deslandres, IUT Lyon

 14 Backlog de Produit ou Carnet
de Produit
¡ Contient des Features déclinées en User Stories

¡ Au max 20 US pour respecter le vœux agile

¡ « peu de stock »
a t u re»
« Fe ¡ Principe : « être précis à court terme, grossier à
VOC
: s t i q ue long terme »
té ri
carac t
i
Produ » : grosse ¡ Attention : ne pas être précis pour le long terme
« Epic ne signifie pas “inutile” !
story Story » : ¡ Cela donne “le cap” de la release
U se r
«
in ¡ On ne les oubliera pas plus tard
beso ntaire
e
é lé m : t âche ¡ Permet d’estimer le « reste à faire »
»
« Task ue pour
iq
techn US
la
faire
(c) V. Deslandres, IUT Lyon
15
Brainstroming
¡ Le client définit le contenu fonctionnel qu'il
souhaite voir implémenté dans le produit
¡ En XP : « scénarios client » sous la forme d’histoires
¡ En SCRUM : features et user stories

¡ Par exemple, pour un logiciel de gestion de

carnet d'adresses, scénarios :
¡ "Je rentre un nom ou prénom, et le logiciel affiche la
liste de toutes les personnes qui possèdent ce nom
ou ce prénom »
¡ "Je peux exporter mon carnet d'adresses au format
HTML »

¡ Granularité ? Une US doit pouvoir être

complètement implémentée en une itération

(c) V. Deslandres, IUT Lyon

 16 Format des User Stories
En tant que… (rôle)
Je peux …. (tâche)
Afin de …. (but)

• Les stories sont discutées

• Elles représenteront l’unité de temps pour la

planification des itérations
Priorité
800 (valeur
En tant que Pilote, Métier)

je peux régler le commutateur en

mode " niveau horizontal »

afin de maintenir les ailes à

l'horizontal et Estimation
l'avion sur sa trajectoire initiale 50
Effort

(c) V. Deslandres, IUT Lyon

 17

Exemples de User Story

ETQ Assureur, je peux
récupérer des contrats
d’assurance sur le site web
afin de vérifier leur précision
et leur légalité

ETQ Assureur, je peux

Source : chaîne YouTube:
BA-Experts
(Business Analysis)
chercher les infos du permis
de conduire du candidat
chez la préfecture
concernée afin de vérifier
leur exactitude

(c) V. Deslandres, IUT Lyon

 18 Rester dans le périmètre du
projet – garder le cap sur la
vision

(c) V. Deslandres, IUT Lyon

 19
3 types de Story
¡ User story (US)
¡ besoin ou solution exprimé par le PO

¡ Story technique
¡ Ex.: tester le framework Guava pour la gestion du cache, tester
l’algo de cryptologie des mots de passe
¡ Rarement exprimée par le PO ! Mais déduite d’une US
¡ « Une user story est une invitation à avoir une
conversation avec son client sur un sujet particulier »
¡ Default Story
¡ soit un défaut a été constaté
¡ soit l’évolution d’une story initiale
¡ Soit proposée par l’équipe à l’issue d’une itération

Dans tous les cas : simplicité et concision

(c) V. Deslandres, IUT Lyon
 20
Principe INVEST
Une bonne story respecte le principe :

I - Independant
N - Negociable : discutée avec le PO (pas budgétisée ! )
V - Valuable (apporte de la valeur à l’utilisateur)
E - Estimable ETQ technicien,
je veux envoyer une
S - Small facture via mon
iPhone,
T - Testable
pour que le client la
reçoive en moins de 4h

(c) V. Deslandres, IUT Lyon

 Tests d’Acceptation 21

¡ Mentionnés au dos des US

¡ C’est l’occasion de discuter des détails

¡ Identifier les tâches associées à la US

¡ Conditions de vérification logicielle de la

US

¡ Soit pour la user story suivante :

En tant que membre du site,

je peux annuler ma réservation d’hôtel
Afin de tenir compte d’imprévus dans mon
voyage
Product Owner

(c) V. Deslandres, IUT Lyon

 Tests d’Acceptation : 22

illustration En tant que membre du site,

je peux annuler ma réservation d’hôtel
Afin de tenir compte d’imprévus dans mon voyage

q Vérifier qu’un email d’annulation est

envoyé au voyageur et à l’hôtel

q Vérifier que si elle a lieu au moins 15 j.

avant la date prévue, pas de charge
imputée au voyageur

q Vérifier qu’un premium peut annuler

n’importe quand sans charge suppl.

q Vérifier qu’un non premium paie 10% du

Product Owner montant de la résa si annulation moins de
15 j. avant la date prévue
(c) V. Deslandres, IUT Lyon
 23

LA CAPTURE des EXIGENCES

PO

PRIORISER
Comment identifier ce qui est important ?

(c) V. Deslandres, IUT Lyon

 24
Objectif 1 : PRIORISER
¡ Comment classer le backlog Produit en fonction
de ce qui est le plus important pour les
utilisateurs, pour l’organisation ?

¡ Valeur Métier (business value)

¡ C’est la partie impact (« afin de ») des US !

¡ Priorisation des features effectuée par le PO en

Scrum, par le « Client » en XP

¡ Différentes méthodes :
¡ Questionnaire de KANO (marketing)
¡ (déjà vues : MoSCWo, Matrice Effort / Valeur)

(c) V. Deslandres, IUT Lyon

 25 Qu’est-ce qui définit la
valeur Métier ?
Ex. : performance,
niveau de service utile
utilisa
désiré
ble
VALEU
R
trouv acces
able sible
crédi
ble
Ex. : langue
Ex. : pour la confiance

User Experience - Peter Morville

(c) V. Deslandres, IUT Lyon
26
Prioriser avec MoSCoW
¡ On prépare 4 fiches :

O ULD
SC H
T
MUS

¡ En équipe, on place les Won’t

items du Backlog Produit sur
D
les fiches COUL

¡ Max 8 par fiche

¡ Les items MUST = vont couvrir

en général 1 à 1,5 sprints
(c) V. Deslandres, IUT Lyon
 27

Illustration : café
¡ Vous entrez dans un bar et demandez un
expresso

¡ Donner des illustrations pour :

¡ Fonctionnalité normale
¡ Insatisfaction
¡ Heureuse surprise

(c) V. Deslandres, IUT Lyon

 28

Quantifier la valeur Client

¡ Une fois la liste priorisée des user stories, on
attribue une valeur globale au projet (par ex. 100
ou 500) et on répartit les valeurs aux US

¡ Échelle cohérente avec les priorités

50 30 2 20 15 50

25
0
15 15 240

200

On inscrit la
60 valeur dans
un angle

(c) V. Deslandres, IUT Lyon

 29

LA CAPTURE des EXIGENCES

Définir l’effort
Les dév +
nécessaire
graphistes + Comment estimer le coût de réalisation ?
testeurs

(c) V. Deslandres, IUT Lyon

 30
Estimation de l’effort - sans point
¡ Certains préfèrent attribuer un niveau de difficulté
aux tâches et US
¡ Plus souple
¡ Plus facile de comparer un tâche par rapport à
une autre que de lui donner une valeur d’effort

¡ Méthode du Tshirt Size : on choisit les catégories

XS, S, M, L, XL
¡ En général, M = entre 1 et 3 jours
¡ S = ½ à 1 jour
¡ Un optimiste va dire M (en pensant 1)
¡ un pessimiste va dire M (en pensant 2,5 ou 3)

(c) V. Deslandres, IUT Lyon

 31
Méthode Planning Poker
¡ Une fois le backlog Produit établi avec le PO, l’équipe va
quantifier l’effort nécessaire pour le réaliser

¡ Fonctionne sur un système de

points (pas de jours ni heure), par
ex. :
¡ 1, 2, 3, 5, 8, 13, 21, etc (dure à
réaliser)
¡ Choisir une User Story étalon,
connue et maîtrisée, et lui affecter
la valeur d’effort qui va bien
¡ Ex. : développer l’interface de
saisie de commande Client Chacun
Discussions
estimé à 3 pts d’effort donne son
avec le PO
¡ Mesure de l’effort « relatif » avis
¡ l’interface de saisie des infos
Client = 2x plus long, disons 8 pts
avec contrôles
(c) V. Deslandres, IUT Lyon
 32

Compléter les US
¡ Même chose, on inscrit l’effort sur un autre angle
de la carte représentant la User Story

Valeur
Effort

50 30 2 20 15 50
5 3 2 8 13 5
0
15 15
25 0
5 8
2

(c) V. Deslandres, IUT Lyon

 33 Scrum – Backlog Produit
Priorités Effort « Carnet de produit »
Client requis
¡ Défini par le product owner
¡ Discuté avec l’équipe

Lots
¡ Répartition en releases et en
sprints.
itérations

Source : http://fr.wikipedia.org

La méthode Scrum
 34

Un ex. de backlog produit

Priority Backlog item Acceptance Criteria Estimate

1 En tant qu’internaute, je peux

réserver l’hôtel en ligne
• Un email de confirmation est
envoyé
3
• Réservation doit être faite au
min 24h avant date

2 En tant que membre, je peux

annuler une réservation
• Un email de confirmation est
envoyé
5
• Ne peut être annulée qu’au
moins 15 jours avant la date

3 En tant que membre, je peux

modifier les dates d’une
… 3
réservation

4 En tant que Resp. Hotel, je

peux voir les réservations à
… 8
venir

5 Améliorer la gestion des

exceptions
Pas de msg “Exception …”
même en cas de pb
15
(c) V. Deslandres, IUT Lyon
 35

Management visuel

Le task board
Comment rapidement voir l’avancement ?

(c) V. Deslandres, IUT Lyon

 36
Task Board SCRUM

¡ Tableau de suivi de l’avancement

¡ On y place les US (post-it) dans les colonnes KANBAN :
¡ A FAIRE
¡ EN COURS on peut y ajouter des US supplémentaires
¡ À TESTER (un tas « US non plannifiées »)
¡ FINIES

(c) V. Deslandres, IUT Lyon

 37
Un ex. de Task Board – Jour 1
NON EN
Priorité TRAITE COURS
décroissante

Effort à fournir

Temps

D’après Erik Kniberg, Scrum & XP from the Trenches Stories

identifiées en
(c) V. Deslandres, IUT Lyon cours sprint
 38
Task Board – Jour n
NON EN
TRAITE COURS

tâches

D’après Erik Kniberg, Scrum & XP from the Trenches

(c) V. Deslandres, IUT Lyon

 Burndown Chart 39
Total des points d’effort
nécessaires pour
de sprint
l’itération
Droite théorique de
progression linéaire

Avance

Retard

Dates de fin
d’itération

(c) V. Deslandres, IUT Lyon D’après Erik Kniberg, Scrum & XP from the Trenches