User Story : support de conversation, de validation et de planification.
[cette page va évoluer d'ici la fin de l'année !...]
téléchargements
exemple
Voici un exemple de User Story :
storypedia
- acceptance tests : permet de vérifier si les stories sont achevées et développées comme attendues. Au moins écrit au dos de la story.
- coût (d’une story) : estimé par les developpeurs en fonction du risque et de la compléxité. L’unité est le story point. Les US doivent faire entre 1/2 jour et 1 semaine).
- epic : user story trop vaste (complexes ou composés), qui doit être découpée en stories. Utile pour matérialiser les parties futures du système : sert de support avant d’être redécoupée.
- équipe d’utilisateurs (EU) : constituée des rôles de prioritisation, de réponse aux questions fonctionnelles des développeurs, d’utilisation du logiciel (utilisateurs finaux), de product manager, de rédaction des user stories, d’écriture et jeu des tests d’acceptance.
- expectations : attentes de l’EU sous forme d’”acceptance tests”.
- itération : la de durée (de 1 à 4 semaines) est établie par l’équipe, puis doit rester constante durant le projet. Sert de référence pour définir la “vélocité”.
- planning (d'itération ou de release) : regroupement des stories par itération selon leur priorité (coût).
- release : ensemble de fonctionnalités, regroupement d’itérations.
- spike : tâche / story d’exploration technique, timeboxée.
- story card : partie visible de la story, mais la moins importante !
- story point : unité “arbitraire” utilisée par les développeurs pour estimer la durée d’une US. Voir “coût” et “vélocité”.
- user story (ou story) : “Card, Conversation, Confirmation” (Jeffries).
- vélocité : nombre de story points réalisés par itération. Ne sont comptabilisés que les points des stories entièrement achevées.
planning d’itération
Prendre les stories par ordre de priorité (coût décroissant), en faisant des piles, sans dépasser la vélocité : se sont les itérations successives.
On peut “remplir” une itération avec une story de moindre importance mais plus petite.
On peut découper une story en plusieurs stories plus petites.
Une fois les itérations définies, l’EU peut regrouper des itérations successives en ensembles fonctionnels : se sont les releases.
Exemple :
2 itérations, indiqué sous la forme [story:coût], la story C, trop grosse (4 points au total) a été coupée
- itération 1 : [A:3 B:4 C1:2 F:1]
- itération 2 : [C2:2 D:4 E:4]
tests d’acceptation
Précisent les suppositions et attentes de l’EU.
Doivent donc être rédigés en début d’itération, le plus tôt possible.
Au moins écrits au dos de la story, voire rédigés dans un framework technique permettant d’automatiser les tests.
Automatiser les tests est vital dans un développement itératif.
processus
Etapes successives lors de la réalisation d'un projet et d'un planning game :
- Définir la matrice utilisateur / rôle (chooseuser.com)
- L’équipe fixe la durée d’une itération pour tout le projet (1 à 4 semaines)
- L’équipe crée les stories sur la base d’une conversation.
- L’EU donne les priorités aux stories en fonction de leur valeur pour l’organisation.
- Les développeurs donnent leur avis sur les priorités (fonction du risque technique ou la complémentarité de stories)
- Les développeurs estiment les stories en story point.
- L’EU fait le planning d’itération.
tips
La story doit être rédigée par l’EU, dans son langage, pour pouvoir être valorisée. Pas de story technique.
Si les développeurs n’arrivent pas estimer une story c’est probablement qu’il ne maîtrise pas le métier (discuter avec l’EU), et/ou la technique (faire un spike timeboxé), ou que la story est trop vaste (la découper).
Pour une story difficile à estimer, on pourra créer une story “spike” puis la story de réalisation qu’on estimera après que l’exploration soit faite.
On peut regrouper diverses petites tâches (debug, retouche interface graphique...) en une même story.
Une story non testable est bien souvent non fonctionnelle.
Pour plus de détails :
