<!-- Slide number: 1 -->
 Bienvenue GDP avec Scrum │ © Pierre E. Neis 1
Notes:
<!-- Slide number: 2 --> # Gestion de projets agiles avec Scrum Cycle de formation « base »
Notes:
<!-- Slide number: 3 -->
 GDP avec Scrum │ © Pierre E. Neis 3
Notes:
<!-- Slide number: 4 --> # Les supports de cours 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 4
Notes:
<!-- Slide number: 5 --> ① # Le Jargon de scrum GDP avec Scrum │ © Pierre E. Neis 5
Notes:
<!-- Slide number: 6 --> # 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 | | L’EQUIPE ou la TEAM: | C’est l’équipe de développement | | La Scrum Team: | C’est l’ EQUIPE + 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 deu projet se retrouvent pour inspecter 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 6
Notes: Nota: les termes sont volontairement restés en anglais afin de favoriser le dialogue avec la communauté internationale Scrum.
<!-- Slide number: 7 --> # Objectif Comprendre les fondamentaux de Scrum
Savoir utiliser les outils de Scrum
Être en mesure de démarrer votre projet Scrum GDP avec Scrum │ © Pierre E. Neis 7
Notes:
<!-- Slide number: 8 --> # Périmètre Historique La théorie « Scrum » La Philosophie agile GDP avec Scrum │ © Pierre E. Neis 8
Notes:
<!-- Slide number: 9 --> # ❶ Historique Un rappel contextuel…. GDP avec Scrum │ © Pierre E. Neis 9
Notes:
<!-- Slide number: 10 --> # 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 10
Notes: Source: Silvana Wasitova
Winston W. Royce,Managing the development of large software systems Proc. IEEE WESCON, Aug 1970
Royce 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;
<!-- Slide number: 11 --> # 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é. » Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986 GDP avec Scrum │ © Pierre E. Neis 11
Notes:
<!-- Slide number: 12 --> Est-ce que le développement logiciel est un processus défini? GDP avec Scrum │ © Pierre E. Neis 12
Notes:
<!-- Slide number: 13 --> # Le modèle empirique Contrôles Outputs Inputs Incrément de produit potentiellement livrable exigences technologie équipe Process Le modèle empirique est dépendant de fréquentes inspections et adaptations pour atteindre l’objectif. GDP avec Scrum │ © Pierre E. Neis 13
Notes: Utile lorsque Le process ne peut pas être suffisamment décrit pour assurer sa répétabilité Il y a tellement de complexité ou de nuisance que le projet tend vers des livrables différents.
Espérer l’inespéré.
Exercer des contrôles par de fréquentes inspections et adaptations.
<!-- Slide number: 14 -->
 # La théorie SCRUM
GDP avec Scrum │ © Pierre E. Neis 14
Notes:
<!-- Slide number: 15 --> # Scrum est un processus empirique
 GDP avec Scrum │ © Pierre E. Neis 15
Notes:
<!-- Slide number: 16 --> # Scrum repose sur 3 pieds GDP avec Scrum │ © Pierre E. Neis 16
Notes:
<!-- Slide number: 17 --> # 10 Pratiques de base Vision claire et partagée Product Backlog entretenu Product Backlog priorisé en fonction de la valeur métier Items de backlog triés par l’équipe Daily Scrums Sprints 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 collaborative Rétrospective concentrée sur l’amélioration du travail et du processus de l’équipe et de l’organisation Burndown Charts (graphiques de reste-à-faire) GDP avec Scrum │ © Pierre E. Neis 17
Notes:
<!-- Slide number: 18 --> # Scrum vs Modèle en “cascade”
 GDP avec Scrum │ © Pierre E. Neis 18
Notes:
<!-- Slide number: 19 --> # 15’ Discussion en Groupe GDP avec Scrum │ © Pierre E. Neis 19
Notes:
<!-- Slide number: 20 -->
 # La Philosophie Agile L’Agile Manifesto GDP avec Scrum │ © Pierre E. Neis 20
Notes:
<!-- Slide number: 21 --> # Manifeste pour le développement Agile de logiciels
21 GDP avec Scrum │ © Pierre E. Neis
Notes: Manifeste pour le développement Agile de logiciels Nous découvrons comment mieux développer des logicielspar la pratique et en aidant les autres à le faire.Ces expériences nous ont amenés à valoriser : Les individus et leurs interactions plus que les processus et les outilsDes logiciels opérationnels plus qu’une documentation exhaustiveLa collaboration avec les clients plus que la négociation contractuelleL’adaptation au changement plus que le suivi d’un plan Nous reconnaissons la valeur des seconds élémentsmais privilégions les premiers.
<!-- Slide number: 22 --> # 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. | 22 GDP avec Scrum │ © Pierre E. Neis
Notes: http://agilemanifesto.org/principles.html
<!-- Slide number: 23 --> # Le triangle magique Engagement des employés Reconnus, engagés, employés heureux Création de Valeur Maximiser le ROI et optimiser la trésorerie Satisfaction du Client Servir le client GDP avec Scrum │ © Pierre E. Neis 23
Notes:
<!-- Slide number: 24 --> # Le Problème
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 24 GDP avec Scrum │ © Pierre E. Neis
Notes: Le métier et le développement sont souvent enfermés dans une relation malsaine. L’équipe de développement “sous-livre”, les projets échouent ou ne génèrent pas la valeur désirée. Les besoins des clients sont mal communiqués et mal compris par le développement
Les deux partenaires doivent changer pour améliorer la satisfaction client et la création de valeur Scrum permet à l'entreprise de piloter directement le développement en supprimant les obstacles Scrum exige que l'entreprise accepte la propriété et collabore étroitement avec le développement de façon continue (rf. R. Pichler)
<!-- Slide number: 25 -->
Contenu de Scrum GDP avec Scrum │ © Pierre E. Neis 25
Notes:
<!-- Slide number: 26 --> # Introduction par Ken Schwaber
 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 26
Notes:
<!-- Slide number: 27 --> # Le principe “Pull”
 GDP avec Scrum │ © Pierre E. Neis 27
Notes:
<!-- Slide number: 28 --> # Équipes auto-gérées vs Organisation traditionnelle | Equipes auto-gérées | Organisation traditionnelle | | --- | --- | | Orientées client | Pilotée par le management | | Force de travail multi-compétence | Force de travail constituée de spécialistes isolés | | Peu de description de poste | 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 du 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 28
Notes:
<!-- Slide number: 29 -->
 # Les Règles Rôles, Artifacts et Time-boxes GDP avec Scrum │ © Pierre E. Neis 29
Notes:
<!-- Slide number: 30 -->
 GDP avec Scrum │ © Pierre E. Neis 30
Notes:
<!-- Slide number: 31 --> # 3 Rôles Scrum Team plus 3 Rôles organisationnels GDP avec Scrum │ © Pierre E. Neis 31
Notes: Les poules sont engagées. Les cochons sont impliquées.
<!-- Slide number: 32 -->
 # Les Rôles de l’Equipe Scrum
GDP avec Scrum │ © Pierre E. Neis 32
Notes:
<!-- Slide number: 33 -->
 # Le ScrumMaster GDP avec Scrum │ © Pierre E. Neis 33
Notes:
<!-- Slide number: 34 --> # Sa fonction Protège l’é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 34
Notes:
<!-- Slide number: 35 --> # Sa Mission Protéger l’Équipe Scrum
Lever les obstacles
Exécuter le process
Travailler avec le Product Owner
Publicité
Changer l’Organisation
GDP avec Scrum │ © Pierre E. Neis 35
Notes:
<!-- Slide number: 36 --> # Le ScrumMaster + Produit + Process Agir de la bonne façon Faire bien (Produit)
 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 36
Notes:
<!-- Slide number: 37 -->
 # Le Product Owner GDP avec Scrum │ © Pierre E. Neis 37
Notes:
<!-- Slide number: 38 --> # Sa fonction Il pilote 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 38
Notes:
<!-- Slide number: 39 --> # Sa Mission Se concentre 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 39
Notes:
<!-- Slide number: 40 -->
 # L’Équipe GDP avec Scrum │ © Pierre E. Neis 40
Notes:
<!-- Slide number: 41 --> # Sa fonction Elle 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 volontairement
Elle travaille continuellement avec le Product Owner pour définir la direction stratégique du Produit. GDP avec Scrum │ © Pierre E. Neis 41
Notes:
<!-- Slide number: 42 --> # Constituer l’Équipe 5/9 personnes
Multidisciplinaire
Autogérée
Cross-fonctionnelle / transverse
Plus orientée compétence que fonction GDP avec Scrum │ © Pierre E. Neis 42
Notes:
<!-- Slide number: 43 --> # Constitution de l’Équipe Product Owner
Chef de Produit MOA Analyste Métier Chef de Projet fonctionnel Scrum Master Architecte Tout le monde. Pas une autorité. Pas nécessairement un développeur. The Team Développeur DBA Analyste Testeur GDP avec Scrum │ © Pierre E. Neis 43
Notes: Quand une tâche peut être effectuée par une seule personne, vous devez le faire avec deux personnes (rf. B.Gloger)
<!-- Slide number: 44 --> # Tuckman: les phases de dévelopement
 © Bruce Tuckman 'Forming Storming' concept 1965. Diagram Alan Chapman 44 GDP avec Scrum │ © Pierre E. Neis
Notes:
<!-- Slide number: 45 --> # Comment optimiser le travail 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 45
Notes:
<!-- Slide number: 46 --> # Collaboration Le Product Owner 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 46
Notes:
<!-- Slide number: 47 --> # 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 47
Notes:
<!-- Slide number: 48 -->
 # Les Rôles Organisationnels
GDP avec Scrum │ © Pierre E. Neis 48
Notes:
<!-- Slide number: 49 -->
 # Le Client GDP avec Scrum │ © Pierre E. Neis 49
Notes:
<!-- Slide number: 50 --> # Sa fonction Il demande 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 50
Notes:
<!-- Slide number: 51 --> # Sa Mission Il commande le produit
Il paye le développement du produit
Il donne des feed-back et des révisions
GDP avec Scrum │ © Pierre E. Neis 51
Notes:
<!-- Slide number: 52 -->
 # Le Manager GDP avec Scrum │ © Pierre E. Neis 52
Notes:
<!-- Slide number: 53 --> # Sa fonction 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.
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 53
Notes:
<!-- Slide number: 54 --> # Sa Mission Il 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. Neis 54
Notes:
<!-- Slide number: 55 -->
 # L’Utilisateur Final GDP avec Scrum │ © Pierre E. Neis 55
Notes: C’est l’audience
<!-- Slide number: 56 --> # Sa fonction Ce 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. Neis 56
Notes:
<!-- Slide number: 57 --> # Sa Mission Il connaî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 57
Notes:
<!-- Slide number: 58 -->
Comment ces rôles travaillent-ils ensemble? GDP avec Scrum │ © Pierre E. Neis 58
Notes:
<!-- Slide number: 59 -->
 Rôles organisationnels
 Scrum Team Roles
 GDP avec Scrum │ © Pierre E. Neis 59
Publicité
Notes:
<!-- Slide number: 60 --> Le ScrumMaster travaille avec le Product Owner
 GDP avec Scrum │ © Pierre E. Neis 60
Notes: Le ScrumMaster travaille avec le Product Owner pour s'assurer que le Product Owner remplit son emploi.
Le ScrumMaster coache le Product Owner et lui apporte son soutien face auy agressions extérieures.
<!-- Slide number: 61 --> Le ScrumMaster travaille avec l’Equipe
 GDP avec Scrum │ © Pierre E. Neis 61
Notes: Le ScrumMaster travaille avec l'équipe pour s'assurer que tout le monde fait ce qu'il s’était engagé de faire! Le ScrumMaster protège l'équipe et élimine les obstacles
<!-- Slide number: 62 --> Le Product Owner travaille avec le client
 GDP avec Scrum │ © Pierre E. Neis 62
Notes: Pour s’assurer qu’il atteindra son retour sur investissement. Le client va tenter de pousser le Product Owner, mais ce dernier conservera l’intérêt de son équipe à l’esprit.
<!-- Slide number: 63 --> L’Equipe travaille avec l’utilisateur final
 GDP avec Scrum │ © Pierre E. Neis 63
Notes: pour comprendre les besoins de l'utilisateur final et d'écrire l'application selon les spécifications de celui-ci.
<!-- Slide number: 64 --> Le ScrumMaster travaille avec le Manager
 GDP avec Scrum │ © Pierre E. Neis 64
Notes: Pour refactorer les lignes directrices et les processus et faire en sorte que l’Equipe Scrum obtienne ce dont elle a besoin.
<!-- Slide number: 65 --> Le Product Owner a besoin de connaître ce que le marché (l’utilisateur final) souhaite.
 GDP avec Scrum │ © Pierre E. Neis 65
Notes: Il doit connaître ses besoins pour pouvoir les prioriser.
<!-- Slide number: 66 --> 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 66
Notes:
<!-- Slide number: 67 --> # Références
 GDP avec Scrum │ © Pierre E. Neis 67
Notes:
<!-- Slide number: 68 -->
Les Artefacts GDP avec Scrum │ © Pierre E. Neis 68
Notes:
<!-- Slide number: 69 --> # 4 Artefacts GDP avec Scrum │ © Pierre E. Neis 69
Notes:
<!-- Slide number: 70 --> # Exercice GDP avec Scrum │ © Pierre E. Neis 70
Notes:
<!-- Slide number: 71 --> # Modèle Sécurisation des 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 71
Notes:
<!-- Slide number: 72 --> # 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 72
Notes:
<!-- Slide number: 73 --> # User Story Card
 Une brève description textuelle des exigences + Risques
+ critères d’acceptation AS A Product Owner I CAN / I WANT estimate Costs
 3 lines of Requirement Description 73 GDP avec Scrum │ © Pierre E. Neis
Notes: Les critères 3C:
Card Small enough to fit on a index card Conversation Drives the conversation between Product Owner and Team Confirmation Can be clearly validated
<!-- Slide number: 74 --> # Les bonnes Stories sont INVEST 74 GDP avec Scrum │ © Pierre E. Neis
Notes: I : Independent Évitez les dépendances avec d'autres storiesRédigez des stories permettant d’établir des fondations solidesCombiner des stories pour les livrer si possible en un seul Sprint N: negotiable Les stories ne sont pas un contratTrop de détails donne l'impression que la discussion n’est plus nécessaire.Pas toutes les stories doivent être négociables, des contraintes peuvent exister. V: valuable Chaque story doit montrer la valeur pour les utilisateurs, clients et parties prenantes
E: estimable suffisamment de détails devraient être indiqués pour permettre à l'équipe d'évaluer L'équipe rencontrera des problèmes d'estimation si la story est trop grande, insuffisante, ou si il ya un manque de connaissance du domaine.
S: sized appropriately Chaque story doit être assez petite pour être achevée en un seul Sprint Les stories à venir devraient être plus petites et plus détaillées. De grandes stories sont acceptables si elles sont planifiées plus loin(Epics)
Testable Les critères d'acceptation devront être démarrés dans les termes de la clientèle Les tests devraient être automatisés autant que possible Tous les membres de l'équipe devrait exiger des critères d'acceptation clairs.
<!-- Slide number: 75 --> # Exercice GDP avec Scrum │ © Pierre E. Neis 75
Notes:
<!-- Slide number: 76 --> # Le Product Backlog?
Priorité haute
Le Backlog est une liste de tâches ouvertes comme : les exigences
une liste de tous les travaux souhaités pour le projet
Idéalement exprimé de telle sorte que chaque objet a une valeur pour les utilisateurs ou les clients du produit Priorisé par le Product Owner
Repriorisé au début de chaque Sprint
Sprint
Priorité moyenne
Release
Releases futures 76 GDP avec Scrum │ © Pierre E. Neis
Notes:
<!-- Slide number: 77 --> # Le Product Backlog
 Le Product Backlog répond aux questions suivantes: Quoi? Quand? Pour Qui? GDP avec Scrum │ © Pierre E. Neis 77
Notes:
<!-- Slide number: 78 --> # Sprint Backlog GDP avec Scrum │ © Pierre E. Neis 78
Notes:
<!-- Slide number: 79 --> # Release Burn down Chart 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 79
Notes:
<!-- Slide number: 80 --> # 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 80
Notes:
<!-- Slide number: 81 --> # Les supports de cours 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 81
Notes:
<!-- Slide number: 82 -->
Les Time-boxes GDP avec Scrum │ © Pierre E. Neis 82
Notes:
<!-- Slide number: 83 -->
 # Au niveau stratégique
GDP avec Scrum │ © Pierre E. Neis 83
Notes:
<!-- Slide number: 84 --> # Estimation Meeting - Préparation du 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 84
Notes:
<!-- Slide number: 85 -->
 # Au niveau tactique
GDP avec Scrum │ © Pierre E. Neis 85
Notes:
<!-- Slide number: 86 --> # Les Meetings Le Quoi? Le Comment? La Synchronisation Les Résultats L’Amélioration GDP avec Scrum │ © Pierre E. Neis 86
Notes:
Publicité
<!-- Slide number: 87 --> Sprint Planning 1 Sprint Planning 2 Revue de Sprint Rétrospective Sprint Planning 1 Sprint Planning 2
Daily Meetings SPRINT
GDP avec Scrum │ © Pierre E. Neis 87
Notes:
<!-- Slide number: 88 --> # Sprint Planning Meeting 2 parties: Le QUOI? Le COMMENT?
Le Product Owner: Présente le Product Backlog priorisé par le client et/ou les utilisateurs
Présente le Release Plan Initial
Présentation de la Vision
L’équipe: Estime le Product Backlog en fonction de sa faisabilité (estimation fonctionelle)
Découpe le Product Backlog en Sprint Backlogs avec le Product Owner
Découpe le Sprint Backlog en tâches
Estime le Sprint Backlog
Le Product Owner et l’Equipe:
Définissent l’objectif du Sprint
Valident la Definition of Done
Organisateur: Product Owner
Participants: l’équipe (actif), le ScrumMaster (passif)
Durée: 8 heures pour un Sprint de 4 semaines
GDP avec Scrum │ © Pierre E. Neis 88
Notes: D’une manière générale, le Sprint Planning Meeting (SPM) est découpé en deux parties:
Le SPM 1: Durée: 4 heures Organisateur: le Product Owner Objectif: définition du QUOI Focus: évaluation du Product Backlog, Découpage des Sprints, Evaluation du Product Backlog. Attention: raisonnenement uniquement basé sur les fonctionnalités et sur l’ingéniérie.
Le SPM 2: Durée: 4 heures Organisateur: l’Equipe Objectif: définition du COMMENT Focus: Design, évaluation du Sprint Backlog, Découpage des tâches, Evaluation du Sprint Backlog, objectif de Sprint
<!-- Slide number: 89 --> # 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? Sprint Planning 2 Design GDP avec Scrum │ © Pierre E. Neis 89
Notes:
<!-- Slide number: 90 --> # Definition of Done
 GDP avec Scrum │ © Pierre E. Neis 90
Notes:
<!-- Slide number: 91 --> # Level of Done Pour l’EQUIPE Le Code est conforme aux normes
Le Code est 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 91
Notes:
<!-- Slide number: 92 --> # Definition of Done Pour SCRUM Une Story/Item est “done” lorsque l’équipe a atteint son Level of Done
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 92
Notes:
<!-- Slide number: 93 -->
 Half done is not done GDP avec Scrum │ © Pierre E. Neis 93
Notes:
<!-- Slide number: 94 --> # Daily Scrum Synchronisation / Engagement sur les tâches
Notes:
<!-- Slide number: 96 --> # Sprint Review Analyse des résultats
 GDP avec Scrum │ © Pierre E. Neis 96
Notes:
<!-- Slide number: 97 --> # La Revue de Sprint C’est l’inspect-and-adapt des utilisateurs, du client et du management
L’équipe présente les résultats du Sprint
Utilisateurs/Client/ Management expriment leurs remarques et trouvent un compromis avec l’équipe
Le Product Owner valide ou rejète les items du Sprint Backlog en fonction de la Definition of Done
C’est le Product Owner qui a toujours le dernier mot...
Organisateur: Product Owner
Participants: l’équipe (actif), le ScrumMaster (passif), le Management (actif), le client (actif), les utilisateurs (actifs)
Durée: 4 heures pour un Sprint de 4 semaines
GDP avec Scrum │ © Pierre E. Neis 97
Notes:
<!-- Slide number: 98 --> # Quand un membre de 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 98
Notes:
<!-- Slide number: 99 --> # 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 99
Notes:
<!-- Slide number: 100 --> # Validation du Sprint GDP avec Scrum │ © Pierre E. Neis 100
Notes:
<!-- Slide number: 101 --> # Rétrospective Analyse des résultats
 GDP avec Scrum │ © Pierre E. Neis 101
Notes:
<!-- Slide number: 102 --> # La Rétrospective Analyse du Process Scrum: Comment cela c’est passé pendant le Sprint Comment s’améliorer
Points principaux de vérification: La communication dans l’équipe Les relations entre les membres de l’équipe Les process et les outils Les besoins en formation
Organisateur: ScrumMaster
Participants: l’équipe (actif), le ScrumMaster (actif), le Product Owner (actif en sa qualité de membre de l’équipe)
Durée: 3 heures pour un Sprint de 4 semaines
GDP avec Scrum │ © Pierre E. Neis 102
Notes:
<!-- Slide number: 103 --> # Rétrospective Nous faisons un 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 103
Notes:
<!-- Slide number: 104 --> # Finalité de la Rétrospective
Debriefing Amélioration Comprendre la réalité Apprendre “Input” pour le Sprint Planning Où allons-nous à partir d’ici? GDP avec Scrum │ © Pierre E. Neis 104
Notes:
<!-- Slide number: 105 -->
Comment implementer scrum? GDP avec Scrum │ © Pierre E. Neis 105
Notes:
<!-- Slide number: 106 -->
 # Sponsor Chercher un Sponsor le 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 106
Notes:
<!-- Slide number: 107 -->
 # Initier Avancer seul sur un projet de changement est plus que risqué. Faites-vous aider par une ressource externe. GDP avec Scrum │ © Pierre E. Neis 107
Notes:
<!-- Slide number: 108 -->
 # Diversité Allumez davantage de balises en diversifiant le nombres des acteurs de votre projet. GDP avec Scrum │ © Pierre E. Neis 109
Notes:
<!-- Slide number: 110 -->
![http://marketinghackz.com/app/static/uploads/2011/05/promote-your-services.jpg%5D(Picture2.jpg) # Promouvoir 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. GDP avec Scrum │ © Pierre E. Neis 110
Notes:
Publicité
<!--