Scrum : Cadre de travail pour des problèmes complexes permettant de délivrer des produits utilisa...

1. Réfléchir à intervalle régulier à la façon de devenir plus efficace dans la manière de travailler

2. Artifacts Permettent de prendre des décisions

2.1. Product Backlog

2.1.1. Liste d'éléments nécessaires à la réalisation d'un produit global.

2.1.2. Attributs des éléments : description, ordre, et taille

2.1.3. Jamais complet. Evolue constamment en fonction de l'environnement et du produit global.

2.1.4. Quand plusieurs équipes travaillent sur un même produit, il y a un seul product backlog.

2.1.5. le Product Backlog est affiné par le PO et la DT pendant tout le sprint : détail, estimation, ordre. Cela ne doit pas prendre plus de 10% de la capacité de la DT.

2.1.6. Le haut du backlog est plus détaillé que le bas.

2.2. Sprint Backlog

2.2.1. Plan que l'équipe se donne pour atteindre le Sprint Goal et délivrer un incrément : ensembles des éléments du backlog sélectionnés plus les tâches pour les réaliser.

2.2.2. Les tâches du sprint backlog peuvent être changées pendant le sprint par la DT. Les user stories sélectionnées ne changent pas

2.2.3. Discuté pendant le daily scrum

2.2.4. Transparent, visible et updaté par la DT

2.3. Definition of Done

2.3.1. Toute l'équipe Scrum doit se mettre d'accord sur la definition of done d'un incrément : ce qui fait qu'ils considèrent que l'incrément est terminé. Toute l'équipe doit comprendre la même définition of Done.

2.3.2. Artifact de transparence. Il répond au but du sprint de délivrer un incrément potentiellement utilisable.

2.3.3. S'il ya plusieurs équipes qui travaillent sur un même produit, elles doivent se mettre d'accord sur la definition of DONE.

2.4. Transparence

2.4.1. Le Scrum master doit travailler avec le PO et la DT et toutes les parties concernées pour assurer la transparence des artifacts. ça passe par enseigner, convaincre et aider à changer.

3. Valeurs

3.1. Courage

3.2. Concentration

3.3. Respect

3.4. Engagement

3.5. Ouverture d'esprit

4. Manifeste agile

4.1. Valeurs

4.1.1. Privilégier les individus et les interactions aux process et outils

4.1.2. Privilégier un logiciel qui fonctionne à de la documentation explicite

4.1.3. Privilégier la collaboration avec le client à la négociation de contrat

4.1.4. Privilégier l'adaptation au changement à la poursuite d'un plan

4.2. Principes

4.2.1. Accorder notre plus haute priorité à la satisfaction du client à travers des livraison de logiciel rapprochées et continues

4.2.2. Accepter le changement de besoins, même tard dans le développement

4.2.3. Livrer fréquemment un logiciel qui marche à échéance régulière, de 2 semaines à 1 mois, avec une préférence pour les plus petites périodes de temps

4.2.4. Faire travailler ensemble quotidiennement les utilisateurs et les développeurs

4.2.5. Construire les projets autour de personnes motivées. Leur donner l'environnement et le support dont elles ont besoin et en leur faisant confiance.

4.2.6. Privilégier la communication face à face qui est le moyen le plus efficace pour transmettre l'information aux équipes de développement.

4.2.7. Considérer les versions opérationnelles du logiciel comme étant les mesures principales de progrès

4.2.8. Considérer les procédés agiles comme les moteurs d'un développement viable. Sponsors, développeurs et utilisateurs doivent pouvoir maintenir un rythme constant indéfiniement.

4.2.9. Apporter une attention continue à l'excellence technique et à la bonne conception afin d'améliorer l'agilité.

4.2.10. privilégier la simplicité - c'est-à-dire l'art de maximiser le travail à ne pas faire

4.2.11. Considérer que les meilleures architectures, besoins et conceptions émergent d'équipes auto-organisées

5. Fondements

5.1. Transparence

5.2. Inspection

5.3. Adaptation

5.3.1. Accepter le changement de besoins, tout le temps

6. Rôles de la Scrum Team

6.1. Product Owner responsable du pourquoi on fait les choses : livrer le bon produit aux bonnes personnes

6.1.1. - Responsable de maximiser la valeur du produit et du travail de la Development Team - Seul responsable de la gestion du Product Backlog. : contenu, disponibilité et ordre. Soit il le fait lui-même ou le fait faire à la Dev Team.

6.1.1.1. Clarifier les éléments du Product Backlog

6.1.1.2. Ordonner les éléments du Product Backlog pour pouvoir atteindre le but final

6.1.1.3. S'assurer que le Product Backlog soit visible, transparent et clair pour tout le monde et montrer à la Scrum Team sur quoi elle bossera.

6.1.1.4. S'assurer que la Developement Team comprenne les éléments du Product Backlog au niveau dont on a besoin

6.1.1.5. Optimiser la valeur du travail de la Development Team

6.1.1.6. L'organisation doit respecter les demandes du PO et personne ne peut adresser d'autres demandes à la Dev team

6.1.1.7. Un backlog grooming est réalisé avant ou pendant le sprint pour faire des user stories invest indépendantes, négociables, de valeur, estimables, de petite tailles et testables.

6.2. Scrum Master responsable de la bonne communication entre les personnes et qu'elles s'approprient scrum. servant leader.

6.2.1. s'assurer que la scrum team adhère à scrum, aux pratiques et règles

6.2.1.1. Rôle vis à vis du Product Owner

6.2.1.1.1. Fournir les techniques pour la gestion du Product Backlog

6.2.1.1.2. S'assurer que le PO sait comment ordonner le Product backlog pour maximiser sa valeur

6.2.1.1.3. Aider la Scrum Team à comprendre le besoin de clarifier et préciser les éléments du backlog

6.2.1.1.4. Comprendre le product planning selon l'environnement

6.2.1.1.5. Comprendre et pratiquer l'agilité

6.2.1.1.6. Faciliter les événements Scrum

6.2.1.2. Rôle vis à vis de la Dev Team

6.2.1.2.1. Coacher la Dev Team pour lui apprendre à s'auto-organiser et développer des compétences transversales

6.2.1.2.2. Eliminer les difficultés qui bloquent la progression de la Dev Team

6.2.1.2.3. Coacher l'équipe au sein d'une organisation dans laquelle Scrum n'est pas complètement adopté

6.2.1.2.4. Faciliter les événements Scrum

6.2.1.3. Rôle vis à vis de l'organisation

6.2.1.3.1. Coacher l'organisation pour l'adoption de Scrum

6.2.1.3.2. Planifier l'implémentation de Scrum dans l'organisation

6.2.1.3.3. Aider les collaborateurs et clients à comprendre et adopter Scrum

6.2.1.3.4. Provoquer des changements qui augmentent la productivité de Scrum

6.2.1.3.5. Travailler avec d'autres Scrum Masters pour augmenter l'efficacité de l'adoption de Scrum dans l'organisation

6.2.2. - s'assurer que les personnes hors scrum comprennent en quoi leurs interactions aident ou pas la scrum team - améliorer les interactions avec les personnes hors scrum pour aider la scrum team

6.3. Development Team Responsables du comment on fait les choses avec qualité

6.3.1. Equipe de professionnels qui travaillent pour délivrer un incrément indépendant et utilisable à la fin de chaque Sprint. Ce sont les seuls à réaliser l'incrément.

6.3.1.1. Equipe auto-organisée pour mieux répondre aux besoins et de meilleurs produits

6.3.1.2. Equipe pluridisciplinaire, réunit toutes les compétences nécessaires pour faire le travail

6.3.1.3. Pas de titres spéciaux pour les membres. Tout le monde est à niveau égal hiérarchique.

6.3.1.4. Le travail est de la responsabilité de l'ensemble de l'équipe, même si certains peuvent avoir des compétences spécifiques.

6.3.1.5. Taille de l'équipe : 3 à 9

7. Evénements Ils sont tous time boxés.

7.1. Sprint

7.1.1. Petite période pour livrer fréquemment et régulièrement des produits utilisables : baisse du risque financier et commercial Durée max de 4 semaines

7.1.2. A la fin du sprint, un produit de valeur et utilisable, a Done, doit être délivré.

7.1.3. Un nouveau sprint commence dès la fin du précédent sprint.

7.1.4. Annulation d'un sprint seulement si l'environnement a changé (marché, moyens financiers)

7.1.5. Le backlog peut être affiné pendant tout le sprint.

7.1.6. Si le travail se détourne de ce qui était attendu par l'équipe à l'issue du sprint, la dev team et le PO collaborent pour revoir le périmètre du sprint backlog.

7.2. Sprint Planning

7.2.1. Toute la Scrum Team y participe et éventuellement clients et experts à la demande de la dev team.

7.2.2. Durée max de 8h pour un sprint de 4 semaines

7.2.3. Objectifs : - Définir ce qui pourra être délivré à l'issue du sprint : But du sprint - déterminer comment le travail sera fait pour atteindre l'objectif du sprint

7.2.3.1. Rôle du product Owner : - Expliquer et discuter le but que le sprint devrait atteindre et les éléments de plus haute valeur à intégrer à partir du product Backlog, précédemment priorisé, qui devraient être délivrés à la fin du sprint - affiner le périmètre des user stories si besoin - découper plus finement les user stories si besoin

7.2.3.2. Rôle de la Dev Team : - Estimer la complexité des éléments du backlog - définir comment le travail peut être fait pour passer les user stories en done. - sélectionner les éléments les plus petits (en temps) et utilisables du backlog, selon un ensemble cohérent, qui pourront être développés pendant le sprint = sprint backlog - préciser les tâches pour faire les user stories, au moins pour les 1ers jours du sprint

7.2.3.3. Rôle de la Scrum team : - définir le but du sprint une fois que les éléments du backlog ont été déterminés. C'est l'objectif du sprint, sa raison d'être, et constitue le guide de l'équipe pendant tout le sprint. - Fixer le lieu et le moment du daily scrum

7.2.3.4. Inputs : - product backlog - l'incrément livré lors du dernier sprint - la capacité de travail de la Dev team pour le prochain sprint - la vélocité estimée de la Dev Team (voire la moyenne des 3 derniers sprints)

7.2.4. Rôle du Scrum master : - s'assurer qu'il a lieu et que tous les participants ont compris son but - apprendre à l'équipe à tenir le délai imparti - faciliter la réunion - participer à la réunion

7.3. Daily Scrum

7.3.1. Seule la Dev team y participe.

7.3.2. Durée de 15 mn

7.3.3. Objectif : inspecter le travail fait pour éventuellement adapter celui-ci de manière à atteindre l'objectif du Sprint - Qu'est-ce que l'équipe a fait hier pour aider à atteindre le but du Sprint ? - Qu'est-ce que l'équipe va faire les prochaines 24h pour se rapprocher du but ? - Est-ce qu'il y a des obstacles pour atteindre le but du Sprint ?

7.3.3.1. Elle a toujours lieu au même endroit et moment.

7.3.3.2. La dev Team est responsable d'animer la réunion.

7.3.3.3. Les membres de la dev team se rencontrent après pour organiser plus en détail leur travail des 24H

7.3.3.4. Bénéfices de cet événement : - éliminer les autres réunions pendant le sprint - améliorer la communication - augmenter le niveau de connaissance de l'équipe - identifier et éliminer les obstacles - permettre de prendre des décisions rapides

7.3.4. Rôle du Scrum master : - s'assurer que l'équipe fasse la réunion au lieu et moment imparti - apprendre à l'équipe à faire la réunion dans le délai imparti - s'assurer que seule l'équipe y participe - faciliter la réunion

7.4. Rôle de la Dev Team : - Elle dit ce qui a marché pendant le sprint, les problèmes rencontrés et ceux qui ont été résolus. - Elle démontre ce qui est Done et répond aux questions sur l'incrément livré.

7.5. Sprint Review

7.5.1. Toute la Scrum Team et les clients y assistent.

7.5.2. Durée max de 4h pour un sprint de 4 semaines

7.5.3. Objectifs : - inspecter les livrables qui ont été réalisés obtenir du feedback sur ceux-ci - adapter le backlog si besoin pour optimiser sa valeur et définir les potentiels items pour le prochain sprint

7.5.3.1. Rôle du PO : - Il explique ce qui est Done ou pas. - Il discute du Product Backlog et projette la date d'achèvement du produit si besoin.

7.5.3.2. Toute la Scrum Team discute de ce qui sera fait ensuite pour fournir des données de valeur pour faire le prochain sprint planning. Actualisation selon l'évolution du marché, des échéances, du budget et ressources

7.5.4. Rôle du Scrum master : - s'assurer que l'événement a lieu - apprendre à l'équipe à faire la réunion dans le délai imparti - s'assurer que les participants ont compris l'objectif de la sprint review - faciliter la réunion - participer à la réunion

7.6. Sprint Retrospective

7.6.1. Toute la Scrum Team y participe

7.6.2. Durée max de 3h pour un sprint de 4 semaines

7.6.3. Objectif pour la Scrum Team : - inspecter sa manière de travailler - planifier des améliorations à mettre en place lors du prochain sprint

7.6.3.1. Rôle de la Scrum team : - Comment le précédent sprint s'est déroulé concernant les personnes, les relations, les process et les outils ? - identifier et prioriser les éléments qui se sont bien/mal passés - prévoir des actions à mettre en place dans le prochain sprint pour des améliorations potentielles - adapter la définition of done pour améliorer la qualité du produit

7.6.4. Rôle du Scrum master : - s'assurer que l'événement a lieu - apprendre à l'équipe à faire la réunion dans le délai imparti - s'assurer que les participants ont compris l'objectif de l'événement - faciliter la réunion - participer à la réunion - encourager la Scrum team à s'améliorer dans le cadre du process agile