Use-case et user story
Un use-case, des user stories ?
L’autre jour à Marseille dans sa présentation, pour parler des user stories, Thierry a dit des histoires d’utilisation. Tiens, un mélange entre cas d’utilisation et histoires d’utilisateur !
J’avais fait un billet sur les différences entre les deux il y a déjà 2 ans. Depuis, j’ai beaucoup pratiqué les histoires (d’utilisateur), et plus du tout les cas (d’utilisation). Je n’ai vu aucune des équipes que j’ai suivies en faire. Le seul endroit où j’ai vu des cas d’utilisation, c’est dans le guide méthode d’une administration : la pratique y était présentée comme obligatoire sur les projets et expliquée avec des exemples.
En fait quand j’étais consultant en cas d’utilisation (dans les années 90), je constatais une pratique très variée des cas d’utilisation. Certains correspondaient d’ailleurs à ce qu’on appelle story maintenant, quelques uns avaient du sens (essential) et la plupart c’était de l’IHM.
Si je trouve que la pratique des user stories apporte généralement plus de valeur, il y manque la notion de contexte. Quand on manipule des dizaines de stories, il est difficile de savoir dans quel système plus large se situe une story particulière.
Avec une approche agile du produit, la vision et l’identification des features fournissent une partie de ce contexte. Une user story est le résultat de la décomposition d’une feature.
On retrouve d’ailleurs avec les features et stories une pratique de décomposition absente des use-cases, qui se présentent à plat, les clauses include et extend permettant les relations entre des use-cases étant de nature différente.
Mais ce qu’il manque toujours, à mon avis, c’est le contexte temporel. Il serait intéressant de connaitre les enchaînements possibles lors de l’exécution des stories. Quelque chose qu’apporte le cas d’utilisation en montrant les différents scénarios qui le composent.
Tiens je vais essayer de faire un cas d’utilisation englobant la story sur laquelle je travaille actuellement dans le cadre d’un outil Scrum.
User Story : activer un sprint.
En tant que ScrumMaster, Je peux activer un sprint Afin d’entériner l’engagement de l’équipe sur le périmètre du sprint
Un cas d’utilisation permettant de situer le contexte pourrait être : Planifier un sprint
- Acteur initiateur : l’équipe Scrum
- But du cas : Planifier un sprint en équipe
- Pré condition : il existe une équipe Scrum qui travaille sur un produit, le backlog de produit contient des stories estimées
- Post condition en cas de succès : l’équipe s’engage sur le périmètre du sprint
Scénario principal
- le premier jour du sprint, l’équipe se réunit pour le sprint planning
- le but du sprint est défini à l’initiative du Product Owner
- le Product Owner présente les stories prévues pour ce sprint
- pour chaque story, l’équipe identifie les tâches nécessaires
- l’équipe estime les tâches en heures
- chaque membre de l’équipe prend des tâches
- l’équipe s’engage sur le périmètre du sprint
- le ScrumMaster active le sprint et clôt la réunion
Alternatives (par exemple)
- A l’étape 2, le ScrumMaster crée le sprint, si cela n’a pas été fait avant (extension)
- A l’étape 4, l’équipe ajoute des tests d’acceptation à la story lors du travail sur les tâches (extension)
- A l’étape 7, l’équipe refuse de s’engager. Retour à l’étape 3
Ce cas d’utilisation Planifier un sprint, qu’on pourrait appeler aussi processus métier, référence plusieurs stories : créer un sprint, définir le but, identifier les tâches, estimer les tâches, activer le sprint…
Il me semble que de voir l’enchaînement des stories élémentaires peut apporter une meilleure compréhension à quelqu’un qui travaille sur une story. Une autre façon de montrer cet aspect temporel est de le faire avec les tests d’acceptation mais c’est une autre histoire.