Ce document présente une formation sur la gestion de projets agiles utilisant le cadre Scrum, couvrant les principes fondamentaux, les rôles impliqués, et les outils nécessaires. Il insiste sur l'importance de la collaboration entre les équipes et les stakeholders pour assurer un développement efficace et centré sur la valeur. Le contenu vise à préparer les participants à mettre en œuvre Scrum dans leurs projets en s'appuyant sur des concepts théoriques et pratiques.

1. GDP avec Scrum │ © Pierre E. Neis1Bienvenue

2. Gestion de projets agiles avec ScrumCycle de formation « base »

3. Pierre NEISScrum Coach http://managingagile.blogspot.com/GDP avec Scrum │ © Pierre E. Neis3

4. GDP avec Scrum │ © Pierre E. Neis4

5. Les règles du jeuGDP avec Scrum │ © Pierre E. Neis5

6. Être à l’heureGDP avec Scrum │ © Pierre E. Neis6

7. Ne pas être dérangéGDP avec Scrum │ © Pierre E. Neis7

8. Pas de GSMGDP avec Scrum │ © Pierre E. Neis8

9. Ne quittez pas la pièceGDP avec Scrum │ © Pierre E. Neis9

10. Pénalité  donGDP avec Scrum │ © Pierre E. Neis10

11. Les supports de coursdisponibles sur le wiki suivant:Les supports de coursLes liens vers les sites de référenceLes photos prises lors de la sessionDes outils Scrum téléchargeablesLe Wiki permettra également de poursuivre votre formation au-delà de ces 3 journées:Nous partagerons nos adressesVous pourrez me contacter pour toute question lors de votre mise en “production” par ce biais.Le Wiki est une zone d’échange privée et les droits seront gérés par votre serviteur.GDP avec Scrum │ © Pierre E. Neishttp://scrumcenterlux.pbworks.com11

12. Le Jargon de scrum①GDP avec Scrum │ © Pierre E. Neis12

13. Le JargonGDP avec Scrum │ © Pierre E. Neis13

14. Objectif Comprendre les fondamentaux de ScrumSavoir utiliser les outils de ScrumÊtre en mesure de démarrer votre projet Scrum14GDP avec Scrum │ © Pierre E. Neis

15. PérimètreHistoriqueLa théorie « Scrum »La Philosophie agile15GDP avec Scrum │ © Pierre E. Neis

16. ❶ HistoriqueUn rappel contextuel….16GDP avec Scrum │ © Pierre E. Neis

17. Le modèle “Grandiose” de Winston RoyceGDP avec Scrum │ © Pierre E. NeisUn modèle de “Phasage simple” pour faire face aux exigencesrèglementairesaméricaines de DoD.“Je crois en ce concept, mais la mise en œuvre est risquée et invite l'échec.”Winston W. Royce, “Managing the development of large software systems”, Aug 197017

18. Nous perdons la course de relais“ L’approche “course de relai” du développement de produit… peut entrer en conflit avec les objectifs de vitesse maximale et de flexibilité. A contrario, une démarche holistique ou « rugby » où une équipe essaie d’aller au loin comme une unité, passant la balle en arrière, peut mieux servir aujourd’hui les exigences de la compétivité. »GDP avec Scrum │ © Pierre E. NeisHirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”,Harvard Business Review, January 198618

19. Une Analyse scientifiqueLa Question: « pourquoi les processus définis par SEI CMM (CMMI) ne mesurent-ils pas la capacité à livrer?« Controlled Chaos: living on the edge », Advanced DevelopmentMethods Inc. 199619GDP avec Scrum │ © Pierre E. Neis

20. Une Analyse scientifique (Réponse)Il existe 2 types de processus:Le processus définiLe processus empirique« Controlled Chaos: living on the edge », Advanced DevelopmentMethods Inc. 199620GDP avec Scrum │ © Pierre E. Neis

21. Un processusdéfiniProcessusDéfiniChaque tâche doit être entièrement comprise.

22. Pour un mêmenombred’entréesbiendéfinies, les sorties généréessont à chaquefoisidentiques.GDP avec Scrum │ © Pierre E. Neis21

23. GDP avec Scrum │ © Pierre E. NeisEst-ce que le développement logiciel est un processus défini?22

24. Le modèleempiriqueGDP avec Scrum │ © Pierre E. NeisContrôlesOutputsInputsIncrément de produitpotentiellementlivrableexigences

25. technologie

26. équipeProcessLe modèleempiriqueestdépendant de fréquentes inspections et adaptations pour atteindrel’objectif.23

27. La théorie SCRUM24GDP avec Scrum │ © Pierre E. Neis

28. Scrum est un processus empirique25GDP avec Scrum │ © Pierre E. Neis

29. Scrum repose sur 3 pieds26GDP avec Scrum │ © Pierre E. Neis

30. 10 Pratiques de baseVision claire et partagéeProduct Backlog entretenuProduct Backlog priorisé en fonction de la valeur métierItems de backlog triés par l’équipeDaily ScrumsSprints non perturbés ni par le Management ni par le(s) client(s)L’Equipe ne délivre que des items « terminés »Revue de Sprint collaborativeRétrospective concentrée sur l’amélioration du travail et du processus de l’équipe et de l’organisationBurndown Charts (graphiques de reste-à-faire)27GDP avec Scrum │ © Pierre E. Neis

31. Scrum vs Modèle en “cascade”GDP avec Scrum │ © Pierre E. Neis28

32. 15’ Discussion en Groupe29GDP avec Scrum │ © Pierre E. Neis

33. La Philosophie AgileL’Agile Manifesto30GDP avec Scrum │ © Pierre E. Neis

34. Manifeste pour le développement Agile de logicielsGDP avec Scrum │ © Pierre E. Neis31

35. Principessous-jacents au manifesteGDP avec Scrum │ © Pierre E. Neis32

36. Le triangle magiqueGDP avec Scrum │ © Pierre E. NeisEngagement des employésReconnus, engagés, employésheureuxCréation de ValeurMaximiser le ROI et optimiser la trésorerieSatisfaction du ClientServir le client33

37. Le ProblèmeLe métier et le développementsontsouventenfermésdans une relation malsaine.Les deux partenaires doivent changer pour améliorer la satisfaction client et la création de valeurGDP avec Scrum │ © Pierre E. Neis34

38. Contenu de Scrum35GDP avec Scrum │ © Pierre E. Neis

39. Introduction par Ken SchwaberScrum n'est pas une méthodologie. Scrum ne fournit pas les réponses à la manière de construire des logiciels de qualité plus rapidement.Scrum est un cadre dans lequel le jeu du développement de produit est joué.Votre équipe joue et, le bon ou le mauvais deviennent très visibles.Votreéquipeestdans un processusd’amélioration continue.GDP avec Scrum │ © Pierre E. Neis36

40. Le principe “Pull”GDP avec Scrum │ © Pierre E. Neis37

41. Équipes auto-géréesvsOrganisation traditionnelleGDP avec Scrum │ © Pierre E. Neis38

42. Les RèglesRôles, Artifacts et Time-boxes39GDP avec Scrum │ © Pierre E. Neis

43. GDP avec Scrum │ © Pierre E. Neis40

44. 3 Rôles Scrum Team plus 3 Rôles organisationnelsGDP avec Scrum │ © Pierre E. Neis41

45. Les Rôles de l’Equipe ScrumGDP avec Scrum │ © Pierre E. Neis42

46. Le ScrumMasterGDP avec Scrum │ © Pierre E. Neis43

47. Sa fonctionProtège l’équipe des turbulencesIl n’est pas un membre de l’ÉquipeIl optimise la productivité de l’ÉquipeIl contrôle l’”Inspect-&-Adapt” de l’ÉquipeIl assure que les idéaux “agiles” soient bien compris et respectés par tous les participants au projet.Il n’est pas responsable des déliverables.GDP avec Scrum │ © Pierre E. Neis44

48. Sa MissionProtéger l’Équipe ScrumLever les obstaclesExécuter le processTravailler avec le Product OwnerChanger l’OrganisationGDP avec Scrum │ © Pierre E. Neis45

49. Le ScrumMasterGDP avec Scrum │ © Pierre E. Neis+ Produit+ ProcessAgir de la bonnefaçonFaire bien (Produit)Il forme et coache SCRUMIl régule les obstaclesIl anime les réunionsIl protègel’équipeIl est le gardien du process Scrum46

50. Le Product OwnerGDP avec Scrum │ © Pierre E. Neis47

51. Sa fonctionIl pilote le projet d’un point de vue métierIl communique une vision claire du produit et défini ses caractéristiquesIl accepte ou rejette le produit à la fin de chaque SprintIl s’assure que l’Équipe se concentre sur les items du Backlog de plus forte valeur ajoutéeIl a le même objectif que l’ÉquipeIl est responsable du Retour sur Investissement et des livraisons.GDP avec Scrum │ © Pierre E. Neis48

52. Sa MissionSe concentre sur le retour sur investissementConstruit et communique la visionEntretien le Product BacklogRend compte de l’acceptance des déliverablesÉtabli et maintien le Plan de LivraisonGDP avec Scrum │ © Pierre E. Neis49

53. L’ÉquipeGDP avec Scrum │ © Pierre E. Neis50

54. Sa fonctionElle délivre le produit et elle est responsable de sa qualitéElle travaille avec les utilisateurs-finaux, le client, le Product Owner pour comprendre les exigences-métier.Elle s’engage volontairementElle travaille continuellement avec le Product Owner pour définir la direction stratégique du Produit.GDP avec Scrum │ © Pierre E. Neis51

55. Constituer l’Équipe5/9 personnesMultidisciplinaireAutogéréeCross-fonctionnelle / transversePlus orientée compétence que fonctionGDP avec Scrum │ © Pierre E. Neis52

56. Constitution de l’ÉquipeGDP avec Scrum │ © Pierre E. NeisProduct OwnerChef de ProduitMOAAnalyste MétierChef de Projet fonctionnelScrum MasterArchitecteTout le monde. Pas une autorité.Pas nécessairement un développeur.The TeamDéveloppeurDBAAnalysteTesteur53

57. Tuckman: les phases de dévelopement© Bruce Tuckman 'Forming Storming' concept 1965. Diagram Alan ChapmanGDP avec Scrum │ © Pierre E. Neis54

58. Comment optimiser le travail de l’Équipe... Créer une règle de vie de l’ÉquipeNe jamais utiliser le “VOUS”Être à l’heureUtiliser un “bâton de parole”Ne jamais être nominatifGDP avec Scrum │ © Pierre E. Neis55

59. CollaborationLe Product Owner n’est pas un ennemiD’autres équipes ont besoin de savoir que nous avons besoin d’elles.Nous avons tous le même objectifUne Équipe = un espace dédié à l’ÉquipeGDP avec Scrum │ © Pierre E. Neis56

60. Sa MissionGarantir la QualitéLivrerLivrerLivrerEstimerEstimerEstimerS’engagerS’autogérerS’organiser .... Elle-mêmeGDP avec Scrum │ © Pierre E. Neis57

61. Les Rôles OrganisationnelsGDP avec Scrum │ © Pierre E. Neis58

62. Le ClientGDP avec Scrum │ © Pierre E. Neis59

63. Sa fonctionIl demande le produitIl contracte l’organisation pour le développement de son produitTypiquement, il s’agit d’un responsable qui achète un développement de produit par un sous-traitant.Dans les projets internes, il s’agit principalement du sponsor au projet, c’est à dire la personne validant le projet et le budget.GDP avec Scrum │ © Pierre E. Neis60

64. Sa MissionIl commande le produitIl paye le développement du produitIl donne des feed-back et des révisionsGDP avec Scrum │ © Pierre E. Neis61

65. Le ManagerGDP avec Scrum │ © Pierre E. Neis62

66. Sa fonctionLe management, la gestion, est primordial dans tout projet Scrum. Il permet à l’Équipe de constituer un environnement optimal pour le déroulement du projet Scrum.Le manager donne de la structure et de la stabilité.Il travaille de concert avec le ScrumMaster pour réorganiser l’organigramme de la structure et donner de la guidance si nécessaire.GDP avec Scrum │ © Pierre E. Neis63

67. Sa MissionIl s’assure que l’organisation puisse survivre en cas de défaillance.Il crée des règles et des lignes directrices.GDP avec Scrum │ © Pierre E. Neis64

68. L’Utilisateur FinalGDP avec Scrum │ © Pierre E. Neis65

69. Sa fonctionCe rôle peut être joué par un grand nombre de personnes.L'Utilisateur final est celui qui connaît les besoins et avec cette connaissance, il définit le produit en disant à l'équipe ce dont il a besoin comme fonctionnalités.GDP avec Scrum │ © Pierre E. Neis66

70. Sa MissionIl connaît ses besoins et ses exigencesIl donne son feed-back lors des revuesIl participe au Sprint Planning 1GDP avec Scrum │ © Pierre E. Neis67

71. Comment ces rôles travaillent-ils ensemble?GDP avec Scrum │ © Pierre E. Neis68

72. Rôles organisationnelsScrum Team RolesGDP avec Scrum │ © Pierre E. Neis69

73. Le ScrumMaster travaille avec le Product OwnerGDP avec Scrum │ © Pierre E. Neis70

74. Le ScrumMaster travaille avec l’EquipeGDP avec Scrum │ © Pierre E. Neis71

75. Le Product Owner travaille avec le clientGDP avec Scrum │ © Pierre E. Neis72

76. L’Equipe travaille avec l’utilisateur finalGDP avec Scrum │ © Pierre E. Neis73

77. Le ScrumMaster travaille avec le ManagerGDP avec Scrum │ © Pierre E. Neis74

78. Le Product Owner a besoin de connaître ce que le marché (l’utilisateur final) souhaite.GDP avec Scrum │ © Pierre E. Neis75

79. Question?Quels problèmes avez-vous dans cet exemple si le ScrumMaster est membre de l’Équipe?GDP avec Scrum │ © Pierre E. NeisCompagnie PORTAL (USA) 5 Product Owners (News, Email, Produits, Sécurité, Infrastructure) 1 Equipe Scrum de développement

80. 1 Produit intégré (Portail)76

81. RéférencesGDP avec Scrum │ © Pierre E. Neis77

82. Les Artefacts78GDP avec Scrum │ © Pierre E. Neis

83. 4 Artefacts79GDP avec Scrum │ © Pierre E. Neis

84. ExerciceGDP avec Scrum │ © Pierre E. Neis80

85. ModèleJe voudrais une application bureau que je puisse utilise pour stocker toute mon information confidentielle tells que les numéros de série, les informations Carte de Crédit, les alias d’enregistrement sur les sites web, les mots de passe, etc. pour chaque item que je souhaite stocker, je dois définir le type de données (comme une date d’expiration). Bien entendu, le système devra être protégé par mot de passe et très sécurisé. Je souhaiterai effectuer des sauvegardes/restaurations online de sorte que je puisse récupérer mes informations à distance. Le produit devra posséder des options de recherche, etc.…GDP avec Scrum │ © Pierre E. NeisSécurisation des InformationsPersonnellesSource: Mike Cohn, CSPO81

86. User StoriesEn tantque[rôleUtilisateur]Je veuxune[FONCTIONNALITE]De sorteque je reçois[BUSINESS VALUE].GDP avec Scrum │ © Pierre E. Neis82

87. User Story CardUne brève description textuelle des exigences+ Risques+ critèresd’acceptationAS A Product OwnerI CAN / I WANT estimate Costs3 lines of Requirement DescriptionGDP avec Scrum │ © Pierre E. Neis83

88. Les bonnes Stories sont INVESTGDP avec Scrum │ © Pierre E. Neis84

89. ExerciceGDP avec Scrum │ © Pierre E. Neis85

90. Le Product Backlog?Priorité hauteLe Backlog est une liste de tâches ouvertes comme :les exigences

91. une liste de tous les travauxsouhaités pour le projet

92. Idéalement exprimé de telle sorte que chaque objet a une valeur pour les utilisateurs ou les clients du produit

93. Priorisé par le Product Owner

94. Repriorisé au début de chaque SprintSprintPriorité moyenneReleaseReleases futuresGDP avec Scrum │ © Pierre E. Neis86

95. Le Product BacklogGDP avec Scrum │ © Pierre E. NeisLe Product Backlog répond aux questions suivantes:Quoi? Quand? Pour Qui?87

96. Stories, themes and epicsGDP avec Scrum │ © Pierre E. NeisUSER STORY:Une description de la fonctionnalité désirée du point de vue du l'utilisateur ou duclientTHEME:Un recueil de storiesEPIC:Une grande story88

97. Sprint Backlog89GDP avec Scrum │ © Pierre E. Neis

98. Release Burn down ChartExample de Burndown Chart (Schwaber and Beedle 2002)Le Release burndown rend les tendances des progrès visibles.Le rapport estbasésur les informationssuivantes:• le reste-à-faire du Product Backlog pour transformer la Vision en un produitgagnant.• Le nombre de Sprints nécessairesourestants.• La vélocité.Le Release burndown regarde le passé pour comprendre ce que l'avenir est susceptible de détenir. Nous déterminons le taux d'avancement des sprints passés.90GDP avec Scrum │ © Pierre E. Neis

99. Sprint Burn-down ChartsLe Sprint Burn-down chart montrecombien d'efforts a été déployé en travaillant sur la tâche contenue dans le Sprint BacklogEt compare cela à la depenseidéaleLe tableau donne une tendance qui indique si l'équipe est susceptible de respecter son engagement (indicateur avancé)91GDP avec Scrum │ © Pierre E. Neis

100. Les supports de coursdisponibles sur le wiki suivant:Les supports de coursLes liens vers les sites de référenceLes photos prises lors de la sessionDes outils Scrum téléchargeablesLe Wiki permettra également de poursuivre votre formation au-delà de ces 3 journées:Nous partagerons nos adressesVous pourrez me contacter pour toute question lors de votre mise en “production” par ce biais.Le Wiki est une zone d’échange privée et les droits seront gérés par votre serviteur.GDP avec Scrum │ © Pierre E. Neishttp://scrumcenterlux.pbworks.com92

101. Les Time-boxes93GDP avec Scrum │ © Pierre E. Neis

102. Au niveau stratégiqueGDP avec Scrum │ © Pierre E. Neis94

103. Estimation Meeting- Préparation du Sprint Planning- Estimation formelle- Passez au moins deux réunions par Sprint- Estimeruniquementsur la taille et le tempsGDP avec Scrum │ © Pierre E. Neis> Input pour Release Planning95

104. Au niveau tactiqueGDP avec Scrum │ © Pierre E. Neis96

105. Les MeetingsLe Quoi?Le Comment?La SynchronisationLes RésultatsL’AméliorationGDP avec Scrum │ © Pierre E. Neis97

106. Sprint Planning 2Revue de SprintRétrospectiveSprint Planning 1Sprint Planning 2Sprint Planning 1SPRINTDaily MeetingsGDP avec Scrum │ © Pierre E. Neis98

107. Sprint Planning MeetingOrganisateur: Product OwnerParticipants: l’équipe (actif), le ScrumMaster (passif)Durée: 8 heures pour un Sprint de 4 semainesGDP avec Scrum │ © Pierre E. Neis2 parties:

108. Le QUOI?

109. Le COMMENT?

110. Le Product Owner:

111. Présente le Product Backlog priorisé par le client et/ou les utilisateurs

112. Présente le Release Plan Initial

113. Présentation de la Vision

114. L’équipe:

115. Estime le Product Backlog en fonction de sa faisabilité (estimation fonctionelle)

116. Découpe le Product Backlog en Sprint Backlogs avec le Product Owner

117. Découpe le Sprint Backlog en tâches

118. Estime le Sprint Backlog

119. Le Product Owner et l’Equipe:

120. Définissent l’objectif du Sprint

121. Valident la Definition of Done99

122. Pour chaque Item du Product Backlog (US)Quelle interface devons-nous rédiger?Quelle architecture devons-nous créer?Quelles tables devons-nous actualiser?Quels composants devons-nous mettre à jour ou créer?GDP avec Scrum │ © Pierre E. NeisSprintPlanning 2Design100

123. Definition of DoneGDP avec Scrum │ © Pierre E. Neis101

124. Level of DoneLe Code est conforme aux normesLe Code estPropre

125. Refactoré

126. Testéunitairement

127. Validé (checked in)

128. Intégré (Built)

129. Dispose d'une suite de test unitaire qui lui est appliquée.Pour arriver à cela, l’environnement de développementestconstitué :D’unebibliothèque de code source

130. De codes standards,