Cours gl 3 a-12-13_projet

427 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
427
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
7
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Cours gl 3 a-12-13_projet

  1. 1. Suivi du projet : Présentation de ScrumTBM 2012-13 page 2
  2. 2. Au faite c’est quoi ce Scrum ?TBM 2012-13 page 3
  3. 3. Ça c’est un ScrumTBM 2012-13 page 4
  4. 4. L’esprit d’équipeTBM 2012-13 page 5
  5. 5. Pratique de Scrum : une vue d’ensembleTBM 2012-13 page 6
  6. 6. Scrum est un frameworkTBM 2012-13 page 7
  7. 7. Cycle de vie scrumTBM 2012-13 page 8
  8. 8. En plus structuré ça donne …TBM 2012-13 page 9
  9. 9. Définition de produit SCRUM Ingénierie Gestion de de Projet LogicielTBM 2012-13 page 10
  10. 10. Backlog ProductTBM 2012-13 page 11
  11. 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. 12. De plus en plus détaillé dans les spécifications Une collection de user stories sur le même thèmeTBM 2012-13 page 13
  13. 13. Quel backlog ?TBM 2012-13 page 14
  14. 14. User Story!TBM 2012-13 page 15
  15. 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 correctementTBM 2012-13 page 16
  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 lhô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. 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. 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
  19. 19. User story : TemplateTBM 2012-13 page 20
  20. 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. 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éservationTBM 2012-13 page 22
  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 lhôtel es  Vérifier lqensemble des ’ notifié de ! annulationsTBM 2012-13 page 23
  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’utilisateurTBM 2012-13 page 24
  24. 24. Rédiger une! User Story!TBM 2012-13 page 25
  25. 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 momentTBM 2012-13 page 26
  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. 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. 28. INVEST (IR)! dans une! User Story!TBM 2012-13 page 29
  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
  30. 30. Pourquoi les! User Stories!TBM 2012-13 page 31
  31. 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 écritTBM 2012-13 page 32
  32. 32. Parce que les mots sont imprécis L’entrée est constituée « J’ai écrit ce scénario, il y a dune 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. 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 participativeTBM 2012-13 page 34
  34. 34. Planification de le releaseTBM 2012-13 page 35
  35. 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 sprintTBM 2012-13 page 36
  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érationsTBM 2012-13 page 37
  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 égaleTBM 2012-13 au chiffre de la complexité de la User story page 38
  38. 38. Affichage possible sur le dashboard - Petites User storiesTBM 2012-13 page 39
  39. 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 pointsTBM 2012-13 page 40
  40. 40. Planification de la release 10 10 10 5 3 2 fini 2 2 5 3 2 3 Sprint 1 Sprint 2 Sprint 3 Sprint 4 3 2 2 Vélocité = 10TBM 2012-13 page 41
  41. 41. ExempleTBM 2012-13 page 42
  42. 42. Burndown chart de la release Date actuelle Date de fin estiméesTBM 2012-13 page 43
  43. 43. Burndown chart de la release Date actuelle Partie du BP Hors release Date de fin de releaseTBM 2012-13 page 44
  44. 44. Planification du SprintTBM 2012-13 page 45
  45. 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 facileTBM 2012-13 page 46
  46. 46. Blackboard : Tableau des tâchesSprint 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. 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  AnnonceTBM 2012-13 de la capacité prévue pour le sprint page 48
  48. 48. Actualiser les charts  Un nouveau point dans le   Le 1er point dans le BCS BCR Points Heures Sprints joursTBM 2012-13 page 49
  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 UMLTBM 2012-13 page 50

×