Agile Training Jam

521 vues

Publié le

Discover Agile core values and principles during a captivating sessions mixing theory, workshops and games…
We love to share our values and help your team be powerful, solid and efficient.

Publié dans : Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

Aucune remarque pour cette diapositive

Agile Training Jam

  1. 1. A G I L E T R A I N I N G J A M A G I L E S E S S I O N S @ A G I L E G E N I U S
  2. 2. FA I S O N S C O N N A I S S A N C E
  3. 3. T R A D I N G C A R D S
  4. 4. C R É E Z V O T R E P R O P R E C A R T E • Choisissez un pseudonyme • Inscrivez-le au bas du recto de la carte • Inscrivez au dos de la carte une information sur vous que les autres ne connaissent pas.
  5. 5. É C H A N G E Z - V O U S L E S C A R T E S • Quand une carte vous donne envie de poser une question, conservez-là, sinon continuez à échanger.
  6. 6. D É C O U V R E Z U N S E C R E T • Un volontaire pour poser une question sur l’information secrète?
  7. 7. B I E N C O M M E N C E R L A J O U R N É E ! S P E E D B O A T
  8. 8. FOR C ESA X ES D ’ A M É L IORAT IO N D I F F I C U LT ÉS
  9. 9. A G I L I T É O R I G I N E S & P R I N C I P E S R E T O U R A U X S O U R C E S
  10. 10. L E M A N I F E S T E A G I L E P E R S O N N E S E T I N T E R A C T I O N SP R O C E S S U S E T O U T I L S L O G I C I E L Q U I F O N C T I O N N ED O C U M E N TAT I O N S U P E R F L U E C O L L A B O R AT I O N AV E C L E C L I E N T N É G O C I AT I O N À PA RT I R D ' U N C O N T R AT A D A P TAT I O N A U C H A N G E M E N TS U I V I D ' U N P L A N
  11. 11. - 1 - “Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.”
  12. 12. - 2 - “Accueillez positivement les changements de besoins,
 même tard dans le projet. Les processus Agiles exploitent le changement
 pour donner un avantage compétitif au client.”
  13. 13. - 3 - “Livrez fréquemment un logiciel opérationnel
 avec des cycles de quelques semaines à quelques mois
 et une préférence pour les plus courts.”
  14. 14. - 4 - “Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.”
  15. 15. - 5 - “Réalisez les projets avec des personnes motivées.
 Fournissez-leur l’environnement et le soutien
 dont ils ont besoin et faites-leur confiance
 pour atteindre les objectifs fixés.”
  16. 16. - 6 - “La méthode la plus simple et la plus efficace pour transmettre
 de l’information à l'équipe de développement
 et à l’intérieur de celle-ci est le dialogue en face à face.”
  17. 17. - 7 - “Un logiciel opérationnel est la principale mesure d’avancement.”
  18. 18. - 8 - “Les processus Agiles encouragent
 un rythme de développement soutenable.
 Ensemble, les commanditaires, les développeurs, et les utilisateurs devraient être capables de maintenir
 indéfiniment un rythme constant.”
  19. 19. - 9 - “Une attention continue à l'excellence technique
 et à une bonne conception renforce l’Agilité.”
  20. 20. - 1 0 - “La simplicité, c’est-à-dire l’art
 de minimiser la quantité de travail inutile
 est essentielle.”
  21. 21. - 1 1 - “Les meilleures architectures, spécifications et conceptions
 émergent d'équipes auto-organisées.”
  22. 22. - 1 2 - “À intervalles réguliers, l'équipe réfléchit aux moyens
 de devenir plus efficace,
 puis règle et modifie son comportement en conséquence.”
  23. 23. M U LT I TA S K I N G N A M E G A M E T R A VA I L M U LT I - TÂ C H E S
  24. 24. - H E N R I K K N I B E R G - “Combien de temps faut-il pour écrire un prénom?”
  25. 25. “Combien de temps faut-il pour écrire cinq prénoms?”
  26. 26. “Quels sont les facteurs qui influencent le temps?”
  27. 27. C H E R C H O N S 
 L A V É R I T É …
  28. 28. PA R L O N S D E S C R U M
  29. 29. L E S R È G L E S D U J E U
  30. 30. T H E S C R U M G U I D E L A R É F É R E N C E
  31. 31. S C R U M V S . G A S P C E Q U ’ E S T S C R U M & C E Q U E C E N ’ E S T PA S
  32. 32. U N C A D R E S I M P L E & L É G E R Rôles Product Owner Scrum Master Equipe Cérémonies Sprint Planning Sprint Review Retrospective Daily Scrum Artéfacts Product Backlog Task Board Burndown Charts
  33. 33. L E S R Ô L E S D E S C R U M
  34. 34. L E P R O D U C T O W N E R
  35. 35. L E P R O D U C T O W N E R • Définit les fonctionnalités du produit. • Choisit la date et le contenu de la release. • Responsable du retour sur investissement. • Ordonne le backlog en fonction de la “valeur métier”. • Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire. • Accepte ou rejette les résultats.
  36. 36. L E S C R U M M A S T E R
  37. 37. L E S C R U M M A S T E R • Représente le management du projet. • Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum. • Élimine les obstacles et s’assure que l'équipe est complètement fonctionnelle et productive. • Facilite une coopération poussée entre tous les rôles et fonctions. • Protège l'équipe des interférences extérieures.
  38. 38. L’ É Q U I P E S C R U M
  39. 39. L’ É Q U I P E S C R U M • De 5 à 10 personnes • Regroupant tous les rôles
 (Architecte, Concepteur, Développeur, Spécialiste IHM, Testeur,…) • A plein temps sur le projet, de préférence
 (Exceptions possibles - Administrateur, DBA,…) • L’équipe s’organise par elle-même • La composition de l’équipe ne doit pas changer pendant un Sprint
  40. 40. L E S C É R É M O N I E S
  41. 41. S P R I N T P L A N N I N G
  42. 42. B A C K L O G R E V I E W
  43. 43. P L A N N I N G P O K E R
  44. 44. D A I LY M E E T I N G S
  45. 45. D A I LY S C R U M • Les règles: • Tous les jours • 15 minutes maximum • Debout • Pas fait pour résoudre les problèmes. • Tout le monde est invité. • Seuls les membres de l'équipe peuvent parler. • Permet d'éviter l'organisation d'autres réunions.
  46. 46. D A I LY S C R U M • Chacun répond à 3 questions: • Qu'as tu fait hier ? • Que vas-tu faire aujourd'hui ? • Y a t-il un obstacle qui te freine ? • Il ne s'agit pas de compte-rendus au Scrum Master. • Ce sont des engagements devant des pairs.
  47. 47. S P R I N T R E V I E W ( D É M O )
  48. 48. S P R I N T R E V I E W ( D É M O ) • L'équipe présente ce qu'elle a fait pendant le sprint. • Se fait avec une démo des nouvelles fonctionnalités ou de l'architecture • Informel - Préparation inférieure à deux heures - Pas de slides! • Toute l'équipe participe. • On invite du monde.
  49. 49. R É T R O S P E C T I V E
  50. 50. R É T R O S P E C T I V E • Réfléchir régulièrement à ce qui fonctionne bien et ce qui ne marche pas. • Dure en général de 15 à 30 minutes. • Fait à la fin de chaque sprint. • Toute l'équipe participe. • ScrumMaster • Product Owner • Equipe • Eventuellement clients et autres intervenants
  51. 51. R É T R O S P E C T I V E • Toute l'équipe collecte du feedback sur le déroulement du dernier Sprint et échange sur ce qu'elle souhaiterait: • Commencer à faire • Arrêter de faire • Continuer à faire
  52. 52. V I S U A L M A N A G E M E N T M E S U R E R P O U R P I L O T E R & S ’ A M É L I O R E R
  53. 53. TA S K B O A R D ( L I S T E D E S TÂ C H E S ) • Chacun s'engage sur du travail qu'il choisit. Le travail n'est jamais attribué par un autre • L'estimation du reste à faire est ajustée tous les jours. • N'importe qui peut ajouter, supprimer ou changer la liste des tâches. • Le travail du sprint émerge progressivement. Si un travail n'est pas clair, définir une tâche avec plus de temps et la décomposer après • Mise à jour du travail restant quand il est mieux connu
  54. 54. TA S K B O A R D P H Y S I Q U E S T O R I E S À FA I R E E N C O U R S T E R M I N É Story 1 Task Story 2 Story 3 Story 4 Story 5 Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task Task
  55. 55. B U R N D O W N C H A R T
  56. 56. B U R N D O W N C H A R T 0 25 50 75 100 20/10 21/10 22/10 23/10 24/10
  57. 57. G E N E R A L LY A C C E P T E D S C R U M P R A C T I C E S • User Stories • Acceptance Tests • Story Points • Task Hours
  58. 58. U S E R S T O R I E S D É C R I R E L E B E S O I N …
  59. 59. P R O B L È M E S D E C O M M U N I C AT I O N ?
  60. 60. U N L A N G A G E C L A I R E T U N I V E R S E L
  61. 61. S E C O M P R E N D R E , C ’ E S T I M P O R TA N T ! • Il est nécessaire de disposer d'un moyen de communication clair, universel et compréhensible par tous les acteurs. • Les projets ne partageant pas un langage commun et exempt de jargon sont voués à l'échec.
  62. 62. L E S U S E R S T O R I E S
  63. 63. S T O RY C A R D S • Les user stories sont généralement écrites sur une fiche ou Post-It. • Les fiches peuvent être enrichies par des notes, des estimations, une valeur business, etc…
  64. 64. C O N V E R S AT I O N • Les précisions et autres détails concernant la user story sont évoqués lors d'une discussion avec le Product Owner.
  65. 65. VA L I D AT I O N • Les critères de succès et exemple à l'origine des tests d'acceptance sont garants de la validité fonctionnelle de la user story.
  66. 66. E X E M P L E S En tant que client je peux modifier mon adresse postale afin de recevoir les couriers de Fongecif En tant que client je dois saisir mon mot de passe afin de valider ma nouvelle adresse
  67. 67. O Ù S O N T L E S P R É C I S I O N S ? “En tant que client je peux modifier mon adresse postale afin de recevoir les couriers de Fongecif.“ • Est-ce que mon adresse doit être valide? • Est-ce que je serai notifié de la prise en compte? • Que se passe-t-il en cas d'erreur?
  68. 68. C R I T È R E S D E S U C C È S • Les critères de succès métier viennent s'ajouter à la user story afin de préciser le besoin. • Ils sont formulés sous forme d'exemples concrets.
  69. 69. C R I T È R E S D E S U C C È S • Je saisis une adresse invalide (75315 Paris) et on me propose une adresse valide que je dois confirmer (75015 Paris). • Si le service de changement d'adresse est indisponible je suis infomé par le message “Votre demande n'a pas pu être prise en compte merci de rééssayer ultérieurement”. • Lorsque je valide ma nouvelle adresse, je suis notifié de la prise en compte via le message “Votre demande a été prise en compte”.
  70. 70. P R É C I S I O N PA R D É C O U PA G E En tant que client je peux modifier mon adresse postale afin de recevoir les couriers Fongecif En tant que client je suis invité à vérifier
 que ma nouvelle
 adresse est valide En tant que client je suis notifié de la
 prise en compte de ma
 demande de
 changement d'adresse En tant que client je dois valider ma
 nouvelle adresse via
 Mon mot de passe
  71. 71. C O M B I N A I S O N D E S A P P R O C H E S • Les deux méthodes ne sont pas exclusives et peuvent être combinées. • Il est important d'identifier le bon niveau de granularité pour les user stories. • Lors de son évolution, chaque user story se verra attribuer des critères de succès.
  72. 72. S T O R I E S & E P I C S • Les epics sont de grosses user stories qui pourront être découpées en plusieurs user stories par la suite.
  73. 73. L’ AT E L I E R D ’ E C R I T U R E • Des experts peuvent être invités • Il n'est pas lié aux cérémonies Scrum • L'objectif est d'écrire rapidement les stories • La priorisation sera faite ultérieurement
  74. 74. U N E B O N N E U S E R S T O RY
  75. 75. I . N . V. E . S . T. • Indépendant • Négociable • Valeur ajoutée • Estimable • Suffisamment petit • Testable
  76. 76. - F O R M A L I S M E U N I Q U E - “En tant que < Rôle >, je souhaite < Objectif > afin de < Raison >”
  77. 77. P O U R Q U O I D E S U S E R S T O R I E S ? • Le métier et les développeurs comprennent les user stories. • Les personnes retiennent plus facilement les évolutions si elles sont organisées sous forme de stories.
  78. 78. AVA N TA G E S • Les stories sont adaptées à la priorisation et planification. • Elles permettent de profiter des opportunités de développement. • Le produit prend forme grâce à l'ordonnancement des user stories. • Ce sont des éléments collaboratifs et favorables à la communication.
  79. 79. I M P O R TA N T ! • Ne pas oublier l'objectif. • Le texte de la story écrit sur une carte est toujours moins important que les discussions qui en découlent.
  80. 80. E X I G E N C E S N O N F O N C T I O N N E L L E S • Elles font partie du Backlog Produit. • Elles peuvent être exprimées sous la forme: • De stories techniques (le rôle est l’équipe de réalisation) • De critères d’acceptance
  81. 81. E X P R E S S I O N D E B E S O I N & S P É C I F I C AT I O N User story Tests d'acceptance Besoin agile + Discussion +
  82. 82. M E R C I W W W. A G I L E G E N I U S . C O M

×