11. Backlog
2 backlogs :
« product backlog » liste les briques fonctionnelles
« Sprint backlog » détaille le contenu de la brique fonctionnelle en
cours de réalisation.
Optionnel : « release backlog »
Il recense les « user stories » (scénarios métiers) et
contient les spécifications agiles.
Les backlogs :
peuvent être utilisés partout, comme « ToDo list » améliorée
sont gérés / tenus par le Client
doivent être « parlant »
contiennent des expressions simples
(entre 10 et 20 pages pour la même chose => double de temps !)
TBM 2012-13 page 12
12. De plus en plus détaillé dans les spécifications
Une collection de user stories sur le même thème
TBM 2012-13 page 13
15. Qu’est ce qu’un User Story ? La règle des 3C
Card
(l’histoire est courte, 1 ou 2 phrases et peut être écrite sur une carte
8×13 cm, c’est mieux)
Les story sont traditionnellement écrits sur des cartes
Les cartes peuvent être annotées avec des estimations,
commentaires, etc.
Conversation
Les détails derrières les cartes peuvent être étudiés durant les
conversations avec le product owner
Les détails de l’histoire sont discutés par les équipes avec le métier,
les ergonomes
Confirmation
l’histoire est confirmée par des tests d’acceptation rédigés au même
moment que celle-ci, au dos de la carte) : c’est un élément majeur
La validation des tests confirme que les story ont été développés
correctement
TBM 2012-13 page 16
16. Exemples : Site de Voyage
je su
voya is un
je suis un veux
geur
, je
utilisateur, je phot
voir
les
veux réserver os d
e
l'hôt
un hôtel! el!
je suis
utilisat un Comme je suis un
voyageur fréquent,
je
eur, je
veux an veux faire une
nuler nouvelle réservation
une ! d’un voyage déjà
réserva effectué, pour gagn
er
tion! du temps!
TBM 2012-13 page 17
17. Une « User Story » contient :
La description d’une fonctionnalité unitaire selon ce type
En tant que <Rôle>
Je veux <Quelque chose>, les <conditions>
Pour <Raison>
les règles de gestion, exigences, cas particuliers
une priorité métier (identifiée par un numéro unique)
un chiffre indiquant la complexité technique de réalisation
les cas de test métier, donnés avant le développement,
avec
les données de test et les résultats attendus
On peut y trouver aussi
l’estimation du temps restant
optionnel : l’estimation du temps de réalisation (en heure)
TBM 2012-13 page 18
18. La priorité « métier »
On part toujours de la priorité métier déterminer sur
quoi on va commencer à travailler
Avant d’être au niveau unitaire (la User story) on peut
utiliser la priorisation MoSCoW :
Must have – fonctionnalité obligatoire
Should have – fonctionnalité qu’il serait très utile d’avoir
Could have – fonctionnalité qu’il serait intéressant d’avoir
Would like – fonctionnalité optionnelle sympathique
A partir du niveau User story, il faut mettre un N° de
priorité unique par user story de l’itération (1, 2, 3...).
Cela affiche clairement les priorités aux développeurs qui
ne doivent pas se demander par quelles tâches il faudrait
commencer (rôle du client)
TBM 2012-13 page 19
20. Une User Story peut avoir des détails …
Je suis un utilisateur, je veux annuler une réservation
Le client reçoit un remboursement complet ou partiel
Je rembourse directement sur son compte ou à l’intermédiaire
Comment doit fonctionner l’annulation d’une réservation ?
C’est le même principe pour tous les hôtels ?
je suis
utilisat un
Un voyageur fréquent peut-il annuler après eur, je
sa réservation veux an
nuler
une !
Une confirmation est adressée à l’utilisateur ?
réserva
tion!
Comment ?
TBM 2012-13 page 21
21. Les détails sont ajoutés en petites user stories
Je suis un
utilisateur
e peux
je suis premium, j
utilisat un
e
annuler un
à la
eur, je réservation
veux an nute!
dernière mi
nuler
une ! Je ne suis
pas un
réserva utilisateur
tion! premium, j
e peux
annuler ma
Je suis un réservation
24 hrs
partenaire, à l’avance!
n
j’adresse u
ur
courriel po
tes
annuler tou s!
mes réservation
TBM 2012-13 page 22
22. Les détails sont aussi une condition de satisfaction
Le product owner peut ajouter aux users stories des
conditions de satisfaction
Ce sont essentiellement des vérifications
ut
premium pe
je suis Vérifier e u’un rvation le jour !
q
ése
nuler un r aire
utilisat un supplément
an
harge
m ême sans c
eur, je ’un non-pr
emium
veux an Vérifieruqu ontant en cas
nuler paye 10% d
m
sa
le jour de
une ! d’annulatio
n
!
réserva réservation n un
tion! qu’il y a bie en cas
Vérifier ui est adressé
courriel q
n!
d’annulatio t bien
u e l'hôtel es
Vérifier lqensemble des
’
notifié de
!
annulations
TBM 2012-13 page 23
23. Rôle utilisateur
Élargir le périmètre de recherche à plus d’un utilisateur
Étudier les variations des utilisateurs :
Comment il utilise le logiciel
Pourquoi il utilise le logiciel
Est-il familiarisé avec les ordinateurs
Connaît-il le contexte métier de l’application
Utiliser intensivement la conception centrée sur
l’utilisateur
TBM 2012-13 page 24
25. Atelier d’écriture des User Stories
Participants :
product owner, utilisateurs, client, équipe, etc.
Réflexion pour générer les users stories
Le but est d’écrire le plus grand nombre de user stories-
Commencer avec les fonctions macro (EPIC)
travailler sur les détails pour les users stories qui seront développées
prochainement
Pas de gestion des priorités pour le moment
TBM 2012-13 page 26
26. Créer des Histoires
Je me nomme Jacques, je voudrais étudier le droit à la faculté. Mon
ami Marie m’a conseillé d’utiliser le formulaire d’inscription que la
faculté propose sur son site Internet. Elle me dit qu’une fois que
j’aurais déposé mon formulaire, un responsable de la faculté ira
l’étudier et éventuellement le valider, ainsi j’aurais rapidement une
réponse à mon inscription
Je traduis en user stories
Je suis un
Je suis un responsable, je
étudiant, je veux veux consulter les
remplir un dossier inscriptions en
d’inscription! attentes!
Je suis un
étudiant, je veux Je suis un
connaître le statut responsable, je
de mon dossier! veux valider/rejeter
les inscriptions!
TBM 2012-13 page 27
27. Commencer Macro (EPIC) et itérer Je suis un voyageu
r
fréquent, je veux
je suis un réserver un vol en
Voyageur fréquent, utilisant mes miles
je veux pouvoir !
contrôler mon
compte! je suis un voyageur
fréquent, je veux
faire une nouvelle
réservation d’un
Je suis un voyage déjà effectu
e!
Voyageur voyageur
Fréquent! fréquent, je veux
réserver un vol! Je suis un voyageu
r
fréquent, je veux
faire une mise à jou
r!
Je suis un
voyageur Je suis un voyageu
r
fréquent, je fréquent, je veux vo
ir
veux ...! si ma mise à jour à
bien été prise en
compte!
TBM 2012-13 page 28
28. INVEST (IR)!
dans une!
User Story!
TBM 2012-13 page 29
29. INVEST - mémo
Independent.
des autres User Stories, autant que possible pour faciliter son traitement
Negotiable.
discutée (c’est le second C, Conversation) dans les réunions d’estimation et
de planification du Sprint mais aussi durant ce dernier.
Valuable.
Elle est source de valeur pour le Client final ou l‘utilisateur.
Estimable.
par les équipes; estimation relative les unes p/p aux autres, en story points.
Simple (taille approprié)
Le plus souvent petite car susceptible d’être traitée (livrée et testée) par
l’équipe sur une seule itération de 2/3 semaines.
Testable.
dans le sens où les critères d’acceptation sont envisagés d’entrée (le
troisième C, Confirmation).
TBM 2012-13 page 30
31. POURQUOI DES USER STORIES ?
Mettre l’accent de l'écriture vers la communication orale
Si les spécification sont ALORS L’utilisateur aura ce qu’il
UX
écrites veut
FA
Au mieux il aura ce qu’il
a écrit
TBM 2012-13 page 32
32. Parce que les mots sont imprécis
L’entrée est constituée « J’ai écrit ce scénario, il y a
d'une soupe ou d’une un an et le studio n’a pas
salade avec du pain changé un mot »
• (Soupe ou salade) avec du pain « Le mot qu’ils n’ont pas
• (Soupe) ou salade avec du pain changé est en page 87 »
TBM 2012-13 page 33
33. Parce que
Les user stories sont compréhensibles
Les développeurs et les clients les comprennent
Les gens ont de meilleures capacités à les retenir s’ils sont organisés
sous forme de user stories
Support et encourage le développement itératif
Il est plus facile de partir avec un Epic et de les décomposer quand le
temps du développement approche
Les user stories ont les bonnes tailles pour les plannings
Les user stories supportent un développement
opportuniste
Nous concevons une solution de manière opportuniste en allant vers
une approche «du haut vers le bas» et «du bas vers le haut»
Les user stories supportent la conception participative
TBM 2012-13 page 34
35. Quelques définitions
Une release est la période de temps constituée de sprints
utilisée pour planifier à moyen terme
La vélocité est la mesure de la partie backlog de produit
qui est réalisé par une équipe pendant un sprint.
Les mesure de vélocité sont utilisées pour planifier
Un burndown chart est une représentation graphique du
reste à faire dans une période, actualisé aussi souvent
que possible et permettant de montrer la tendance.
Dans le cas d’un burndown chart de sprint la mise à jour est
quotidienne
Le burndown chart de la release est actualisé à la fin de chaque sprint
TBM 2012-13 page 36
36. La complexité
La complexité est une « note » indiquant la complexité
technique sur une échelle de valeur relative
(démocratiquement) pendant
une séance de « planning
poker », et non par une
métrique mécanique
n’est possible que sur un scope fonctionnel limité donc
mieux maitrisé
donne une évaluation plus fiable
aide le Client à faire son choix pour la répartition des user stories dans
le plan d’itérations
TBM 2012-13 page 37
37. Une métrique par niveau de détail
- Pas de relation métrique d’un niveau de granularité à un autre.
- La somme des complexités des taches d’une User story n’est pas égale
TBM 2012-13
au chiffre de la complexité de la User story page 38
39. Estimer la capacité de l’Equipe
La capacité de l’équipe est une prévision de ce que
l’équipe est capable de faire pendant un sprint.
Elle se base sur la vélocité, selon le principe de la météo
de la veille.
Si on a une nouvelle équipe
On simule la réunion de planification du premier sprint
Etudier quelques sotories des plus prioritaires
Décomposer en tâches
Estimer la durée des tâches
Exemple
3 stories étudiée, qui avait été estimées à 3,2 et 5 points. Les tâches
identifiées pour ces stories sont estimé à 30 H
L’équipe dispose de 300 H / sprint
Capacité = 300/30 x 10 soit 100 points
TBM 2012-13 page 40
45. Réunion de planification du sprint
Participants : PO, SM, Team
Le PO a tendance à s’éclipser après le début, il faut le retenir sinon il
doit revenir pour la fin
Quand
La veille ou le matin du 1er jour du sprint
Durée :
max 2 x n Heure (n: nb sem./sprint)
Ambiance:
Bonne, permissif
Lieu : Espace de travail
« ouvert »
Disposition favorisant la
communication
Tableau d’affichage grand,
visible, à accès facile
TBM 2012-13 page 46
46. Blackboard : Tableau des tâches
Sprint 4 : début le 14/03, fin le 28/03
Equipe
Objectif : …………………….
A FAIRE EN COURS FINI
Fini
Tâche Burndown chart
A0! Tâche
BO!
Tâche
A1! Tâche
B1!
Story 1!
Tâche Tâche
C1! D1!
Problèmes
A résoudre En cours
Story 2! Tâche
A2! Obstacle ! Obstacle !
3! 1!
Tâche
C2!
Obstacle
2!
TBM 2012-13 page 47
47. L’étapes
Rappeler les contexte du sprint
N° du sprint, durée, date de fin, disponibilité de l’équipe
Evaluer le périmètre
Éléments du backlog qui vont être réalisés
Définit l’objectif du sprint
Une phrase élaborer par le Team : « authentification des users »
Identifier les tâches
Le Team construit progressivement les tâches nécessaire
Tâche de développent du story
Tâches transverses (storyless)
Estimer les tâches
Le Team les estime collectivement en heure
Prendre des tâches
S’engager collectivement
Annonce
TBM 2012-13 de la capacité prévue pour le sprint page 48
48. Actualiser les charts
Un nouveau point dans le Le 1er point dans le BCS
BCR
Points
Heures
Sprints jours
TBM 2012-13 page 49
49. Faire de la conception collective
Ne pas se lancer directement dans la réalisation
Il faut faire de la conception collective
L’identification des tâches
Réfléchir à la façon dont la story sera conçue
Elaboration d’un fragment de Diagramme de classes
Ou de Diagramme de séquence UML
TBM 2012-13 page 50
