Scrum Mini Reference and Guide

Cet article est un mini-guide et un guide de la méthode Scrum, créé à la suite de la lecture du livre de Sutherland, d'articles sur Internet et d'une application pratique.

Il est nécessaire de faire la distinction entre Agile et Scrum. Agile est une méthodologie (science) et Scrum est une méthode pour atteindre un objectif.

Avec Scrum, il est important de disposer d'une véritable équipe de professionnels, de respecter les conditions de transparence, d'ouverture et de confiance.

Les membres de l'équipe doivent être satisfaits de leurs activités, être heureux dans leur travail. Un état de bonheur conduit les gens à d'excellents résultats.

Les gens heureux ont 50% plus de succès. Ils sont donc 50% plus productifs s'ils sont heureux et trouvent un sens à leur travail. Dans le même temps, ils sont 88% plus fidèles, car ils comprennent qu'ils travaillent pour une bonne raison, consacrant la moitié de leur temps au développement de cette entreprise

- Dr Corrie Block, expert en stratégie d'entreprise en évaluation du bonheur.

Scrum Mini Guide

Scrum - Scrum, une méthode de gestion de projet flexible. Le terme vient d'un match de rugby.

Product Owner - Product Owner , le lien entre le client et l'équipe de développement. La responsabilité la plus importante du Product Owner est la création et le contrôle du Product Backlog.

Responsabilités et responsabilités clés du Product Owner dans la gestion du Product Backlog:

• définir des éléments de backlog pour un produit;
• la bonne disposition des éléments pour optimiser la réalisation de l'objectif;
• Assurer la clarté et la transparence du Product Backlog;
• assurer la transparence et la compréhension des exigences sur lesquelles toute l'équipe Scrum devra travailler;
• optimisation générale pour obtenir la valeur la plus élevée du travail de l'équipe de développement;
• responsabilité de comprendre l'arriéré par l'équipe de développement.

Scrum Team (Scrum Team) - une image collective d'une équipe composée de l'équipe de développement, Scrum Master et Product Owner. L'équipe est totalement autonome et ne dépend pas de spécialistes externes ou de clients.

Scrum Master (scrum master) - arbitre qui organise et tient des réunions, surveille le respect de tous les principes de la mêlée, résout les contradictions et protège l'équipe des distractions, facilite les réunions, est responsable de la comptabilité, du stockage et de la délivrance des équipements SCRUM. Ce rôle n'implique rien d'autre que le processus de mêlée correct.

Scrum Master ne donne pas de tâches, mais élimine les problèmes qui apparaissent à l'intérieur de l'équipe.
Une équipe interfonctionnelle de développeurs de projets, composée de spécialistes de différents profils: programmeurs, testeurs, analystes, architectes, etc.

Équipe de développement (équipe de développement) - une équipe de développement, une équipe interfonctionnelle de développeurs de projets, composée de spécialistes dans divers domaines: programmeurs, testeurs, analystes, architectes, etc. La taille de l'équipe est de 5 à 9 personnes (5 est optimale). L'équipe est le seul participant au développement pleinement impliqué et est responsable du résultat dans son ensemble. Cette unité de travail est autosuffisante, autonome et auto-organisée. C'est comme un organisme unique composé d'éléments séparés.

Parties prenantes (actionnaires) - littéralement actionnaires, personnes qui initient le projet (clients commerciaux), à qui le projet Scrum apportera des avantages. Ils ne sont impliqués dans la mêlée que lors de la Sprint Review.

Utilisateur - utilisateur du produit.

Backlog de produit (backlog de produit) - ou exigences de produit de backlog, souhaits des clients pour la fonctionnalité et la conception, tous les «souhaits» ils sont classés par ordre d'importance et de valeur pour le client.

Epic est l'une des nombreuses fonctionnalités mondiales du produit. L'épopée peut contenir une User Story, par exemple, un ensemble de souhaits d'un utilisateur ou une liste de tâches (tâche) pour la mise en œuvre d'Epic.

User Story - ou Story, une intrigue qui contient les souhaits de l'utilisateur.

Tâche (tâche) - une tâche, un fragment qui doit être achevé pour atteindre l'objectif du projet.

Sprint (sprint) - une période de 1 à 4 semaines, pendant laquelle l'équipe crée une partie du produit, prête pour la démonstration et précieuse pour le client. La durée optimale du sprint est de 1 à 2 semaines. Ceci est fait pour que les informations reçues au début de la première semaine ne soient pas oubliées à la fin de la deuxième semaine et que le temps ne soit pas nécessaire pour rétablir les communications.

Sprint Goal ( Sprint Goal ) - le but du sprint.

Réunion de planification de sprint (Sprint Planin Mitin) - Planification de sprint, réunion Scrum, où l'équipe Scrum participe. Les tâches de backlog pouvant être exécutées dans le sprint sont sélectionnées.

Scrum Poker est un moyen rapide et précis de collecter des scores en utilisant un jeu de cartes avec des numéros de Fibonacci (1,2,3,5,8,13). Vous pouvez utiliser des applications mobiles pour Scrum Poker. Les tâches avec une évaluation de 13 doivent être divisées en plus petites.

Points d'histoire - une unité pour évaluer la difficulté de terminer une tâche. Il est logique d'appliquer des Story Points si le projet se compose de 3 sprints ou plus, car l'équipe accumule des statistiques et de l'expérience dans l'évaluation des tâches. Sur un projet d'un ou deux sprints, cela n'a aucun sens d'utiliser des Story Points, sinon pour s'entraîner.

Daily Scrum Meeting (Daily Scrum Mitin) - une réunion quotidienne de pas plus de 15 minutes, tenue en même temps. Tim Scrum participe, tout le monde peut observer. Dirigé par un Scrum Master. Le but du rallye est l'échange rapide d'informations, tout le monde est au courant de ce qui se passe, il n'y a pas de lacunes de communication. Trois questions sont posées: qu'avez-vous fait hier? que vas-tu faire aujourd'hui quels sont les obstacles sur le chemin du but?

Revue de sprint (revue de sprint) - revue de sprint, toutes les personnes impliquées, la réunion est ouverte. L'équipe raconte ce qui a été fait et démontre les parties du projet qui sont enfin prêtes.

Sprint Retrospective Meeting (sprint retrospective Mitin) - une rétrospective, mêlant scrum tim. Réunion à la table ronde. Des questions sont discutées: qu'est-ce qui s'est bien passé et qu'est-ce qui a mal tourné? que pourrait-on faire de mieux? L'essentiel est de ne condamner personne! Le workflow est à l'étude. L'objectif est d'améliorer le workflow, de devenir une "super" équipe.

La définition de Terminé (DoD) est le critère qui détermine le degré de préparation d'une tâche. Il est utilisé dans les cas où il est finalement impossible de vérifier l'état de préparation de la tâche, par exemple, si l'élément fonctionnel se trouve dans une autre mêlée d'équipe ou d'entreprise. La description DoD commence par la ligne «done =», par exemple, done = la fonctionnalité est implémentée dans un environnement de test, le déchargement et la vérification dans l'environnement principal sont requis.

Velocity (Velocity) - vitesse d'équipe; Pour l'analyse, un graphique de vitesse est construit, où l'axe X compte les sprints et les points d'histoire de l'axe Y. Sur la base de ces indicateurs, la vitesse moyenne et les points d'histoire sont construits.

Burndown Chart - graphique de la combustion des tâches. La direction du graphique est de haut en bas. Conçu pour suivre la quantité de travail restante, où l'axe des x est le nombre de jours de sprint et l'axe des y est le nombre de points d'histoire. Le premier jour du sprint correspond au nombre maximum de Story Points.

Burnup Chart - Burnup Chart. La direction du graphique va de bas en haut. Conçu pour suivre la quantité de travail, où sur l'axe X le nombre de jours de sprint et sur l'axe Y le nombre de points d'histoire. Le dernier jour du sprint correspond au nombre maximum de Story Points.

Arrêt anormal (arrêt anormal) - arrêt du sprint, action anormale. L'arrêt est initié par le Product Owner. Un rassemblement a lieu pour discuter des causes de l'arrêt anormal. Puis Sprint recommence.

Guide Scrum

Carnet de produit
Il est formé lors d'une assemblée générale ou d'entretiens individuels avec toutes les parties intéressées (parties prenantes, utilisateurs). La User Story, les exigences et les souhaits sont enregistrés.

1. Les principaux champs de la carte: identifiant, nom, importance, note, version, description, auteur, artiste;
2. Champs supplémentaires dans la carte. Par exemple, le champ «Objet» - la note du produit dans la boutique en ligne n'est pas nécessaire pour le moment, et la note comprend quelques tâches. Ensuite, vous pouvez modifier "l'importance" de toutes les tâches avec ce thème;
3. Les tâches sont mieux réparties dans les mêmes types.

Les tâches avec des composants comme: 3IIIC, 5VE sont plus compliquées et nécessitent plus de temps.

123, ABC est plus rapide car le cerveau n'a pas besoin de basculer entre différents types de tâches.

Histoire d'utilisateur

1. Recevoir un objectif commercial d'un client. Nous composons Impact Map pour chaque objectif commercial: Pourquoi? -> Qui? -> Comment? -> Quoi? (Pourquoi? -> Qui? -> Comment? -> Que faut-il faire?);
2. Libellé de la User Story:
   En tant qu'utilisateur <...> je veux faire <...> pour obtenir <...>.
   En tant que responsable d'entrepôt, je reçois un rapport de solde de stock pour prendre une décision PLUS RAPIDEMENT;
   Libellé sans TO (c'est mieux).
   En tant qu '<utilisateur>, je <veux obtenir quelque chose>, <dans un tel but>.
   En tant que responsable d'entrepôt, je reçois un rapport de bilan PLUS RAPIDEMENT.
3. La division des "acteurs" en groupes: cible, importante, moins importante, etc. Attribuer des noms uniques aux acteurs de ces groupes, même s'il existe des rôles identiques pour les «utilisateurs système»;
4. Ecrire une histoire du point de vue de ces acteurs aux noms uniques;
5. En conséquence, vous pouvez voir quelles histoires sont nécessaires pour les acteurs du groupe cible, d'un groupe important, etc. Par conséquent, vous pouvez prioriser;
6. Action. Il est important de décrire l'histoire au niveau de "Quoi?" plutôt que «Comment?» décrit le problème, pas sa solution. "Comment?" est avec l'équipe;
7. La valeur. Refus du libellé "To". Pour certaines histoires, vous pouvez indiquer la valeur de l'histoire au format "À", mais pas pour la plupart;
8. Le passage du concept de "valeur" (valeur) au concept d '"impact" (impact). L'histoire ne doit pas avoir de valeur, mais elle doit avoir un impact sur l'acteur qui est indiqué dans l'histoire. Cette influence mène finalement au but;
9. Les User Stories sont décomposées par importance et fonctionnalité et décomposées en tâches dans le backlog.

Affiner et évaluer l'arriéré de produits

Se produit en collaboration avec l'équipe de développement. L'équipe doit évaluer chaque tâche: est-ce faisable en principe? Y a-t-il suffisamment d'informations à exécuter?

Formé par Sprint. Réunion de planification du sprint. Scrum poker

La durée de la réunion ne dépasse pas 8 heures. Pour un sprint de 2 semaines, le rallye dure 2 heures. Pour visualiser l'exécution des tâches dans le sprint, il est pratique d'utiliser un tableau Kanban.

1. La première partie de la réunion est ouverte à tous.
   Droits de vote avec le propriétaire du produit et l'équipe de développeurs. Sélection de la user story et des tâches du Product Backlog au Sprint Backlog;
   Formulation d'objectif de sprint - Objectif de sprint. Déterminer la valeur commerciale. Une brève description de l'objectif commercial pour lequel ce sprint est effectué. Aide l'équipe à prendre des décisions éclairées ou des décisions alternatives.
2. La deuxième partie du rallye ne concernait que Scrum Team. Remplir le carnet de sprint.
   Déterminer comment l'étendue des travaux sera mise en œuvre. Discussion des détails techniques;

Scrum Poker (Planning Poker).

Points d'histoire (basés sur la série Fibonacci - 1,2,3,5,8,13). Les tâches de 13 points ou plus doivent être divisées en plus petites. Le délai pour terminer une tâche par un développeur n'est pas supérieur à un jour ou 8 heures. Si le projet n'a qu'un seul sprint, cela n'a aucun sens de définir des Story Points, car il n'y aura pas de statistiques et, par conséquent, il n'y aura aucune précision dans la détermination des notes.
Pour attribuer correctement des Story Points, vous pouvez conserver des statistiques, comme dans le tableau suivant:

1. Scrum Master dirige la réunion;
2. Le Product Owner fournit un bref aperçu de chaque tâche;
3. Il y a une discussion, des questions sont posées;
4. Les membres de l'équipe de développement sélectionnent une carte, puis la retournent;
5. Si à la suite du vote il y a une grande dispersion dans les points, alors écoutez deux personnes qui ont retourné les cartes avec la valeur minimale et maximale;
6. Puis ils votent à nouveau et attribuent des Story Points à la tâche.

Réunion de mêlée quotidienne

Il a lieu tous les jours. Tout le monde peut regarder. Seule l'équipe Scrum parle. Dirigé par Scrum Master.

1. Elle est réalisée en même temps;
2. Il ne dure strictement pas plus de 15 minutes. La solution des problèmes se fait au-delà du cadre du rallye et en tant que partie des personnes directement affectées par cet obstacle;
3. Tous ne répondent qu'à trois questions, se répondent, pas à Scrum Master: qu'est-ce que j'ai fait hier? Que vais-je faire aujourd'hui? Quels problèmes ai-je et l'équipe sur le chemin de l'objectif?

Réunion d'examen du sprint

Tout le monde est impliqué. Augmentation significative des fonctionnalités du produit. Démonstration du produit fini ou de la fonctionnalité.

Durée du rallye: une heure pour chaque semaine de sprint (2 heures de revue de sprint = sprint de 2 semaines) La préparation de cette réunion ne doit pas dépasser 2 heures.

Réunion rétrospective Sprint. Rétrospective.

Tenue le dernier jour du sprint.

Conçu pour évaluer le résultat de l'équipe. Des questions sont posées: que peut-on améliorer? comment? Comment augmenter l'efficacité de l'équipe?
Le temps rétrospectif pour un sprint de 2 semaines ne dépasse pas 2 heures.
Le concept de kaizen et de bonheur. Kaizen - amélioration continue. Des gens heureux = une équipe performante.

Vous pouvez poser des questions: Qu'est-ce qui peut vous rendre plus heureux au prochain sprint? Qu'est-ce qui vous rend plus heureux?