Glossaire de la methodologie Scrum

[My Blog]

Backlog du produit

La principale source d'information sur le projet est le Backlog du produit, qui définit les exigences auxquelles l'application doit satisfaire afin de réussir. Les exigences sont exprimées en tant que récits d'utilisateur du format:



"En tant que: (rôle) Je veux: (description de la fonction) Alors je peux: (statement-value)"

Les histoires d'utilisateurs (ou simplement "histoires") sont des déclarations courtes identifiant le type de personne, la fonctionnalité dont elles ont besoin pour réaliser leurs propres termes et la valeur qu'elles s'attendent à obtenir. Ceux-ci sont intentionnellement exprimés en termes très personnels et sont conservés à ce qui correspondrait à une carte d'index. Garder les histoires courtes est important car il garantit que les exigences sont fines.

Sagas, épiques et histoires d'utilisateurs

Il est souvent utile de classer les histoires comme des sagas, des épopées et des histoires pour refléter les différences dans leur portée et leur durée de vie.

Learn more info. check out here: scrum gestion de projet

Sagas

Les Sagas sont des exigences de "grande image" qui sont extrêmement larges dans leur portée. Un exemple d'une saga pourrait être:

"En tant que: utilisateur final que je souhaite: utiliser une application qui a des performances exceptionnelles et répond à mes demandes en quelques secondes. Je peux: terminer rapidement mon travail et rester concentré sur ma tâche immédiate."

Ce type d'exigence est très large dans sa portée et prévoit une attente pour toutes les fonctions de l'application. Ainsi, toutes les fonctionnalités et toutes les fonctionnalités doivent en tenir compte. Cela signifie que plusieurs épopées et histoires seront basées sur ce type de saga. Les sagas ont généralement une longue vie et, si elles doivent être respectées, elles ne sont pas entièrement complétées jusqu'à ce que toutes les épopées de niveau inférieur et les histoires enracinées soient terminées.

Épopees

Le prochain type d'histoire est une épopée. Comme une saga, les épopées ont une durée de vie de sprints multiples et ne peuvent être considérées comme complètes jusqu'à ce que toutes les histoires basées sur elles soient également complétées. Cependant, les épopées ont une focalisation plus étroite qu'une saga et, même si elles sont encore larges, elles peuvent être complétées en quelques sprints. Par exemple,

"En tant que: contributeur de contenu, je souhaite: catégoriser le contenu que je crée. Je peux: assurer que les lecteurs puissent facilement le localiser".

Ce type d'exigence entraînera plusieurs histoires définissant comment les catégories de contenu sont définies et maintenues, comment elles sont associées au contenu et comment les fonctions de recherche les utilisent.

Histoires

L'histoire de l'utilisateur est la description la plus détaillée des fonctionnalités. Les histoires décrivent les livrables qui peuvent être complétés en un seul sprint. Un exemple est le suivant:

"En tant qu'utilisateur final expérimenté Je souhaite: Enregistrer mon travail à l'aide d'une séquence de touches de commande Je peux: sauvegarder rapidement mon travail sans plusieurs clics"

Il est important de noter qu'il existe de nombreux détails sur lesquels l'utilisateur final peut ne pas être conscient ou même s'intéresser à la spécification d'une exigence. Il incombe à l'équipe de développement et de développement du produit d'affiner les histoires afin qu'elles puissent être mises en action. Dans de nombreux cas, cela signifie que les sagas, les épopées et les histoires fournies par le client doivent être décomposées en unités de travail plus discrètes et donc actionnables.

Il existe un certain nombre d'outils qui peuvent aider à la capture et à la gestion des histoires, y compris Jira et Trello. Cependant, les histoires peuvent être maintenues avec une méthode manuelle telle que des fiches.

Métrique

Le produit répond-il aux besoins et aux attentes de l'utilisateur final? Cette question est la mesure ultime de succès pour tout projet. Mais les mesures sont également utiles à l'équipe pour mesurer leur progression et leur efficacité. Deux indicateurs simples, mais efficaces, sont le tableau de combustion et la vitesse.

Les deux sont basés sur des points d'histoire, ce qui est une mesure de l'effort relatif ou des difficultés nécessaires pour compléter une histoire donnée. Une partie du processus de toilettage du carnet de commandes est que l'équipe Scrum examine les histoires d'utilisateurs et estime le nombre de points d'histoire requis pour chacun d'eux. Il existe de nombreuses méthodes différentes qui peuvent être utilisées pour cela et celle choisie par l'équipe Scrum n'est pas aussi importante que la nécessité d'être cohérente lors de l'estimation des points de l'histoire.

Le diagramme de gravure est utilisé pour fournir une vue graphique du nombre d'histoires dans l'arriéré qui a été complété par rapport au nombre total restant à travers les sprints.

La vitesse mesure le taux moyen auquel les histoires sont complétées par les sprints. La méthode de base consiste à diviser le nombre de points d'histoire complétés par le nombre total dans l'arriéré du produit. Au fil du temps, la vitesse est une mesure du travail qu'on peut s'attendre à compléter dans un sprint et elle permet de s'assurer que l'équipe ne surpasse pas le nombre de points à compléter dans un sprint donné.

Les équipes trouvent souvent un haut degré de variance de la vitesse au début d'un projet, mais elle tend à s'alléger au fur et à mesure que l'équipe acquière de l'expérience avec l'application et en équipe. Il est important de noter que cela ne signifie pas que l'équipe s'arrête de "se détendre". Il incombe à l'équipe de s'efforcer continuellement de rechercher des gains d'efficacité dans le processus de développement qui permettront d'augmenter la vitesse tant que la qualité n'est pas compromise.

For more details visit here: la méthode scrum