cours gl 3 a-12-13_projet
TRANSCRIPT
page 2 TBM 2012-13
Suivi du projet : Présentation de Scrum
page 3 TBM 2012-13
Au faite c’est quoi ce Scrum ?
page 4 TBM 2012-13
Ça c’est un Scrum
page 5 TBM 2012-13
L’esprit d’équipe
page 6 TBM 2012-13
Pratique de Scrum : une vue d’ensemble
page 7 TBM 2012-13
Scrum est un framework
page 8 TBM 2012-13
Cycle de vie scrum
page 9 TBM 2012-13
En plus structuré ça donne …
page 10 TBM 2012-13
SCRUM
Définition de produit
Ingénierie de
Logiciel Gestion
de Projet
page 11 TBM 2012-13
Backlog Product
page 12 TBM 2012-13
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 !)
page 13 TBM 2012-13
De plus en plus détaillé dans les spécifications
Une collection de user stories sur le même thème
page 14 TBM 2012-13
Quel backlog ?
page 15 TBM 2012-13
User Story!
page 16 TBM 2012-13
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
page 17 TBM 2012-13
Exemples : Site de Voyage
je suis un utilisateur, je veux réserver
un hôtel !
je suis un voyageur, je veux voir les photos de l'hôtel !
Comme je suis un voyageur fréquent, je
veux faire une nouvelle réservation
d’un voyage déjà effectué, pour gagner
du temps!
je suis un utilisateur, je veux annuler une !réservation !
page 18 TBM 2012-13
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)
page 19 TBM 2012-13
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)
page 20 TBM 2012-13
User story : Template
page 21 TBM 2012-13
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 ?
Un voyageur fréquent peut-il annuler après sa réservation
Une confirmation est adressée à l’utilisateur ?
Comment ?
je suis un utilisateur, je veux annuler une !réservation !
page 22 TBM 2012-13
Les détails sont ajoutés en petites user stories
je suis un utilisateur, je veux annuler une !réservation !
Je suis un utilisateur
premium, je peux annuler une
réservation à la dernière minute!
Je ne suis pas un utilisateur premium, je peux annuler ma réservation 24 hrs à l’avance!Je suis un partenaire, j’adresse un courriel pour annuler toutes mes réservations !
page 23 TBM 2012-13
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
je suis un utilisateur, je veux annuler une !réservation !
Vérifier qu’un premium peut
annuler une réservation le jour
même sans charge supplémentaire !
Vérifier qu’un non-premium
paye 10% du montant en cas
d’annulation le jour de sa
réservation!
Vérifier qu’il y a bien un
courriel qui est adressé en cas
d’annulation!
Vérifier que l'hôtel est bien
notifié de l’ensemble des
annulations !
page 24 TBM 2012-13
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
page 25 TBM 2012-13
Rédiger une!User Story!
page 26 TBM 2012-13
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
page 27 TBM 2012-13
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 étudiant, je veux
remplir un dossier d’inscription!
Je suis un responsable, je veux consulter les inscriptions en
attentes !Je suis un
étudiant, je veux connaître le statut de mon dossier !
Je suis un responsable, je
veux valider/rejeter les inscriptions !
page 28 TBM 2012-13
Commencer Macro (EPIC) et itérer
Voyageur Fréquent !
je suis un Voyageur fréquent, je veux pouvoir
contrôler mon compte!
Je suis un voyageur
fréquent, je veux réserver un vol !
Je suis un voyageur
fréquent, je veux ...!
Je suis un voyageur fréquent, je veux réserver un vol en utilisant mes miles!
je suis un voyageur fréquent, je veux faire une nouvelle réservation d’un voyage déjà effectue!
Je suis un voyageur fréquent, je veux faire une mise à jour !
Je suis un voyageur fréquent, je veux voir si ma mise à jour à bien été prise en compte!
page 29 TBM 2012-13
INVEST (IR)!dans une!
User Story!
page 30 TBM 2012-13
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).
page 31 TBM 2012-13
Pourquoi les!User Stories!
page 32 TBM 2012-13
POURQUOI DES USER STORIES ? Mettre l’accent de l'écriture vers la communication orale
Si les spécification sont écrites
L’utilisateur aura ce qu’il veut
Au mieux il aura ce qu’il a écrit
ALORS
FAUX
page 33 TBM 2012-13
Parce que les mots sont imprécis
L’entrée est constituée d'une soupe ou d’une salade avec du pain
• (Soupe ou salade) avec du pain • (Soupe) ou salade avec du pain
« J’ai écrit ce scénario, il y a un an et le studio n’a pas
changé un mot »
« Le mot qu’ils n’ont pas changé est en page 87 »
page 34 TBM 2012-13
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
page 35 TBM 2012-13
Planification de le release
page 36 TBM 2012-13
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
page 37 TBM 2012-13
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
page 38 TBM 2012-13
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 au chiffre de la complexité de la User story
page 39 TBM 2012-13
Affichage possible sur le dashboard - Petites User stories
page 40 TBM 2012-13
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
page 41 TBM 2012-13
Planification de la release
Sprint 1 Sprint 2 Sprint 3 Sprint 4
23
5 fini
3 2 2
Vélocité = 10
2 2 3 3
10 10
5 2
10
page 42 TBM 2012-13
Exemple
page 43 TBM 2012-13
Burndown chart de la release
Date actuelle
Date de fin estimées
page 44 TBM 2012-13
Burndown chart de la release
Date actuelle
Date de fin de release
Partie du BP Hors release
page 45 TBM 2012-13
Planification du Sprint
page 46 TBM 2012-13
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
page 47 TBM 2012-13
Blackboard : Tableau des tâches Sprint 4 : début le 14/03, fin le 28/03
Objectif : ……………………. Equipe
Fini
Burndown chart
Problèmes A résoudre En cours
Obstacle !3!
Obstacle 2!
Obstacle !1!
A FAIRE EN COURS FINI
Story 1!
Story 2!
Tâche A1! Tâche
B1!Tâche
C1! Tâche D1!
Tâche A0! Tâche
BO!
Tâche A2!
Tâche C2!
page 48 TBM 2012-13
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 de la capacité prévue pour le sprint
page 49 TBM 2012-13
Actualiser les charts
Un nouveau point dans le BCR
Le 1er point dans le BCS
jours Sprints
Heures Points
page 50 TBM 2012-13
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