Ce document décrit les user stories, le backlog de produit et la méthode MoSCoW pour prioriser les exigences. Les user stories sont des exigences du système formulées du point de vue de l'utilisateur pour estimer le coût et permettre la réalisation dans un sprint. Le backlog de produit liste les fonctionnalités attendues classées par priorité. La méthode MoSCoW classe les exigences en must have, should have, could have et won't have.
0 évaluation0% ont trouvé ce document utile (0 vote)
57 vues6 pages
Ce document décrit les user stories, le backlog de produit et la méthode MoSCoW pour prioriser les exigences. Les user stories sont des exigences du système formulées du point de vue de l'utilisateur pour estimer le coût et permettre la réalisation dans un sprint. Le backlog de produit liste les fonctionnalités attendues classées par priorité. La méthode MoSCoW classe les exigences en must have, should have, could have et won't have.
Ce document décrit les user stories, le backlog de produit et la méthode MoSCoW pour prioriser les exigences. Les user stories sont des exigences du système formulées du point de vue de l'utilisateur pour estimer le coût et permettre la réalisation dans un sprint. Le backlog de produit liste les fonctionnalités attendues classées par priorité. La méthode MoSCoW classe les exigences en must have, should have, could have et won't have.
Ce document décrit les user stories, le backlog de produit et la méthode MoSCoW pour prioriser les exigences. Les user stories sont des exigences du système formulées du point de vue de l'utilisateur pour estimer le coût et permettre la réalisation dans un sprint. Le backlog de produit liste les fonctionnalités attendues classées par priorité. La méthode MoSCoW classe les exigences en must have, should have, could have et won't have.
Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
Télécharger au format pdf ou txt
Vous êtes sur la page 1/ 6
User –stories et Backlog de produit
User-stories ou scénarios : Une user story ou un scénario est une exigence du système à développer formulée en une ou deux phrases dans le langage des utilisateurs pour servir un but. Sa granularité doit permettre à l’équipe de réalisation d’estimer son coût et de la réaliser entièrement à l’intérieur d’un sprint (ou une itération).
L’avantage des user-stories est qu’elles facilitent la démarche en deux temps : générales et grossières au début, elles s’enrichissent ensuite d’exemples, de tests d’acceptation. Elles facilitent la communication, l’ajout ou la suppression de détails.
Une user story s’écrit comme suit;
En tant que <rôle>
Je veux <liste de tâches>
Afin de <valeur ajoutée ou résultat>
Exemples
1. En tant qu’acheteur en ligne, je veux pouvoir ajouter des items à mon panier supprimer les items afin de pouvoir n’acheter que ce dont je suis vraiment certain. 2. En tant que client, je peux consulter la liste des factures émises. 3. En tant que client (du projet), je peux consulter la liste de mes clients. 4. En tant que client, je peux connaître le montant total des factures impayées.
Une bonne user story doit respecter l’acronyme INVEST
I pour Indépendante : lorsque le client peut en toute liberté décider de l’ordre dans lequel les scénarios (story) est implémenté sans qu’interviennent des contraintes techniques. Si des stories sont fortement liées, alors il faut les combiner
Bon exemple :
En tant que client, je veux consulter la liste des factures émises.
Mauvais exemple :
En tant que client, je veux créer la listes des factures..
Préparé par Saliha Yacoub Automne 2013 Page 1
N pour Négociable : L’équipe de développement n’est pas contrainte par la manière dont sera implémenté le scénario : Elle a la latitude d’imaginer une solution efficace
Bon exemple :
En tant que client, je peux connaître le montant total des factures impayées.
Mauvais exemple
En tant que client, je veux, lorsque je clique sur le bouton «calculer» une ligne s’ajoute et on affiche sur cette ligne le montant total des factures impayées.
V pour Vertical : un bon scénario ou story décrit une fonctionnalité complète de
l’application dont le client apprécie l’intérêt.
Bon exemple :
Un bon découpage qui fait apparaitre les scénarios distincts rendus par le service de facturation :
Consulter la liste des factures émises
Afficher la liste des factures ordonnées par date Afficher la liste des factures par adresse de livraison Consulter une facture client …
Mauvais exemple :
Créer la base de données pour le module de facturation. Créer l’interface graphique pour la facturation
E : pour Estimé : pour que le scénario puissent servir de base à la planification, on
connaître au moins une estimation du coût d’implémentation.
Bon exemple :
Implémenter les règles métier R1, et R2
R1 : si le nom de l’utilisateur existe déjà, lorsque l’acheteur en ligne essaye de créer son compte, alors le message «ce compte existe déjà doit »être affiché.
R2, un rabais de 5% est octroyé pour tous les clients dont le montant total de la facture dépasse les 1000$.
Préparé par Saliha Yacoub Automne 2013 Page 2
Mauvais exemple :
Garantir le respect des règles de gestion en vigueur.
S pour Suffisamment petit (Size appropriately): toujours, pour planifier sa réalisation un
scénario doit être réalisable en peu de temps pour que l’équipe de projet puisse en planifier plusieurs dans un même sprint (itération)
Mauvais exemple : réaliser le module de facturation – il faudra découper –
Bon exemple : voir V pour vertical
T pour Testable : planifier un test d’acceptation est un excellent moyen pour vérifier que tout le monde a bien compris le scénario ou la story.
Exemple de test d’acceptation :
En tant que client, je veux connaître la liste des factures par date.
Test d’acceptation : afficher la liste des factures ordonnées par la date de
facturation
Le backlog de produit :
Le backlog du produit est la liste des fonctionnalités attendues d’un produit.
Scrum n’impose pas de pratique pour identifier et nommer les éléments du backlog. L’usage le plus courant est de définir un élément comme étant une story ou un cas d’utilisation
Dans un backlog de produit, les stories sont rangées (Classées) selon l’ordre envisagé pour leur réalisation. Cette notion de priorité prend une grande importance dans le développement itératif.
Préparé par Saliha Yacoub Automne 2013 Page 3
Exemple simplifié de backlog de produit
La colonne Effort ou charge désigne le nombre de jours/homme.
5jours/homme : a une durée de 5 jours si le nombre de ressources qui travaillent en
parallèle et à temps plein est égal à 1. A une durée de 10 jours si le nombre de ressources qui travaillent en parallèle et à mi-temps est égal à 1. A une durée de 1 jours si le nombre de ressources qui travaillent en parallèle et à temps plein est égal à 5
La colonne risque : indique le niveau de complexité technique
Scénario ou story Priorité Effort ou Risque
charge En tant qu’administrateur, je dois pouvoir M 1 1 supprimer un usager du système sans le faire palnter
En tant que client, je veux que mon robot M 2 1
puisse trier les pièces selon leur forme.
En tant que client, je veux que mon robot M 10 3
se déplace entre le point A et le point B selon le chemin le plus court En tant que candidat, je dois pouvoir M 3 1 soumettre mon CV par interne.
Exemple plus détaillé (approprié au backlog de sprint)
Scénario ou Niveau Niveau détaillé Priori Risq Effo
story utilisateur (cas té ue rt d’utilisation) En tant que Réaliser un Construire le M 1 1 recruteur je veux formulaire de formulaire avec tous recevoir les mise en les champs 1 1 candidatures via candidature M 1 1 notre site Indiquer les champs internet. Je obligatoires M souhaite afficher la liste des Sélectionner dans 2 1 candidats par une liste les champs domaine de de compétence pour compétences. le poste. La liste est S 2 1 triée par ordre alphabétique
Préparé par Saliha Yacoub Automne 2013 Page 4
Avoir une zone de C 2 2 texte de 500 caractères pour les motivations pour le M 2 poste
Trier la liste des
compétences selon le poste
Enregistrer le formulaire correctement
Lister les Afficher la liste des M 1 1
candidats par candidats selon les domaine de trois premières compétences compétences. M 1 1 Lister les candidats selon un résumé d’expérience (à partir de la liste précédente) C 1 1
En plus des compétences, afficher les candidats W 2 2 par niveau de scolarisation
En plus des compétences, afficher les candidats par ordre d’éloignement
Préparé par Saliha Yacoub Automne 2013 Page 5
La méthode MoSCow pour les priorités :
La technique utilisée pour prioriser les besoins dans un contexte itératif est celle de MoSCoW. L'avantage de la méthode MoSCoW réside dans la signification de l'acronyme, qui est plus compréhensible que d'autres techniques de priorisation comme élevé/moyen/faible
M pour Must Have : DOIT être fait. L’exigence est essentielle. Si elle n’est pas faîte le projet échoue. On peut dire également priorité haute.
S pour Should Have : Il s’agit d’une exigence essentielle, qu’il faut faire dans la mesure du possible (DEVRAIT). Mais si elle n’est pas faîte, on peut la contourner et la livrer plus tard.
C pour Could Have: Il s’agit d’une exigence souhaitable. Elle POURRAIT être faîte dans la mesure où elle n’a pas d’impact sur les autres tâches
W pour Won’t Have Il s’agit d’une exigence «Luxe». NE SERA PAS faîte cette fois mais plus tard, mais intéressante et à garder pour la prochaine version
Ce qu’il faut faire :
cultiver le backlog : la backlog évolue dans le temps, il faudra le mettre à jour.
partager le backlog avec toute l'équipe surveiller la taille du backlog : ne pas avoir plus de 150 éléments à faire dans le backlog
Éviter :
D’avoir plusieurs backlog pour le même de produit
De ne pas avoir de backlog De confondre le backlog de produit avec le backlog de sprint
Sources : Gestion de projet agile 3e Édition , Véronique Messager Rota, Eyrolles 2011.
SCRUM : le guide pratique de la méthode agile la plus populiare., Claude Aubrey, DUNOD 2011.
