MàJ: Un bon récap et le TABLEAU SYNTHETIQUE DES DIFFERENCES use case user stories dans ce billet Use Case vs User Story
« User stories » (c’est à dire « Récits d’utilisateurs » ou plutôt « Histoires d’utilisateur« comme le suggère Claude Aubry) et « Use cases » (« Cas d’utilisation ») ont des similitudes (mon précédent billet, « Use cases, User Stories ? « ) mais aussi de réelles différences qui, en fonction de notre contexte, vont nous permettre d’opter pour l’une ou l’autre de ces deux techniques de spécification des exigences fonctionnelles:
- « User stories » et « Use cases » n’ont pas la même portée, n’ont pas le même niveau de détail. Une « User story » s’écrit en une courte phrase (Rôle -> But) alors que le « Use case » est beaucoup plus riche en informations. Il possede un Titre (le but), est liè à un Acteur, propose un Résumé, et surtout, décrit un Déclencheur, un Scénario nominal (séquence d’actions de 3 à 9 étapes), les Variations à ce scénario nominal (à toutes les étapes), ainsi que tous les Cas d’erreur et leur mode gestion. Il peut décrire aussi les règles metiers et les données.
- Une « User story » propose donc uniquement un but, pas une séquence d’actions.
- Une « User story » correspond souvent et seulement à l’un des scénarios (nominal ou alternatif) du « Use case ».
- Une « User story » ne nécessite pas un travail d’analyse aussi poussé que le « Use case » (spécification mais aussi gestion, une activité trop souvent sous estimée).
- Les « User stories » émergent plus rapidement (en 1 ou 2 ateliers de travail).
- Les « User stories » se lisent plus facilement d’autant que les « Use cases » sont souvent mal écrits ou mal présentés.
- Les « User stories » sont rédigées (en principe) sur des cartes: leur durée de vie est limitée et elles n’ont pas pour vocation à être conservées (contrairement aux « Use cases »). Or, ce besoin de traçabilité peut être réel.
- Les « User stories » reposent sur un mode oral, collaboratif, de proximité : elles sont discutées (Customer / Developer) et tout n’est pas rédigé (contrairement aux « Use cases »). Or ce besoin de formalisme peut lui aussi être réel (gros projets, équipe importante, offshore…).
- Les « User stories » contiennent d’entrée des tests d’acceptation (rédigés au dos de la carte); les « Use cases » sont une base solide et efficace pour les tests fonctionnels mais ceux-ci sont réalisés plus tard et ailleurs.
- Une « User story » doit être implémentée et testée en une itération. Un « Use case » peut être traité sur plusieurs itérations (scénario nominal sur une, scénarios alternatifs sur une autre) en fonction des risques à lever.
- « Use cases » ou « User stories » : le choix va impacter le mode d’estimation et de planification du projet (« Technique des points de cas d’utilisation » / « Points d’histoire d’utilisateur et vélocité d’une itération »).
- Les relations entre « User stories » ne sont pas toujours évidentes; le problème est moindre pour les « Use cases » grâce notamment au diagramme de cas d’utilisation (qui accompagne les « Use cases »), et aux notions de package, inclusion, extension.
- Enfin, les « User stories » sont issues de l’univers « Extreme programming » alors que les « Use Cases » sont intimement liés au « Processus Unifié« . L’usage de telle ou telle technique sera donc aussi fonction de la méthode de développement utilisée: UP, RUP, XP, SCRUM…