Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Let’s Scrum Together Page 2 Introduction Scrumble est un jeu qui modèle les rôl

Let’s Scrum Together Page 2 Introduction Scrumble est un jeu qui modèle les rôles, les événements et les artéfacts de Scrum. Il a pour buts de présenter les opérations et les préceptes de Scrum à une équipe qui désire se développer autour de ce framework. Le jeu permet, dans une atmosphère relaxante, de mettre en lumière de nombreux problèmes auxquels les équipes sont confrontées et de trouver dans le même temps des solutions de manière spontanée. Aperçu du jeu Le plateau se compose de la manière suivante (de l’extérieur vers l’intérieur) - En Jaune, deux cercles pour les tâches - En vert, un cercle pour les points de la dette technique - Au centre en gris, les différentes phases représentées par les jours (1-9), la revue, la rétrospective et le planning Page 3 Différentes cartes Les User Stories à réaliser Ainsi qu’un certain nombre de marqueurs sous forme de jetons - Marqueur d’équipe - Marqueur de la dette technique - Marqueur d’une User Story Les rôles dans le jeu Scrum Master Le Scrum Master est le maître de jeu. Il ne participe pas activement en tant que joueur au sein de jeu mais son rôle est vital puisqu’il conduit les activités et facilite les décisions aux moments clés. Product Owner Le Product Owner est responsable pour le produit. Son rôle est de se concentrer sur la valeur délivrée ainsi que comme personne référente en ce qui concerne le domaine d’activités pour lequel le produit est conçu. Membre de l’équipe de développement Testeur, analyste, développeur junior ou expérimenté, administrateur système, graphiste, … Tous sont égaux au sein de l’équipe (dans la vraie vie de Scrum et dans le jeu). Ils s’autoorganisent et contribuent au développement et à l’incrément du produit durant les diverses phases. User stories Les User stories représentent les éléments à développer Page 4 Une User Story comporte - Un numéro d’identification (En haut à gauche) - Une dépendance à une autre User Story (En haut à droite) - Une description As [Who] I Want [What] - Une valeur pour le Business, respectivement pour le Product Owner (En bas à gauche) - Une taille en termes de complexité de développement (Voir plus bas) Phases du jeu Initialisation du jeu - Placer le marqueur de l’équipe sur 0 - Mélanger les cartes Problem, Daily, Review - Placer le marqueur de la dette technique sur 15 Pre-Sprint Le Product Owner présente le produit que l’équipe va développer basé sur le scénario choisi. Le Product Owner est la seule personne qui donne la vision du produit et les éléments du Backlog ainsi que l’ordre des User Stories à réaliser. Le Backlog est le container de toutes les User Stories pour les Sprints Il est important que les participants connaissent les idées et le thème du produit pour s’assurer leur participation. Une fois l’ensemble des User Stories présenté et compris, les membres de l’équipe doivent estimer la complexité relative (la taille) pour chaque User Story à implémenter. Il faut garder en mémoire que l’estimation exacte d’un effort et de la charge de travail n’est jamais possible. Tous les êtres humains, sont par nature, mauvais dans l’estimation absolue. Le fait d’exécuter les User Stories sous forme de Sprint réduit généralement l’erreur et offre la place à l’auto amélioration. La notion de taille de T-Shirt facilite le classement des User Stories par taille Page 5 Les Users Stories sont classées par l’équipe, priorité au sein de chaque taille en fonction de leur valeur. Sprint Dans un ordre chronologique le sprint se compose - D’une session de planification (Sprint Planning) - De neuf jours de développement (neufs tours) - D’une session de revue - D’une session de rétrospective. Sprint Planning Le Product Owner choisit en fonction des priorités et de la valeur la plus élevée qu’il désire les Users Stories, ainsi que les éventuelles User Stories dépendantes (dépendance en haut à droite de chaque User Story) que l’équipe va devoir réaliser dans le Sprint. Les User Stories choisies forment le Sprint Backlog et sont l’objectif du Sprint. L’équipe calcule alors le nombre de tâche à réaliser pour compléter chaque User Story à l’aide de la formule basée sur la dette technique ainsi que du nombre de membres du team. Exemple : Une équipe de 5 personnes ayant une tâche de complexité M et une dette technique Low  (Low x 3-M) == 12x5 = 60 tâches. L’équipe notera sur un sticker, pour chaque User Story, le nombre de tâches à réaliser pour la User Story et la couleur d’un marqueur qu’elle place sur le plateau de jeu, sur la case correspondant au nombre de tâches à réaliser. Page 6 Si le nombre de tâches à réaliser excède 100, placer plusieurs marqueurs de la même couleur, l’équipe devra ensuite tous les collecter. Une tâche sera considérée comme réalisée lorsque le marqueur de l’équipe atteindra le marqueur correspondant à la User Story. Jours de développement (Day 1  Day 9) Chaque membre de l’équipe, hormis le Product Owner et le Scrum Master lancent un dé à tour de rôle pour, à choix - Exécuter une tâche - Diminuer la dette technique Le choix doit être évoqué avant de lancer le dé. Ce choix est à la libre discrétion du joueur en fonction de ce qu’il considère apporter le plus de valeur au sprint ou au produit. Si le joueur décide de réduire la dette technique, il déplacera le marqueur en arrière, en diminution, correspondant au nombre de points indiqué sur le dé. Si le joueur décide d’exécuter une tâche, il déplacera le marqueur de l’équipe en fonction du résultat indiqué par le dé. Si le dé indique les valeurs suivantes - Le dé indique 1, le joueur comptabilise le point et relance le dé pour une deuxième chance - Le dé indique 6, le joueur pioche une carte  Problem, lit cette dernière à haute voix pour l’équipe et effectue l’action indiqué sur cette dernière. Le marqueur n’est pas déplacé. La carte  Problem est généralement une complication dans le jeu. L’équipe agit ensemble pour résoudre la difficulté, pas uniquement le joueur qui a pioché la carte. Une User Story est complétée Une User Story est considérée comme complétée lorsque le marqueur de l’équipe atteint ou dépasse le marqueur (ou tous les marqueurs) de la User Story. La User Story est marquée comme réalisée et le marqueur de l’équipe est placé sur 0 (ou sur la différence de points obtenus en sus) pour commencer une nouvelle User Story. Lorsqu’un tour est terminé (tous les joueurs ayant lancé les dés), on passe au jour suivant jusqu’à la revue. Daily A chaque nouveau jour, mis à part le jour 1 ou lors de la Review, un joueur pioche une carte Daily et en fait part au Team. Il n’y a plus de tâche en jeu Si l’ensemble des tâches sont réalisées avant le jour 9, l’équipe choisit une des trois options - Ajouter une ou plusieurs User Stories au Backlog du Sprint courant. Cela ajoutera de la valeur livrée au Sprint. Page 7 - Payer la dette technique - Finir le Sprint. Cela n’est possible que s’il n’y a plus de User Story dans le Backlog du produit. Rendez-vous ensuite directement à la dernière Review Sprint Review Lorsque la revue est atteinte le Product Owner inspecte les User Stories réalisées pendant le Sprint et calcule les scores Il félicite, encourage et donne des conseils constructifs à l’équipe (max 5 minutes) Le Product Owner pioche une carte Review par User Story complétée pendant le sprint User Stories non-complétées Les User Stories non-complétées, pour cause de dette technique ou d’autres activités sont revues et replanifiées. L’équipe reçoit un malus sous la forme de points dans la dette technique. 1 point de dette technique pour chaque lot de 5 tâches non réalisées. La User Story commencée est diminuée du nombre de tâches déjà réalisées pour le prochain Sprint, le marqueur de la User Story est placé au nouvel endroit sur le plateau. Les Users Stories sur le plateau du jeu ne sont pas affectées par la nouvelle dette technique. Sprint Rétrospective Le marqueur est déplacé sur Sprint Rétrospective Ce moment est réservé à chaque joueur pour exprimer ce qu’il a aimé (I like), ce qu’il n’a pas aimé (I dislike) ou ce qu’il voudrait (I would like) pour le sprint suivant. (max. 2 minutes par participant) Dans le réel, cette phase est la plus importante puisqu’elle permet d’échanger, de s’améliorer et de s’approcher de plus en plus des principes Agiles. Il s’agit de la partie la plus formatrice de la phase. http://agilemanifesto.org/principles.html Le Sprint est maintenant terminé. Retour à la phase Sprint Planning Page 8 La dette technique, votre pire ennemi La dette technique est votre pire ennemi, elle est partout et sous toutes les formes Le cauchemar de beaucoup de Scrum Masters est la dette technique. Quelle soit explicite ou non, elle représente un dû envers les utilisateurs ou les parties prenantes. La dette technique impacte le jeu à différents moments, par uploads/Management/ scrumble-explication-des-regles.pdf