Gestion de projets agiles avec scrumv2

2 539 vues

Publié le

Formation Scrum (base) pour Devoteam et Namsa.
28-29.09.2011

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

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

Aucune remarque pour cette diapositive
  • Nota: lestermessontvolontairementrestés en anglaisafin de favoriser le dialogue avec la communautéinternationale Scrum.
  • Source: SilvanaWasitovaWinston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce a développé le modèle de livraison par étapes pour faire face aux exigences réglementaires des Etats-Unis énoncées dans le documentDoD STD-2167, qui était tellement compliquéet bureaucratique que l’approche en cascade était la seule façon d'y faire face;
  • Utile lorsqueLe process ne peut pas êtresuffisammentdécrit pour assurer sa répétabilitéIl y a tellement de complexitéou de nuisance que le projet tend vers des livrablesdifférents.Quel’onespèrel’inespéré.Exercedes contrôles par de fréquentes inspections et adaptations.
  • Exercise 30’ : building a Shared Vision from the Case Study according to the Elevator Statement Form
  • 5’ minutes discussion in Team. Then Feedback: inspect & adapt
  • Gestion de projets agiles avec scrumv2

    1. 1. GDP avec Scrum │ © Pierre E. Neis<br />1<br />Bienvenue<br />
    2. 2. Gestion de projets agiles avec Scrum<br />Cycle de formation « base »<br />
    3. 3. Pierre NEIS<br />Scrum Coach http://managingagile.blogspot.com/<br />GDP avec Scrum │ © Pierre E. Neis<br />3<br />
    4. 4. GDP avec Scrum │ © Pierre E. Neis<br />4<br />
    5. 5. Les règles du jeu<br />GDP avec Scrum │ © Pierre E. Neis<br />5<br />
    6. 6. Être à l’heure<br />GDP avec Scrum │ © Pierre E. Neis<br />6<br />
    7. 7. Ne pas être dérangé<br />GDP avec Scrum │ © Pierre E. Neis<br />7<br />
    8. 8. Pas de GSM<br />GDP avec Scrum │ © Pierre E. Neis<br />8<br />
    9. 9. Ne quittez pas la pièce<br />GDP avec Scrum │ © Pierre E. Neis<br />9<br />
    10. 10. Pénalité  don<br />GDP avec Scrum │ © Pierre E. Neis<br />10<br />
    11. 11. Les supports de cours<br />disponibles sur le wiki suivant:<br />Les supports de cours<br />Les liens vers les sites de référence<br />Les photos prises lors de la session<br />Des outils Scrum téléchargeables<br />Le Wiki permettra également de poursuivre votre formation au-delà de ces 3 journées:<br />Nous partagerons nos adresses<br />Vous pourrez me contacter pour toute question lors de votre mise en “production” par ce biais.<br />Le Wiki est une zone d’échange privée et les droits seront gérés par votre serviteur.<br />GDP avec Scrum │ © Pierre E. Neis<br />http://scrumcenterlux.pbworks.com<br />11<br />
    12. 12. Le Jargon de scrum<br />①<br />GDP avec Scrum │ © Pierre E. Neis<br />12<br />
    13. 13. Le Jargon<br />GDP avec Scrum │ © Pierre E. Neis<br />13<br />
    14. 14. Objectif <br />Comprendre les fondamentaux de Scrum<br />Savoir utiliser les outils de Scrum<br />Être en mesure de démarrer votre projet Scrum<br />14<br />GDP avec Scrum │ © Pierre E. Neis<br />
    15. 15. Périmètre<br />Historique<br />La théorie « Scrum »<br />La Philosophie agile<br />15<br />GDP avec Scrum │ © Pierre E. Neis<br />
    16. 16. ❶ Historique<br />Un rappel contextuel….<br />16<br />GDP avec Scrum │ © Pierre E. Neis<br />
    17. 17. Le modèle “Grandiose” de Winston Royce<br />GDP avec Scrum │ © Pierre E. Neis<br />Un modèle de “Phasage simple” pour faire face aux exigencesrèglementairesaméricaines de DoD.<br />“Je crois en ce concept, mais la mise en œuvre est risquée et invite l'échec.”<br />Winston W. Royce, “Managing the development of large software systems”, Aug 1970<br />17<br />
    18. 18. Nous perdons la course de relais<br />“ 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é. »<br />GDP avec Scrum │ © Pierre E. Neis<br />Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”,<br />Harvard Business Review, January 1986<br />18<br />
    19. 19. Une Analyse scientifique<br />La Question: « pourquoi les processus définis par SEI CMM (CMMI) ne mesurent-ils pas la capacité à livrer?<br />« Controlled Chaos: living on the edge », Advanced DevelopmentMethods Inc. 1996<br />19<br />GDP avec Scrum │ © Pierre E. Neis<br />
    20. 20. Une Analyse scientifique (Réponse)<br />Il existe 2 types de processus:<br />Le processus défini<br />Le processus empirique<br />« Controlled Chaos: living on the edge », Advanced DevelopmentMethods Inc. 1996<br />20<br />GDP avec Scrum │ © Pierre E. Neis<br />
    21. 21. Un processusdéfini<br />ProcessusDéfini<br /><ul><li>Chaque tâche doit être entièrement comprise.
    22. 22. Pour un mêmenombred’entréesbiendéfinies, les sorties généréessont à chaquefoisidentiques.</li></ul>GDP avec Scrum │ © Pierre E. Neis<br />21<br />
    23. 23. GDP avec Scrum │ © Pierre E. Neis<br />Est-ce que le développement logiciel est un processus défini?<br />22<br />
    24. 24. Le modèleempirique<br />GDP avec Scrum │ © Pierre E. Neis<br />Contrôles<br />Outputs<br />Inputs<br />Incrément de produitpotentiellementlivrable<br /><ul><li>exigences
    25. 25. technologie
    26. 26. équipe</li></ul>Process<br />Le modèleempiriqueestdépendant de fréquentes inspections et adaptations pour atteindrel’objectif.<br />23<br />
    27. 27. La théorie SCRUM<br />24<br />GDP avec Scrum │ © Pierre E. Neis<br />
    28. 28. Scrum est un processus empirique<br />25<br />GDP avec Scrum │ © Pierre E. Neis<br />
    29. 29. Scrum repose sur 3 pieds<br />26<br />GDP avec Scrum │ © Pierre E. Neis<br />
    30. 30. 10 Pratiques de base<br />Vision claire et partagée<br />Product Backlog entretenu<br />Product Backlog priorisé en fonction de la valeur métier<br />Items de backlog triés par l’équipe<br />Daily Scrums<br />Sprints non perturbés ni par le Management ni par le(s) client(s)<br />L’Equipe ne délivre que des items « terminés »<br />Revue de Sprint collaborative<br />Rétrospective concentrée sur l’amélioration du travail et du processus de l’équipe et de l’organisation<br />Burndown Charts (graphiques de reste-à-faire)<br />27<br />GDP avec Scrum │ © Pierre E. Neis<br />
    31. 31. Scrum vs Modèle en “cascade”<br />GDP avec Scrum │ © Pierre E. Neis<br />28<br />
    32. 32. 15’ Discussion en Groupe<br />29<br />GDP avec Scrum │ © Pierre E. Neis<br />
    33. 33. La Philosophie Agile<br />L’Agile Manifesto<br />30<br />GDP avec Scrum │ © Pierre E. Neis<br />
    34. 34. Manifeste pour le développement Agile de logiciels<br />GDP avec Scrum │ © Pierre E. Neis<br />31<br />
    35. 35. Principessous-jacents au manifeste<br />GDP avec Scrum │ © Pierre E. Neis<br />32<br />
    36. 36. Le triangle magique<br />GDP avec Scrum │ © Pierre E. Neis<br />Engagement des employés<br />Reconnus, engagés, employésheureux<br />Création de Valeur<br />Maximiser le ROI et optimiser la trésorerie<br />Satisfaction du Client<br />Servir le client<br />33<br />
    37. 37. Le Problème<br />Le métier et le développementsontsouventenfermésdans une relation malsaine.<br />Les deux partenaires doivent changer pour améliorer la satisfaction client et la création de valeur<br />GDP avec Scrum │ © Pierre E. Neis<br />34<br />
    38. 38. Contenu de Scrum<br />35<br />GDP avec Scrum │ © Pierre E. Neis<br />
    39. 39. Introduction par Ken Schwaber<br />Scrum n'est pas une méthodologie. Scrum ne fournit pas les réponses à la manière de construire des logiciels de qualité plus rapidement.<br />Scrum est un cadre dans lequel le jeu du développement de produit est joué.<br />Votre équipe joue et, le bon ou le mauvais deviennent très visibles.<br />Votreéquipeestdans un processusd’amélioration continue.<br />GDP avec Scrum │ © Pierre E. Neis<br />36<br />
    40. 40. Le principe “Pull”<br />GDP avec Scrum │ © Pierre E. Neis<br />37<br />
    41. 41. Équipes auto-géréesvsOrganisation traditionnelle<br />GDP avec Scrum │ © Pierre E. Neis<br />38<br />
    42. 42. Les Règles<br />Rôles, Artifacts et Time-boxes<br />39<br />GDP avec Scrum │ © Pierre E. Neis<br />
    43. 43. GDP avec Scrum │ © Pierre E. Neis<br />40<br />
    44. 44. 3 Rôles Scrum Team plus 3 Rôles organisationnels<br />GDP avec Scrum │ © Pierre E. Neis<br />41<br />
    45. 45. Les Rôles de l’Equipe Scrum<br />GDP avec Scrum │ © Pierre E. Neis<br />42<br />
    46. 46. Le ScrumMaster<br />GDP avec Scrum │ © Pierre E. Neis<br />43<br />
    47. 47. Sa fonction<br />Protège l’équipe des turbulences<br />Il n’est pas un membre de l’Équipe<br />Il optimise la productivité de l’Équipe<br />Il contrôle l’”Inspect-&-Adapt” de l’Équipe<br />Il assure que les idéaux “agiles” soient bien compris et respectés par tous les participants au projet.<br />Il n’est pas responsable des déliverables.<br />GDP avec Scrum │ © Pierre E. Neis<br />44<br />
    48. 48. Sa Mission<br />Protéger l’Équipe Scrum<br />Lever les obstacles<br />Exécuter le process<br />Travailler avec le Product Owner<br />Changer l’Organisation<br />GDP avec Scrum │ © Pierre E. Neis<br />45<br />
    49. 49. Le ScrumMaster<br />GDP avec Scrum │ © Pierre E. Neis<br />+ Produit<br />+ Process<br />Agir de la bonnefaçon<br />46<br />Faire bien (Produit)<br />Bonne façon<br />Gains rapides, mais insoutenable<br />Succèsdurable<br />Il forme et coache SCRUM<br />Il régule les obstacles<br />Il anime les réunions<br />Il protègel’équipe<br />Il est le gardien du process Scrum<br />Mauvaise façon<br />Echecrapide<br />Échec lent<br />Bon chemin<br />Mauvais chemin<br />
    50. 50. Le Product Owner<br />GDP avec Scrum │ © Pierre E. Neis<br />47<br />
    51. 51. Sa fonction<br />Il pilote le projet d’un point de vue métier<br />Il communique une vision claire du produit et défini ses caractéristiques<br />Il accepte ou rejette le produit à la fin de chaque Sprint<br />Il s’assure que l’Équipe se concentre sur les items du Backlog de plus forte valeur ajoutée<br />Il a le même objectif que l’Équipe<br />Il est responsable du Retour sur Investissement et des livraisons.<br />GDP avec Scrum │ © Pierre E. Neis<br />48<br />
    52. 52. Sa Mission<br />Se concentre sur le retour sur investissement<br />Construit et communique la vision<br />Entretien le Product Backlog<br />Rend compte de l’acceptance des déliverables<br />Établi et maintien le Plan de Livraison<br />GDP avec Scrum │ © Pierre E. Neis<br />49<br />
    53. 53. L’Équipe<br />GDP avec Scrum │ © Pierre E. Neis<br />50<br />
    54. 54. Sa fonction<br />Elle délivre le produit et elle est responsable de sa qualité<br />Elle travaille avec les utilisateurs-finaux, le client, le Product Owner pour comprendre les exigences-métier.<br />Elle s’engage volontairement<br />Elle travaille continuellement avec le Product Owner pour définir la direction stratégique du Produit.<br />GDP avec Scrum │ © Pierre E. Neis<br />51<br />
    55. 55. Constituer l’Équipe<br />5/9 personnes<br />Multidisciplinaire<br />Autogérée<br />Cross-fonctionnelle / transverse<br />Plus orientée compétence que fonction<br />GDP avec Scrum │ © Pierre E. Neis<br />52<br />
    56. 56. Constitution de l’Équipe<br />GDP avec Scrum │ © Pierre E. Neis<br />Product Owner<br />Chef de Produit<br />MOA<br />Analyste Métier<br />Chef de Projet fonctionnel<br />Scrum Master<br />Architecte<br />Tout le monde. Pas une autorité.<br />Pas nécessairement un développeur.<br />The Team<br />Développeur<br />DBA<br />Analyste<br />Testeur<br />53<br />
    57. 57. Tuckman: les phases de dévelopement<br />© Bruce Tuckman 'Forming Storming' concept 1965. Diagram Alan Chapman<br />GDP avec Scrum │ © Pierre E. Neis<br />54<br />
    58. 58. Comment optimiser le travail de l’Équipe... <br />Créer une règle de vie de l’Équipe<br />Ne jamais utiliser le “VOUS”<br />Être à l’heure<br />Utiliser un “bâton de parole”<br />Ne jamais être nominatif<br />GDP avec Scrum │ © Pierre E. Neis<br />55<br />
    59. 59. Collaboration<br />Le Product Owner n’est pas un ennemi<br />D’autres équipes ont besoin de savoir que nous avons besoin d’elles.<br />Nous avons tous le même objectif<br />Une Équipe = un espace dédié à l’Équipe<br />GDP avec Scrum │ © Pierre E. Neis<br />56<br />
    60. 60. Sa Mission<br />Garantir la Qualité<br />Livrer<br />Livrer<br />Livrer<br />Estimer<br />Estimer<br />Estimer<br />S’engager<br />S’autogérer<br />S’organiser .... Elle-même<br />GDP avec Scrum │ © Pierre E. Neis<br />57<br />
    61. 61. Les Rôles Organisationnels<br />GDP avec Scrum │ © Pierre E. Neis<br />58<br />
    62. 62. Le Client<br />GDP avec Scrum │ © Pierre E. Neis<br />59<br />
    63. 63. Sa fonction<br />Il demande le produit<br />Il contracte l’organisation pour le développement de son produit<br />Typiquement, il s’agit d’un responsable qui achète un développement de produit par un sous-traitant.<br />Dans les projets internes, il s’agit principalement du sponsor au projet, c’est à dire la personne validant le projet et le budget.<br />GDP avec Scrum │ © Pierre E. Neis<br />60<br />
    64. 64. Sa Mission<br />Il commande le produit<br />Il paye le développement du produit<br />Il donne des feed-back et des révisions<br />GDP avec Scrum │ © Pierre E. Neis<br />61<br />
    65. 65. Le Manager<br />GDP avec Scrum │ © Pierre E. Neis<br />62<br />
    66. 66. Sa fonction<br />Le 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.<br />Le manager donne de la structure et de la stabilité.<br />Il travaille de concert avec le ScrumMaster pour réorganiser l’organigramme de la structure et donner de la guidance si nécessaire.<br />GDP avec Scrum │ © Pierre E. Neis<br />63<br />
    67. 67. Sa Mission<br />Il s’assure que l’organisation puisse survivre en cas de défaillance.<br />Il crée des règles et des lignes directrices.<br />GDP avec Scrum │ © Pierre E. Neis<br />64<br />
    68. 68. L’Utilisateur Final<br />GDP avec Scrum │ © Pierre E. Neis<br />65<br />
    69. 69. Sa fonction<br />Ce rôle peut être joué par un grand nombre de personnes.<br />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.<br />GDP avec Scrum │ © Pierre E. Neis<br />66<br />
    70. 70. Sa Mission<br />Il connaît ses besoins et ses exigences<br />Il donne son feed-back lors des revues<br />Il participe au Sprint Planning 1<br />GDP avec Scrum │ © Pierre E. Neis<br />67<br />
    71. 71. Comment ces rôles travaillent-ils ensemble?<br />GDP avec Scrum │ © Pierre E. Neis<br />68<br />
    72. 72. Rôles organisationnels<br />Scrum Team Roles<br />GDP avec Scrum │ © Pierre E. Neis<br />69<br />
    73. 73. Le ScrumMaster travaille avec le Product Owner<br />GDP avec Scrum │ © Pierre E. Neis<br />70<br />
    74. 74. Le ScrumMaster travaille avec la Development Team<br />GDP avec Scrum │ © Pierre E. Neis<br />71<br />
    75. 75. Le Product Owner travaille avec le client<br />GDP avec Scrum │ © Pierre E. Neis<br />72<br />
    76. 76. La Development Team travaille avec l’utilisateur final<br />GDP avec Scrum │ © Pierre E. Neis<br />73<br />
    77. 77. Le ScrumMaster travaille avec le Manager<br />GDP avec Scrum │ © Pierre E. Neis<br />74<br />
    78. 78. Le Product Owner a besoin de connaître ce que le marché (l’utilisateur final) souhaite.<br />GDP avec Scrum │ © Pierre E. Neis<br />75<br />
    79. 79. Question?<br />Quels problèmes avez-vous dans cet exemple si le ScrumMaster est membre de l’Équipe?<br />GDP avec Scrum │ © Pierre E. Neis<br />Compagnie PORTAL (USA)<br /><ul><li> 5 Product Owners</li></ul> (News, Email, Produits, Sécurité, Infrastructure)<br /><ul><li> 1 Equipe Scrum de développement
    80. 80. 1 Produit intégré (Portail)</li></ul>76<br />
    81. 81. Références<br />GDP avec Scrum │ © Pierre E. Neis<br />77<br />
    82. 82. Les Artefacts<br />78<br />GDP avec Scrum │ © Pierre E. Neis<br />
    83. 83. 4 Artefacts<br />79<br />GDP avec Scrum │ © Pierre E. Neis<br />
    84. 84. Exercice<br />GDP avec Scrum │ © Pierre E. Neis<br />80<br />
    85. 85. Modèle<br />Je 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.…<br />GDP avec Scrum │ © Pierre E. Neis<br />Sécurisation des InformationsPersonnelles<br />Source: Mike Cohn, CSPO<br />81<br />
    86. 86. User Stories<br />En tantque[rôleUtilisateur]<br />Je veuxune[FONCTIONNALITE]<br />De sorteque je reçois[BUSINESS VALUE].<br />GDP avec Scrum │ © Pierre E. Neis<br />82<br />
    87. 87. User Story Card<br />Une brève description textuelle des exigences<br />+ Risques<br />+ critèresd’acceptation<br />AS A Product Owner<br />I CAN / I WANT estimate Costs<br />3 lines of Requirement Description<br />GDP avec Scrum │ © Pierre E. Neis<br />83<br />
    88. 88. Les bonnes Stories sont INVEST<br />GDP avec Scrum │ © Pierre E. Neis<br />84<br />
    89. 89. Exercice<br />GDP avec Scrum │ © Pierre E. Neis<br />85<br />
    90. 90. Le Product Backlog?<br />Priorité haute<br />Le Backlog est une liste de tâches ouvertes comme :<br /><ul><li>les exigences
    91. 91. une liste de tous les travauxsouhaités pour le projet
    92. 92. Idéalement exprimé de telle sorte que chaque objet a une valeur pour les utilisateurs ou les clients du produit
    93. 93. Priorisé par le Product Owner
    94. 94. Repriorisé au début de chaque Sprint</li></ul>Sprint<br />Priorité moyenne<br />Release<br />Releases futures<br />GDP avec Scrum │ © Pierre E. Neis<br />86<br />
    95. 95. Le Product Backlog<br />GDP avec Scrum │ © Pierre E. Neis<br /><ul><li>Le Product Backlog répond aux questions suivantes:</li></ul>Quoi? Quand? Pour Qui?<br />87<br />
    96. 96. Stories, themes and epics<br />GDP avec Scrum │ © Pierre E. Neis<br />USER STORY:<br />Une description de la fonctionnalité désirée du point de vue du l'utilisateur ou du client<br />THEME:<br />Un recueil de stories<br />EPIC:<br />Une grande story<br />88<br />
    97. 97. Sprint Backlog<br />89<br />GDP avec Scrum │ © Pierre E. Neis<br />
    98. 98. Release Burn down Chart<br />Example de Burndown Chart (Schwaber and Beedle 2002)<br />Le Release burndown rend les tendances des progrès visibles.<br />Le rapport estbasésur les informationssuivantes:<br />• le reste-à-faire du Product Backlog pour transformer la Vision en un produitgagnant.<br />• Le nombre de Sprints nécessairesourestants.<br />• La vélocité.<br />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.<br />90<br />GDP avec Scrum │ © Pierre E. Neis<br />
    99. 99. Sprint Burn-down Charts<br />Le Sprint Burn-down chart montre<br />combien d'efforts a été déployé en travaillant sur la tâche contenue dans le Sprint Backlog<br />Et compare cela à la depenseidéale<br />Le tableau donne une tendance qui indique si l'équipe est susceptible de respecter son engagement (indicateur avancé)<br />91<br />GDP avec Scrum │ © Pierre E. Neis<br />
    100. 100. Les supports de cours<br />disponibles sur le wiki suivant:<br />Les supports de cours<br />Les liens vers les sites de référence<br />Les photos prises lors de la session<br />Des outils Scrum téléchargeables<br />Le Wiki permettra également de poursuivre votre formation au-delà de ces 3 journées:<br />Nous partagerons nos adresses<br />Vous pourrez me contacter pour toute question lors de votre mise en “production” par ce biais.<br />Le Wiki est une zone d’échange privée et les droits seront gérés par votre serviteur.<br />GDP avec Scrum │ © Pierre E. Neis<br />http://scrumcenterlux.pbworks.com<br />92<br />
    101. 101. Les Time-boxes<br />93<br />GDP avec Scrum │ © Pierre E. Neis<br />
    102. 102. Au niveau stratégique<br />GDP avec Scrum │ © Pierre E. Neis<br />94<br />
    103. 103. Estimation Meeting<br />- Préparation du Sprint Planning<br />- Estimation formelle<br />- Passez au moins deux réunions par Sprint<br />- Estimeruniquementsur la taille et le temps<br />GDP avec Scrum │ © Pierre E. Neis<br />> Input pour Release Planning<br />95<br />
    104. 104. Au niveau tactique<br />GDP avec Scrum │ © Pierre E. Neis<br />96<br />
    105. 105. Les Meetings<br />Le Quoi?<br />Le Comment?<br />La Synchronisation<br />Les Résultats<br />L’Amélioration<br />GDP avec Scrum │ © Pierre E. Neis<br />97<br />
    106. 106. Sprint Planning 2<br />Revue de Sprint<br />Rétrospective<br />Sprint Planning 1<br />Sprint Planning 2<br />Sprint Planning 1<br />SPRINT<br />Daily Meetings<br />GDP avec Scrum │ © Pierre E. Neis<br />98<br />
    107. 107. Sprint Planning Meeting<br />Organisateur: Product Owner<br />Participants: l’équipe (actif), le ScrumMaster (passif)<br />Durée: 8 heures pour un Sprint de 4 semaines<br />GDP avec Scrum │ © Pierre E. Neis<br /><ul><li>2 parties:
    108. 108. Le QUOI?
    109. 109. Le COMMENT?
    110. 110. Le Product Owner:
    111. 111. Présente le Product Backlog priorisé par le client et/ou les utilisateurs
    112. 112. Présente le Release Plan Initial
    113. 113. Présentation de la Vision
    114. 114. L’équipe:
    115. 115. Estime le Product Backlog en fonction de sa faisabilité (estimation fonctionelle)
    116. 116. Découpe le Product Backlog en Sprint Backlogs avec le Product Owner
    117. 117. Découpe le Sprint Backlog en tâches
    118. 118. Estime le Sprint Backlog
    119. 119. Le Product Owner et l’Equipe:
    120. 120. Définissent l’objectif du Sprint
    121. 121. Valident la Definition of Done</li></ul>99<br />
    122. 122. Pour chaque Item du Product Backlog (US)<br />Quelle interface devons-nous designer?<br />Quelle architecture devons-nous créer?<br />Quelles tables devons-nous actualiser?<br />Quels composants devons-nous mettre à jour ou créer?<br />GDP avec Scrum │ © Pierre E. Neis<br />Sprint<br />Planning<br /> 2<br />Design<br />100<br />
    123. 123. Definition of Done<br />GDP avec Scrum │ © Pierre E. Neis<br />101<br />
    124. 124. Level of Done<br />Le Code est conforme aux normes<br />Le Code est<br /><ul><li>Propre
    125. 125. Refactoré
    126. 126. Testéunitairement
    127. 127. Validé (checked in)
    128. 128. Intégré (Built)
    129. 129. Dispose d'une suite de test unitaire qui lui est appliquée.</li></ul>Pour arriver à cela, l’environnement de développementestconstitué :<br /><ul><li>D’unebibliothèque de code source
    130. 130. De codes standards,
    131. 131. Build automatisé,
    132. 132. D’un environnement pour les tests unitaires.</li></ul>GDP avec Scrum │ © Pierre E. Neis<br />Pour l’EQUIPE<br />102<br />
    133. 133. Definition of Done<br />Une Story/Item est “done” lorsque l’équipe a atteint son Level of Done<br />Le Sprint/itérationest “done” lorsque<br />tous les items sont “done” <br />et que le Sprint atteint son objectif<br />et que les critèresd’acceptationsontadressés.<br />La Release est “done”<br /><ul><li>“done” pour l’intégration
    134. 134. “done” pour la production</li></ul>GDP avec Scrum │ © Pierre E. Neis<br />Pour SCRUM<br />103<br />
    135. 135. Half done is not done<br />GDP avec Scrum │ © Pierre E. Neis<br />104<br />
    136. 136. Daily Scrum<br />Synchronisation / Engagement sur les tâches<br />GDP avec Scrum │ © Pierre E. Neis<br />105<br />
    137. 137. Daily Scrum<br />Organisateur: l’équipe<br />Participants: l’équipe (actif), le ScrumMaster (passif), Product Owner (passif)<br />Durée: 15 min<br />GDP avec Scrum │ © Pierre E. Neis<br /><ul><li>C’est l’inspect-and-adapt de l’équipe: synchronisation et engagement
    138. 138. Les 3 questions:</li></ul>Qu’est-ce que tu as fait hier?<br />Quels sont les problèmes que tu as rencontrés?<br />Qu’est-ce que tu as prévu aujourd’hui?<br />106<br />
    139. 139. Sprint Review<br />Analyse des résultats<br />GDP avec Scrum │ © Pierre E. Neis<br />107<br />
    140. 140. La Revue de Sprint<br />Organisateur: Product Owner<br />Participants: l’équipe (actif), le ScrumMaster (passif), le Management (actif), le client (actif), les utilisateurs (actifs)<br />Durée: 4 heures pour un Sprint de 4 semaines<br />GDP avec Scrum │ © Pierre E. Neis<br /><ul><li>C’est l’inspect-and-adapt des utilisateurs, du client et du management
    141. 141. L’équipe présente les résultats du Sprint
    142. 142. Utilisateurs/Client/ Management expriment leurs remarques et trouvent un compromis avec l’équipe
    143. 143. Le Product Owner valide ou rejète les items du Sprint Backlog en fonction de la Definition of Done
    144. 144. C’est le Product Owner qui a toujours le dernier mot...</li></ul>108<br />
    145. 145. Quand un membre de l'équipe dit « DONE", ça veut dire quoi?<br />Le code est conforme aux normes, est propre, a été re-factoré, a été testé unitairement, a été vérifiée, a été built, et a eu une suite de tests unitaires qui lui est appliquée.<br />Dispose d’un environnement de développement, pour cela il faut une bibliothèque de codes source, des normes de codage, des builts automatisés, et un environnement de tests unitaires<br />GDP avec Scrum │ © Pierre E. Neis<br />109<br />LOD!<br />
    146. 146. Sprint Review<br />Présentation (par l’équipe)<br />Feedback (par l’utilisateur final)<br />C’est l’inspect-&-adapt de l’utilisateur permettant la création ou le changement des items du Product Backlog<br />GDP avec Scrum │ © Pierre E. Neis<br />110<br />
    147. 147. Validation du Sprint<br />GDP avec Scrum │ © Pierre E. Neis<br />111<br />
    148. 148. Rétrospective<br />Analyse des résultats<br />GDP avec Scrum │ © Pierre E. Neis<br />112<br />
    149. 149. La Rétrospective<br />Organisateur: ScrumMaster<br />Participants: l’équipe (actif), le ScrumMaster (actif), le Product Owner (actif en sa qualité de membre de l’équipe)<br />Durée: 3 heures pour un Sprint de 4 semaines<br />GDP avec Scrum │ © Pierre E. Neis<br /><ul><li>Analyse du Process Scrum:
    150. 150. Comment cela c’est passé pendant le Sprint
    151. 151. Comment s’améliorer
    152. 152. Points principaux de vérification:
    153. 153. La communication dans l’équipe
    154. 154. Les relations entre les membres de l’équipe
    155. 155. Les process et les outils
    156. 156. Les besoins en formation</li></ul>113<br />
    157. 157. Rétrospective<br />Nous faisons un point après l’action en nous posant deux questions:<br />Qu’est-ce qui a bien fonctionné?<br />Que devons-nous améliorer?<br />Objectifs:<br />Apprendre du passé pour préparer l’avenir<br />Améliorer la productivité de l’équipe<br />GDP avec Scrum │ © Pierre E. Neis<br />114<br />
    158. 158. Finalité de la Rétrospective<br />Debriefing<br />Amélioration<br />Comprendre la réalité<br />Apprendre<br />“Input” pour le Sprint Planning<br />GDP avec Scrum │ © Pierre E. Neis<br />Où allons-nous à partir d’ici?<br />115<br />
    159. 159. Démarrer un projet scrum<br />GDP avec Scrum │ © Pierre E. Neis<br />116<br />
    160. 160. Nous avons un projet!<br />Un projet repose sur 2 piliers:<br />Un produit<br />Un process<br />GDP avec Scrum │ © Pierre E. Neis<br />117<br />
    161. 161. … dans Scrum?<br />GDP avec Scrum │ © Pierre E. Neis<br />118<br />
    162. 162. Product Life Cycle <br />Project<br />Project<br />Project<br />Project<br />Project<br />Project<br />Project<br />Project<br />GDP avec Scrum │ © Pierre E. Neis<br />119<br />
    163. 163. Scrum<br />GDP avec Scrum │ © Pierre E. Neis<br />120<br />
    164. 164. GDP avec Scrum │ © Pierre E. Neis<br />121<br />
    165. 165. Scrum Project Management Process<br />GDP avec Scrum │ © Pierre E. Neis<br />122<br />
    166. 166. Project Charter<br />GDP avec Scrum │ © Pierre E. Neis<br />123<br />
    167. 167. Définirune vision partagée<br />Les équipesperformentmieuxlorsqu’ellesontune vision, un objectif “clair et motivant”, un “engagement unique”<br />C’est le travail du Product Owner de s’assurerde concentrer l'équipe et trouver cet objectif clair et engageant.<br />Quelquesoutils pour établircette vision:<br />GDP avec Scrum │ © Pierre E. Neis<br />Elevator Statement<br />Press Release<br />Product Data Sheet<br />Magazine Review<br />Product Vision Box<br />Source: Teamwork by Carl Larson and Franck LaFasto and Agile Project Management by Jim Highsmith<br />124<br />
    168. 168. Comment construire une vision puissante?<br />For<target customer><br />who<statement of the need or opportunity><br />the<product name> is<br />a<product category><br />that<key benefit, compelling reason to buy><br />unlike<primary competitive alternative><br />our product <statement of primary differentiation><br /><ul><li>Un brefénoncé du positionnementproduit
    169. 169. Explique le produit à quelqu’un en 2 minutes
    170. 170. Suit cettesynthaxe</li></ul>GDP avec Scrum │ © Pierre E. Neis<br />125<br />
    171. 171. Exempled’elevatorstatement<br />For dentists and their assistants<br />Who need to efficiently schedule appointments<br />Dental Clinic 2.0 is desktop and web-based<br />appointment scheduling software<br />That supports office and remote access.<br />Unlike all competitors<br />Dental Clinic 2.0 is easy to use.<br />GDP avec Scrum │ © Pierre E. Neis<br />126<br />
    172. 172. Product vision box<br />Dessineruneboîte pour votreprojet<br />Mêmesi le produit de votreprojet ne sera pas distribuédansuneboîte<br />Ecrire 3-4 bullet points pour vendre le produit<br />GDP avec Scrum │ © Pierre E. Neis<br />127<br />
    173. 173. Press release to come / Magazine Review<br />Ecrivrecollaborativement un article de presse: celuiquevousaimerieztrouverunefoisvotreproduitlivré<br />Quels sont les points clés que vous donneriez sur le produit?<br />Quellesréférencessouhaiteriez-voustrouver? De votre direction? Des membres de l’équipe? De vos clients?<br />GDP avec Scrum │ © Pierre E. Neis<br />128<br />
    174. 174. User Stories<br />2 parties :<br />lesUser<br />lesStory<br />En tantque Product Owner, vous représentez l'utilisateur et hiérarchiser leurs besoins<br />Impliquez-les le plus possible<br />Pensez à tous les utilisateurs de votre système<br />GDP avec Scrum │ © Pierre E. Neis<br />129<br />
    175. 175. User roles<br />Élargir le scope du point de vue d’un seulutilisateur<br />Permet à l’utilisateur de variersont point de vue en fonction de:<br />L’utilisation du logiciel<br />Quelslogicielsilutilise<br />Background<br />Son aisancedansl’utilisation des logiciels/ ordinateurs<br />Largement utilisé dans la conception centrée utilisateur<br />GDP avec Scrum │ © Pierre E. Neis<br />130<br />
    176. 176. Attributscommuns<br />GDP avec Scrum │ © Pierre E. Neis<br />Infrequent vacation planner<br />Wants to schedule her family’s annual vacation<br />Frequent flyer who never knows where she’ll be<br />Frequent flyer<br />Frequent flyer who flies everywhere but always to the same place<br />Insider<br />Scheduler<br />Hotel chain Vice President; wants to monitor reservations<br />A frequent flyer’s assistant; books her reservations<br />Repeat Traveler<br />131<br />
    177. 177. Prioritisation sur la Business Value<br /><ul><li>2 dimensions:
    178. 178. IN ou OUT
    179. 179. Séquence
    180. 180. Les facteursclés
    181. 181. remplir les critères de la Vision
    182. 182. Doitêtre utile au client
    183. 183. Apporter de la valeur
    184. 184. Réduire les coûts
    185. 185. Risques, incertitudes
    186. 186. Dependences:
    187. 187. Au projet
    188. 188. Aux entrées du Product Backlog
    189. 189. Releasability</li></ul>GDP avec Scrum │ © Pierre E. Neis<br />132<br />
    190. 190. Stocking the Backlog<br />GDP avec Scrum │ © Pierre E. Neis<br />133<br />
    191. 191. Trier les US en Epic & Themes<br />GDP avec Scrum │ © Pierre E. Neis<br />INVEST valide les US<br />134<br />
    192. 192. Stocking leProductBacklog<br />GDP avec Scrum │ © Pierre E. Neis<br />Outils & Techniques<br /><ul><li>Requirements Workshops
    193. 193. Story Mapping</li></ul>Ex. Story Mapping<br />135<br />
    194. 194. Afiner le Product Backlog<br />Prioritisation<br />Complétudefonctionnelle<br />Risques& incertitudes<br />Nécessitésévidentes<br />Dépendances<br />GDP avec Scrum │ © Pierre E. Neis<br /><ul><li>Qu’est-cequ’unepriorité haute?
    195. 195. Claire
    196. 196. Testable
    197. 197. Faisable</li></ul>just enough, just in time<br />136<br />
    198. 198. Grooming le Product Backlog<br />GDP avec Scrum │ © Pierre E. Neis<br />C'est un processuscontinu :<br /><ul><li>de nouvellesexigencessontdécouvertes et détaillées
    199. 199. Le Product Backlog estpriorisé
    200. 200. Les prioritéshautessontpréparées pour le Sprint Planning Meeting
    201. 201. Les exigencessontestimées</li></ul>Grooming, c’est:<br /><ul><li>Collaboratif
    202. 202. La Scrum Team alloue 10% de son activité pour le grooming</li></ul>137<br />
    203. 203. L’approche DEEP<br />Detailed appropriately<br />Emergent<br />Estimated<br />Pioritised<br />GDP avec Scrum │ © Pierre E. Neis<br />Priorisation du Product Backlog et niveaux de détails<br />N'hésitez pas à affiner « davantage » les hautes priorités pour la planification du prochain Sprint<br />138<br />
    204. 204. Grooming, quand?<br />Option 1: <br />Daily Grooming avec la Scrum Team<br />Après le Daily Scrum Meeting (si la Scrum Team estOK)<br />GDP avec Scrum │ © Pierre E. Neis<br /><ul><li>Option 2:
    205. 205. Grooming hebdomadaire avec la Scrum Team
    206. 206. Préparez Grooming Meeting
    207. 207. Option 3:
    208. 208. A la fin du Sprint
    209. 209. Ouidéalement un jour avant la fin du Sprint</li></ul>139<br />
    210. 210. Product Backlog Refactoring<br />Réévaluer les prioritéscalculéesdans le Product Backlog.<br />Afiner le Product Backlog en fonction des nouvellespriorités.<br />Assurer que le Backlog est prêt pour le prochain Sprint, idéalement 2 Sprints d’avance.<br />Avoir la Dev. Team disponible 10% du temps alloué pour le Sprint pour cetteactivité.<br />La De. Team ne devraitjamaislaisser le Product Owner aller au Sprint Planning Meeting sans avoirgroomé (entretenu) son Product Backlog.<br />GDP avec Scrum │ © Pierre E. Neis<br />140<br />
    211. 211. Product Backlog - Résumé<br />La création du P/B: répond à ces questions:<br />Quoi? Quand? Pour qui?<br />Management du P/B<br />Nettoyer le Backlog des fonctionnalitésinutilisées<br />(celles-cipeuventêtreajoutéesultérieurementsicela fait sens)<br />Gardez à l’esprit: est-cevraimentnécessaire?<br />Pour les Meetings de Backlog: transcriresur des cartes et coller. (Post-its ouBristols)<br />GDP avec Scrum │ © Pierre E. Neis<br />141<br />
    212. 212. GDP avec Scrum │ © Pierre E. Neis<br />142<br />
    213. 213. Comment implementerscrum?<br />143<br />GDP avec Scrum │ © Pierre E. Neis<br />
    214. 214. Sponsor<br />Chercher un Sponsor le plus haut possible dans la hiérarchie permet de garantir la bonne mise en place du processus de changement.<br />144<br />GDP avec Scrum │ © Pierre E. Neis<br />
    215. 215. Initier<br />Avancer seul sur un projet de changement est plus que risqué. Faites-vous aider par une ressource externe.<br />145<br />GDP avec Scrum │ © Pierre E. Neis<br />
    216. 216. Enflammer<br />Allumez votre première balise et enflammez ensuite le développement.<br />146<br />GDP avec Scrum │ © Pierre E. Neis<br />
    217. 217. Diversité<br />Allumez davantage de balises en diversifiant le nombres des acteurs de votre projet.<br />147<br />GDP avec Scrum │ © Pierre E. Neis<br />
    218. 218. Promouvoir<br />Faites savoir et partagez votre expérience. Vous et votre équipe êtes les promoteurs de Scrum au sein de votre organisation. Allumez encore plus de balises.<br />148<br />GDP avec Scrum │ © Pierre E. Neis<br />
    219. 219. Professionnaliser<br />En adoptant une attitude « Scrum », vous engager un processus d’amélioration continue et de montée en compétence de votre organisation. Créez un Centre de Compétence.<br />149<br />GDP avec Scrum │ © Pierre E. Neis<br />
    220. 220. Etablir<br />Définir Scrum comme option officielle.<br />150<br />GDP avec Scrum │ © Pierre E. Neis<br />
    221. 221. Consolider<br />Faites une transition vers une Entreprise Agile<br />151<br />GDP avec Scrum │ © Pierre E. Neis<br />
    222. 222. Intégrer<br />Construisez une gouvernance IT.<br />152<br />GDP avec Scrum │ © Pierre E. Neis<br />
    223. 223. Le mot de la fin<br />Ayez toujours sur vous votre « Sac Agile »<br />
    224. 224. Demander à l’équipe<br />154<br />GDP avec Scrum │ © Pierre E. Neis<br />
    225. 225. Inspecter & Adapter<br />155<br />GDP avec Scrum │ © Pierre E. Neis<br />
    226. 226. Livrer tous les 30 jours<br />156<br />GDP avec Scrum │ © Pierre E. Neis<br />
    227. 227. Traiter les personnes comme des adultes<br />157<br />GDP avec Scrum │ © Pierre E. Neis<br />

    ×