Cours gl 3 a-12-13_projet

TBM 2012-13

Suivi du projet : Présentation de Scrum

TBM 2012-13

Au faite c’est quoi ce Scrum ?

TBM 2012-13

Ça c’est un Scrum

TBM 2012-13

L’esprit d’équipe

TBM 2012-13

Pratique de Scrum : une vue d’ensemble

TBM 2012-13

Scrum est un framework

TBM 2012-13

Cycle de vie scrum

TBM 2012-13

En plus structuré ça donne …

TBM 2012-13

SCRUM

Définition de produit

Ingénierie de

Logiciel Gestion

de Projet

TBM 2012-13

Backlog Product

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 !)

TBM 2012-13

De plus en plus détaillé dans les spécifications

Une collection de user stories sur le même thème

TBM 2012-13

Quel backlog ?

TBM 2012-13

User Story!

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

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 !

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)

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)

TBM 2012-13

User story : Template

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 ?


TBM 2012-13

Les détails sont ajoutés en petites user stories


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 !

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


 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 !

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

TBM 2012-13

Rédiger une!User Story!

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

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 !

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!

TBM 2012-13

INVEST (IR)!dans une!

User Story!

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).

TBM 2012-13

Pourquoi les!User Stories!

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

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 »

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

TBM 2012-13

Planification de le release

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

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

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

TBM 2012-13

Affichage possible sur le dashboard - Petites User stories

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

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

TBM 2012-13

Exemple

TBM 2012-13

Burndown chart de la release

Date actuelle

Date de fin estimées

TBM 2012-13

Burndown chart de la release

Date actuelle

Date de fin de release

Partie du BP Hors release

TBM 2012-13

Planification du Sprint

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

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!

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

TBM 2012-13

Actualiser les charts

  Un nouveau point dans le BCR

  Le 1er point dans le BCS

jours Sprints

Heures Points

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

Cours gl 3 a-12-13_projet

Documents

Transcript of Cours gl 3 a-12-13_projet