Téléchargé 591 fois
![User Stories
• En tant que [rôle Utilisateur]
• Je veux une [FONCTIONNALITE]
• De sorte que je reçois [BUSINESS VALUE].
GDP avec Scrum │ © Pierre E. Neis 81](https://image.slidesharecdn.com/gestiondeprojetsagilesavecscrumactiskills-111209051301-phpapp02/75/Gestion-de-projets-agiles-avec-scrum-actiskills-81-2048.jpg)
Téléchargé parPierre E. NEIS
Gestion de projets agiles avec scrum actiskills
Le document présente une formation sur la gestion de projets agiles utilisant Scrum, avec des explications des rôles, artefacts et processus associés. Il souligne l'importance de la collaboration, de la transparence et de l'adaptation dans un environnement de développement. Enfin, il aborde les principes du manifeste agile et propose des méthodes pour assurer la qualité et l'efficacité du travail d'équipe.
Contenu connexe
Similaire à Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
- 1. Gestion de projetsagiles avec Scrum Cycle de formation « base »
- 2. Pierre NEIS • ScrumCoach http://managingagile.blogspot.com/ GDP avec Scrum │ © Pierre E. Neis 2
- 3. GDP avec Scrum│ © Pierre E. Neis 3
- 4. Les règles dujeu GDP avec Scrum │ © Pierre E. Neis 4
- 5. Être à l’heure GDP avec Scrum │ © Pierre E. Neis 5
- 6. Ne pas êtredérangé GDP avec Scrum │ © Pierre E. Neis 6
- 7. Pas de GSM GDPavec Scrum │ © Pierre E. Neis 7
- 8. Ne quittez pasla pièce GDP avec Scrum │ © Pierre E. Neis 8
- 9. Pénalité don GDP avec Scrum │ © Pierre E. Neis 9
- 10. Les supports decours http://scrumcenterlux.pbworks.com • disponibles sur le wiki suivant: – Les supports de cours – Les liens vers les sites de référence – Les photos prises lors de la session – Des outils Scrum téléchargeables • Le Wiki permettra également de poursuivre votre formation au-delà de ces 3 journées: – Nous partagerons nos adresses – Vous 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. Neis 10
- 11. LE JARGON DESCRUM GDP avec Scrum │ © Pierre E. Neis 11
- 12. Le Jargon Sprint: Est une iteration Backlog: Est une liste de tâches ouvertes Product Backlog: Est une liste d’items ouverts pour livrer le produit Sprint Backlog: Est une liste de tâches ouvertes attribuées au Sprint La Development TEAM: C’est l’équipe de développement La Scrum Team: C’est la Development Team + le ScrumMaster + le Product Owner Estimation Meeting C’est la réunion d’ estimation Sprint Planning Meeting C’est la réunion de planification de Sprint Daily Scrum ou Stand-up Meeting C’est la réunion journalière de 15’ où l’EQUIPE inspecte et adapte, coordonne son effort. Sprint Review ou Revue de Sprint C’est la réunion de fin de Sprint où tous les acteurs du projet se retrouvent pour inspecter et adapter les délivrables du Sprint. Rétrospective C’est la réunion d’inspection et d’adaption de la Scrum Team. GDP avec Scrum │ © Pierre E. Neis 12
- 13. Objectif • Comprendre lesfondamentaux de Scrum • Savoir utiliser les outils de Scrum • Être en mesure de démarrer votre projet Scrum GDP avec Scrum │ © Pierre E. Neis 13
- 14. Périmètre • Historique • Lathéorie « Scrum » • La Philosophie agile GDP avec Scrum │ © Pierre E. Neis 14
- 15. „The New New „Wicked „Managing the Product Problems, „Borland „Agile Software New Product Developm Righteous Software Development Development ent Solutions“ Craftmans with Process“1984 Game“ 1990 hip“1994 Scrum“2001 Moving The First „SCRUM: A Pattern the Scrum Scrum Scrum1993 Language for Downfield Approach Hyperproductive Software Developement“1999 Historique Un rappel contextuel…. GDP avec Scrum │ © Pierre E. Neis 15
- 16. Le modèle “Grandiose”de Winston Royce Un modèle de “Phasage simple” pour faire face aux exigences règlementaires amé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 1970 GDP avec Scrum │ © Pierre E. Neis 16
- 17. Nous perdons lacourse 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é. » Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986 GDP avec Scrum │ © Pierre E. Neis 17
- 18. Une Analyse scientifique •La Question: « pourquoi les processus définis par SEI CMM (CMMI) ne mesurent-ils pas la capacité à livrer? « Controlled Chaos: living on the edge », Advanced Development Methods Inc. 1996 GDP avec Scrum │ © Pierre E. Neis 18
- 19. Une Analyse scientifique(Réponse) • Il existe 2 types de processus: – Le processus défini – Le processus empirique « Controlled Chaos: living on the edge », Advanced Development Methods Inc. 1996 GDP avec Scrum │ © Pierre E. Neis 19
- 20. Un processus défini Processus Défini •Chaque tâche doit être entièrement comprise. •Pour un même nombre d’entrées bien définies, les sorties générées sont à chaque fois identiques. GDP avec Scrum │ © Pierre E. Neis 20
- 21. Est-ce que ledéveloppement logiciel est un processus défini? GDP avec Scrum │ © Pierre E. Neis 21
- 22. Le modèle empirique Contrôles Inputs Outputs Incrément de •exigences produit •technologie Process potentiellement •équipe livrable Le modèle empirique est dépendant de fréquentes inspections et adaptations pour atteindre l’objectif. GDP avec Scrum │ © Pierre E. Neis 22
- 23. La théorie SCRUM GDP avec Scrum │ © Pierre E. Neis 23
- 24. Scrum est unprocessus empirique GDP avec Scrum │ © Pierre E. Neis 24
- 25. Scrum repose sur3 pieds Transparence Inspection Adaptation GDP avec Scrum │ © Pierre E. Neis 25
- 26. 10 Pratiques debase 1. Vision claire et partagée 2. Product Backlog entretenu 3. Product Backlog priorisé en fonction de la valeur métier 4. Items de backlog triés par la Development Team 5. Daily Scrums 6. Sprints non perturbés ni par le Management ni par le(s) client(s) 7. La Development Team ne délivre que des items « terminés » 8. Revue de Sprint collaborative 9. Rétrospective concentrée sur l’amélioration du travail et du processus de l’équipe et de l’organisation 10. Burndown Charts (graphiques de reste-à-faire) GDP avec Scrum │ © Pierre E. Neis 26
- 27. Scrum vs Modèleen “cascade” GDP avec Scrum │ © Pierre E. Neis 27
- 28. 15’ Discussion enGroupe 1 • Quels sont les problèmes que vous pouvez entrevoir dans l’approche en cascade? • Comment votre organisation gère-t-elle ces 2 problèmes à l’heure actuelle (ou dans le passé)? 3 • Identifier certains attributs de ce que serait le pire processus dans le monde et pourquoi. GDP avec Scrum │ © Pierre E. Neis 28
- 29. La Philosophie Agile L’AgileManifesto GDP avec Scrum │ © Pierre E. Neis 29
- 30. Manifeste pour ledéveloppement Agile de logiciels Les individus et leurs interactions • Des logiciels opérationnels • La collaboration avec les clients • L’adaptation au changement les processus et les outils • une documentation exhaustive • la négociation contractuelle • le suivi d’un plan 30 GDP avec Scrum │ © Pierre E. Neis
- 31. Principes sous-jacents au manifeste Priorité 1 satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. 2 Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. 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. 4 Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. 5 Réalisez les projets avec des personnes motivées. 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. 7 Un logiciel opérationnel est la principale mesure d’avancement. 8 Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. 9 Une attention continue à l'excellence technique et à une bonne conception renforcent l’Agilité. 10 La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. 11 Les meilleures architectures, spécifications et conceptions émergent d'équipes auto organisées. 12 À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. 31 GDP avec Scrum │ © Pierre E. Neis
- 32. Le triangle magique Engagement des employés Reconnus, engagés, employés heureux Création de Valeur Maximiser le ROI et Satisfaction du Client Abondance optimiser la Servir le client trésorerie GDP avec Scrum │ © Pierre E. Neis 32
- 33. Le Problème Métier (MOA) Projet Développement (MOE) • Le métier et le développement sont souvent enfermés dans une relation malsaine. • Les deux partenaires doivent changer pour améliorer la satisfaction client et la création de valeur 33 GDP avec Scrum │ © Pierre E. Neis
- 34. CONTENU DE SCRUM GDP avec Scrum │ © Pierre E. Neis 34
- 35. Introduction par KenSchwaber • 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. • 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 équipe est dans un processus d’amélioration continue. GDP avec Scrum │ © Pierre E. Neis 35
- 36. Le principe “Pull” GDP avec Scrum │ © Pierre E. Neis 36
- 37. Équipes auto-gérées vsOrganisation traditionnelle Equipes auto-gérées Organisation traditionnelle Orientées client Pilotée par le management Force de travail multi-compétente Force de travail constituée de spécialistes isolés Peu de description de postes Beaucoup de description de poste Information largement partagée Information limitée Peu de niveau de management De npmbreux niveaux de management Orientée Ensemble du Métier Orientée fonction/département Objectifs partagés Objectifs séparés D’apparence chaotique D’apparence organisée Emphatique sur l’hypothèse d’atteinte un résultat Emphatique sur la résolution de problème Très fort engagement des “producteurs” Très fort engagement du Management Améliorations continues Améliorations incrémentales Autorégulées Contrôlées par le Management Basées sur des valeurs et des principes Basées sur les politiques et les procédures Source: "Leading self-directed work teams" by Kimball Fisher. Traduction libre Pierre NEIS. GDP avec Scrum │ © Pierre E. Neis 37
- 38. Les Règles Rôles, Artifactset Time-boxes GDP avec Scrum │ © Pierre E. Neis 38
- 39. GDP avec Scrum│ © Pierre E. Neis 39
- 40. 3 Rôles ScrumTeam plus 3 Rôles organisationnels Les Rôles de l’Équipe Scrum • La Development • Le Team Les Rôles organisationnels Management • Le Client • Le ScrumMaster • Les Utilisateurs • Le Product Owner GDP avec Scrum │ © Pierre E. Neis 40
- 41. Les Rôles dela Scrum Team GDP avec Scrum │ © Pierre E. Neis 41
- 42. Le ScrumMaster GDP avec Scrum │ © Pierre E. Neis 42
- 43. Sa fonction • Protègel’équipe des turbulences • Il n’est pas un membre de l’Équipe • Il optimise la productivité de l’Équipe • Il contrôle l’”Inspect-&-Adapt” de l’Équipe • Il 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. Neis 43
- 44. Sa Mission • Protégerl’Équipe Scrum • Lever les obstacles • Exécuter le process • Travailler avec le Product Owner • Changer l’Organisation GDP avec Scrum │ © Pierre E. Neis 44
- 45. Le ScrumMaster Agir dela bonne façon + Produit Faire bien (Produit) + Process • Il forme et coache SCRUM • Il régule les obstacles • Il anime les réunions • Il protège l’équipe • Il est le gardien du process Scrum GDP avec Scrum │ © Pierre E. Neis 45
- 46. Le Product Owner GDP avec Scrum │ © Pierre E. Neis 46
- 47. Sa fonction • Ilpilote le projet d’un point de vue métier • Il communique une vision claire du produit et défini ses caractéristiques • Il accepte ou rejette le produit à la fin de chaque Sprint • Il s’assure que l’Équipe se concentre sur les items du Backlog de plus forte valeur ajoutée • Il a le même objectif que l’Équipe • Il est responsable du Retour sur Investissement et des livraisons. GDP avec Scrum │ © Pierre E. Neis 47
- 48. Sa Mission • Seconcentre sur le retour sur investissement • Construit et communique la vision • Entretien le Product Backlog • Rend compte de l’acceptance des déliverables • Établi et maintien le Plan de Livraison GDP avec Scrum │ © Pierre E. Neis 48
- 49. La Development Team GDP avec Scrum │ © Pierre E. Neis 49
- 50. Sa fonction • Elledé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 volontairement • Elle travaille continuellement avec le Product Owner pour définir la direction stratégique du Produit. GDP avec Scrum │ © Pierre E. Neis 50
- 51. Constituer l’Équipe • 5/9personnes • Multidisciplinaire • Autogérée • Cross-fonctionnelle / transverse • Plus orientée compétence que fonction GDP avec Scrum │ © Pierre E. Neis 51
- 52. Constitution de l’Équipe Chef de Produit Product Owner MOA Analyste Métier Chef de Projet fonctionnel Scrum Master Architecte Tout le monde. Pas une autorité. Pas nécessairement un développeur. Développeur The Team DBA Analyste Testeur GDP avec Scrum │ © Pierre E. Neis 52
- 53. Tuckman: les phasesde dévelopement © Bruce Tuckman 'Forming Storming' concept 1965. Diagram Alan Chapman 53 GDP avec Scrum │ © Pierre E. Neis
- 54. Comment optimiser letravail de l’Équipe... • Créer une règle de vie de l’Équipe • Ne jamais utiliser le “VOUS” • Être à l’heure • Utiliser un “bâton de parole” • Ne jamais être nominatif GDP avec Scrum │ © Pierre E. Neis 54
- 55. Collaboration • Le ProductOwner n’est pas un ennemi • D’autres équipes ont besoin de savoir que nous avons besoin d’elles. • Nous avons tous le même objectif • Une Équipe = un espace dédié à l’Équipe GDP avec Scrum │ © Pierre E. Neis 55
- 56. Sa Mission • Garantir la Qualité • Livrer • Livrer • Livrer • Estimer • Estimer • Estimer • S’engager • S’autogérer • S’organiser .... Elle-même GDP avec Scrum │ © Pierre E. Neis 56
- 57. Les Rôles Organisationnels GDP avec Scrum │ © Pierre E. Neis 57
- 58. Le Client GDP avecScrum │ © Pierre E. Neis 58
- 59. Sa fonction • Ildemande le produit • Il contracte l’organisation pour le développement de son produit • Typiquement, 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. Neis 59
- 60. Sa Mission • Ilcommande le produit • Il paye le développement du produit • Il donne des feed-back et des révisions GDP avec Scrum │ © Pierre E. Neis 60
- 61. Le Manager GDP avecScrum │ © Pierre E. Neis 61
- 62. Sa fonction • Lemanagement, 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. Neis 62
- 63. Sa Mission • Ils’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. Neis 63
- 64. L’Utilisateur Final GDPavec Scrum │ © Pierre E. Neis 64
- 65. Sa fonction • Cerô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. Neis 65
- 66. Sa Mission • Ilconnaît ses besoins et ses exigences • Il donne son feed-back lors des revues • Il participe au Sprint Planning 1 GDP avec Scrum │ © Pierre E. Neis 66
- 67. COMMENT CES RÔLES TRAVAILLENT-ILSENSEMBLE? GDP avec Scrum │ © Pierre E. Neis 67
- 68. Rôles organisationnels Scrum Team Roles GDP avec Scrum │ © Pierre E. Neis 68
- 69. Le ScrumMaster travailleavec le Product Owner GDP avec Scrum │ © Pierre E. Neis 69
- 70. Le ScrumMaster travailleavec la Development Team GDP avec Scrum │ © Pierre E. Neis 70
- 71. Le Product Ownertravaille avec le client GDP avec Scrum │ © Pierre E. Neis 71
- 72. La Development Teamtravaille avec l’utilisateur final GDP avec Scrum │ © Pierre E. Neis 72
- 73. Le ScrumMaster travailleavec le Manager GDP avec Scrum │ © Pierre E. Neis 73
- 74. Le Product Ownera besoin de connaître ce que le marché (l’utilisateur final) souhaite. GDP avec Scrum │ © Pierre E. Neis 74
- 75. Compagnie PORTAL (USA) •5 Product Owners (News, Email, Produits, Sécurité, Infrastructure) • 1 Equipe Scrum de développement • 1 Produit intégré (Portail) Question? Quels problèmes avez-vous dans cet exemple si le ScrumMaster est membre de l’Équipe? GDP avec Scrum │ © Pierre E. Neis 75
- 76. Références GDP avec Scrum│ © Pierre E. Neis 76
- 77. LES ARTEFACTS GDP avec Scrum │ © Pierre E. Neis 77
- 78. 4 Artefacts ProductBacklog Sprint Backlog Release Burndown Sprint Burndown GDP avec Scrum │ © Pierre E. Neis 78
- 79. Exercice • Créez un exemple d’application pour 1 la discussion Lignes directrices • Etude de cas réelle ou non • Rédiger (lisiblement!) une description 2 de votre étude de cas(100-200 mots) GDP avec Scrum │ © Pierre E. Neis 79
- 80. Sécurisation des Modèle Informations Personnelles 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.… Source: Mike Cohn, CSPO GDP avec Scrum │ © Pierre E. Neis 80
- 81. User Stories • Entant que [rôle Utilisateur] • Je veux une [FONCTIONNALITE] • De sorte que je reçois [BUSINESS VALUE]. GDP avec Scrum │ © Pierre E. Neis 81
- 82. User Story Card • Une brève description AS A Product Owner I CAN / I WANT estimate textuelle des exigences Costs • + Risques 3 lines of • + critères Requirement d’acceptation Description 82 GDP avec Scrum │ © Pierre E. Neis
- 83. Les bonnes Storiessont INVEST I N V E S Sized to fit (à T indépendant négociable valorisable estimable la bonne testable taille) 83 GDP avec Scrum │ © Pierre E. Neis
- 84. Exercice 1 •Reprenez l’exercice 2 •Rédigez les User Stories 3 •Sont-elles INVEST? GDP avec Scrum │ © Pierre E. Neis 84
- 85. Le Product Backlog? Le Backlog est une liste Priorité haute de tâches ouvertes comme : Sprint –les exigences – une liste de tous les travaux souhaités pour le projet –Idéalement exprimé de telle moyenne Priorité sorte que chaque objet a une valeur pour les utilisateurs ou les clients du produit –Priorisé par le Product Owner Release –Repriorisé au début de chaque Sprint Releases futures 85 GDP avec Scrum │ © Pierre E. Neis
- 86. Le Product Backlog Le Product Backlog répond aux questions suivantes: Quoi? Quand? Pour Qui? GDP avec Scrum │ © Pierre E. Neis 86
- 87. Stories, themes andepics USER STORY: THEME: Une description de la Un recueil de stories fonctionnalité désirée du point de vue du l'utilisateur ou duclient EPIC: Une grande story GDP avec Scrum │ © Pierre E. Neis 87
- 88. Sprint Backlog Tâches pour Les membres de transformer le l’équipe Les équipes sont Le Sprint Backlog Product Backlog Tâches estimées s’engagent sur mesurées en est revu en en heures les tâches une fonction de leurs journellement fonctionnalité- fois que le Sprint engagements produit a démarré De nouvelles tâches Une tâche ne doit sont pas nécessité plus identifiées, d’autres d’un jour ou deux sont changées ou éffacées. Et pas sur le temps Les tâches ne sont nécessaire pour le pas assignées réaliser Les heures Les grandes tâches restantes de travail sont découpées plus pour chaque tard dans le Sprint tâche sont mises à jour GDP avec Scrum │ © Pierre E. Neis 88
- 89. Release Burn downChart Example de Burndown Chart (Schwaber and Beedle 2002) Le Release burndown rend les tendances des progrès visibles. Le rapport est basé sur les informations suivantes: • le reste-à-faire du Product Backlog pour transformer la Vision en un produit gagnant. • Le nombre de Sprints nécessaires ou restants. • 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. GDP avec Scrum │ © Pierre E. Neis 89
- 90. Sprint Burn-down Charts •Le Sprint Burn-down chart montre – combien d'efforts a été déployé en travaillant sur la tâche contenue dans le Sprint Backlog – Et compare cela à la depense idéale Le tableau donne une tendance qui indique si l'équipe est susceptible de respecter son engagement (indicateur avancé) GDP avec Scrum │ © Pierre E. Neis 90
- 91. Les supports decours http://scrumcenterlux.pbworks.com • disponibles sur le wiki suivant: – Les supports de cours – Les liens vers les sites de référence – Les photos prises lors de la session – Des outils Scrum téléchargeables • Le Wiki permettra également de poursuivre votre formation au-delà de ces 3 journées: – Nous partagerons nos adresses – Vous 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. Neis 91
- 92. LES TIME-BOXES GDP avec Scrum │ © Pierre E. Neis 92
- 93. Au niveau stratégique GDP avec Scrum │ © Pierre E. Neis 93
- 94. Estimation Meeting - Préparationdu Sprint Planning - Estimation formelle - Passez au moins deux réunions par Sprint - Estimer uniquement sur la taille et le temps > Input pour Release Planning GDP avec Scrum │ © Pierre E. Neis 94
- 95. Au niveau tactique GDP avec Scrum │ © Pierre E. Neis 95
- 96. Les Meetings • Le Quoi? • Le Comment? • La Synchronisation • Les Résultats • L’Amélioration GDP avec Scrum │ © Pierre E. Neis 96
- 97. Sprint Planning 1 Sprint Planning 2 SPRINT Daily Meetings GDP avec Scrum │ © Pierre E. Neis Revue de Sprint Rétrospective Sprint Planning 1 Sprint Planning 2 97
- 98. Sprint Planning Meeting 2 PARTIES: • Organisateur: Le QUOI? Le COMMENT? Product Owner LE PRODUCT OWNER: Présente le Product Backlog priorisé par le client et/ou les utilisateurs • Participants: Présente le Release Plan Initial Présentation de la Vision l’équipe (actif), le L’ÉQUIPE: ScrumMaster Estime le Product Backlog en fonction de sa faisabilité (estimation fonctionelle) (passif) Découpe le Product Backlog en Sprint Backlogs avec le Product Owner Découpe le Sprint Backlog en tâches • Durée: 8 heures Estime le Sprint Backlog pour un Sprint de LE PRODUCT OWNER ET L’EQUIPE: 4 semaines Définissent l’objectif du Sprint Valident la Definition of Done GDP avec Scrum │ © Pierre E. Neis 98
- 99. Pour chaque Itemdu 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? Sprint Planning 2 Design GDP avec Scrum │ © Pierre E. Neis 99
- 100. Definition of Done GDP avec Scrum │ © Pierre E. Neis 100
- 101. Level of Done •Le Code est conforme aux normes Pour • Le Code est l’EQUIPE Propre Refactoré Testé unitairement Validé (checked in) Intégré (Built) Dispose d'une suite de test unitaire qui lui est appliquée. • Pour arriver à cela, l’environnement de développement est constitué : D’une bibliothèque de code source De codes standards, Build automatisé, D’un environnement pour les tests unitaires. GDP avec Scrum │ © Pierre E. Neis 101
- 102. Definition of Done •Une Story/Item est “done” lorsque Pour l’équipe a atteint son Level of Done SCRUM • Le Sprint/Iteration est “done” lorsque – tous les items sont “done” – et que le Sprint atteint son objectif – et que les critères d’acceptation sont adressés. • La Release est “done” “done” pour l’intégration “done” pour la production GDP avec Scrum │ © Pierre E. Neis 102
- 103. •Half done isnot done GDP avec Scrum │ © Pierre E. Neis 103
- 104. • Synchronisation / DailyScrum Engagement sur les tâches GDP avec Scrum │ © Pierre E. Neis 104
- 105. Daily Scrum • Organisateur: C’est l’inspect-and- l’équipe adapt de l’équipe: synchronisation et engagement • Participants: Les 3 questions: l’équipe (actif), le 1. Qu’est-ce que tu as fait hier? ScrumMaster 2. Quels sont les problèmes que tu as (passif), Product rencontrés? Owner (passif) 3. Qu’est-ce que tu as prévu aujourd’hui? • Durée: 15 min GDP avec Scrum │ © Pierre E. Neis 105
- 106. • Analyse desrésultats Sprint Review GDP avec Scrum │ © Pierre E. Neis 106
- 107. La Revue deSprint • Organisateur: Product C’est l’inspect-and-adapt des Owner utilisateurs, du client et du management L’équipe présente les résultats • Participants: l’équipe du Sprint (actif), le Utilisateurs/Client/ ScrumMaster (passif), Management expriment leurs le Management remarques et trouvent un (actif), le client (actif), compromis avec l’équipe les utilisateurs (actifs) Le Product Owner valide ou rejète les items du Sprint Backlog en fonction de la • Durée: 4 heures pour Definition of Done un Sprint de 4 C’est le Product Owner qui a semaines toujours le dernier mot... GDP avec Scrum │ © Pierre E. Neis 107
- 108. Quand un membrede l'équipe dit « DONE", ça veut dire quoi? • 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. • 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 GDP avec Scrum │ © Pierre E. Neis 108
- 109. Sprint Review • Présentation(par l’équipe) • Feedback (par l’utilisateur final) • C’est l’inspect-&-adapt de l’utilisateur permettant la création ou le changement des items du Product Backlog GDP avec Scrum │ © Pierre E. Neis 109
- 110. Validation du Sprint GDP avec Scrum │ © Pierre E. Neis 110
- 111. • Analyse desrésultats Rétrospective GDP avec Scrum │ © Pierre E. Neis 111
- 112. La Rétrospective • Organisateur: Analyse du Process ScrumMaster Scrum: Comment cela c’est passé pendant le Sprint • Participants: l’équipe Comment s’améliorer (actif), le ScrumMaster Points principaux de (actif), le Product vérification: Owner (actif en sa La communication dans l’équipe qualité de membre de Les relations entre les l’équipe) membres de l’équipe Les process et les outils Les besoins en formation • Durée: 3 heures pour un Sprint de 4 semaines GDP avec Scrum │ © Pierre E. Neis 112
- 113. Rétrospective • Nous faisonsun point après l’action en nous posant deux questions: – Qu’est-ce qui a bien fonctionné? – Que devons-nous améliorer? • Objectifs: – Apprendre du passé pour préparer l’avenir – Améliorer la productivité de l’équipe GDP avec Scrum │ © Pierre E. Neis 113
- 114. Finalité de laRétrospective • Debriefing • Amélioration • Comprendre la réalité Où allons-nous à partir d’ici? • Apprendre • “Input” pour le Sprint Planning GDP avec Scrum │ © Pierre E. Neis 114
- 115. COMMENT IMPLEMENTER SCRUM? GDP avec Scrum │ © Pierre E. Neis 115
- 116. Sponsor Chercher un Sponsorle plus haut possible dans la hiérarchie permet de garantir la bonne mise en place du processus de changement. GDP avec Scrum │ © Pierre E. Neis 116
- 117. Initier Avancer seul surun projet de changement est plus que risqué. Faites- vous aider par une ressource externe. GDP avec Scrum │ © Pierre E. Neis 117
- 118. Enflammer Allumez votre premièrebalise et enflammez ensuite le développement. GDP avec Scrum │ © Pierre E. Neis 118
- 119. Diversité Allumez davantage debalises en diversifiant le nombres des acteurs de votre projet. GDP avec Scrum │ © Pierre E. Neis 119
- 120. Promouvoir Faites savoir etpartagez votre expérience. Vous et votre équipe êtes les promoteurs de Scrum au sein de votre organisation. Allumez encore plus de balises. GDP avec Scrum │ © Pierre E. Neis 120
- 121. Professionnaliser En adoptant uneattitude « 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. GDP avec Scrum │ © Pierre E. Neis 121
- 122. Etablir Définir Scrum commeoption officielle. GDP avec Scrum │ © Pierre E. Neis 122
- 123. Consolider Faites une transitionvers une Entreprise Agile GDP avec Scrum │ © Pierre E. Neis 123
- 124. Intégrer Construisez une gouvernanceIT. GDP avec Scrum │ © Pierre E. Neis 124
- 125. Le mot dela fin Ayez toujours sur vous votre « Sac Agile »
- 126. Demander à l’équipe GDP avec Scrum │ © Pierre E. Neis 126
- 127. Inspecter & Adapter GDP avec Scrum │ © Pierre E. Neis 127
- 128. Livrer tous les30 jours GDP avec Scrum │ © Pierre E. Neis 128
- 129. Traiter les personnescomme des adultes GDP avec Scrum │ © Pierre E. Neis 129
- 130. pneis@coprocess.lu Scrum by coPROcess 130
Notes de l'éditeur
- #13 Nota: lestermessontvolontairementrestés en anglaisafin de favoriser le dialogue avec la communautéinternationale Scrum.
- #17 Source: SilvanaWasitovaWinston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce developed the phased delivery model to cope with regulatory requirements set out in the US DoD STD-2167 document, which was so byzantine and bureaucratic that the waterfall was the only way to cope with it;
- #23 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.Espérerl’inespéré.Exercer des contrôles par de fréquentes inspections et adaptations.