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[1].

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

  1. le premier jour du sprint, l'équipe se réunit pour le sprint planning
  2. le but du sprint est défini à l'initiative du Product Owner
  3. le Product Owner présente les stories prévues pour ce sprint
  4. pour chaque story, l'équipe identifie les tâches nécessaires
  5. l'équipe estime les tâches en heures
  6. chaque membre de l'équipe prend des tâches
  7. l'équipe s'engage sur le périmètre du sprint
  8. 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.

Notes

[1] 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.

Commentaires

1. Le mardi 05 mai 2009, 10:48 par Pascal Roques

Oui, j'aime bien cette idée que les cas d'utilisation donnent un contexte aux User Stories ! Ça me rappelle le titre d'un des bouquins de référence sur le sujet : Use cases - Requirements in context, Kulak , Guiney, Addison Wesley, 2003.

Étant lui-même un agiliste convaincu et actif, il est intéressant de noter qu’Alistair Cockburn continue de penser que les cas d’utilisation ont de la valeur, et il explique même sur son blog pourquoi il continue à utiliser les use cases !

2. Le mardi 05 mai 2009, 11:35 par jc-qualitystreet

Pour ce qui est du contexte entre les user stories, les livrables "Experience Utilisateur" ou ergonomie permettent de combler le manque:
- Personas
- Cinématique (storyboard)
- Wireframe
D'où l'interêt d'inclure un travail ergonomique dés le Sprint 0

Pour ce qui est des différences use cases / user stories, j'ai fait un petit tableau récap. :
http://www.qualitystreet.fr/2009/02...

A ce propos, si l'ergonomie et l'experience Utilisateur dans un contexte Agile vous interessent, je presente une session le 25 mai aux prochains XP Days
http://xpday.fr/programme

J'y parlerai Ergonomie, avec un fort focus sur les Personas (un sujet qui me tient à coeur), Tests Utilisateurs, Prototypage rapide, collaboration avec le Product Owner et l'équipe...

3. Le mardi 05 mai 2009, 18:43 par Thierry

Aaaarrrggggh il me reste donc encore quelques séquelles de mes années UML :-)

je rejoins la note de Pascal, avec quand même un bémol qui est "à utiliser avec modération". Le contexte effectivement est bien "embrassé" par les acteurs et les cas principaux.
diagramme de contexte

  • - id : guest
  • - passwd : model4mind

Pour ce qui est de la décomposition en interactions, qui est la base des cas d'utilisation, je suis sceptique pour une approche agile (j'ai pratiqué et franchement c'est carrément trop lourd !). sans parler de ces fameuses relations entre cas : include, extend (j'ose même plus citer l'héritage).

Pour une approche disons simili-agile (Client pas sur site tous les jours) pourquoi pas, ce peut être un bon compromis.

Un point important à mon sens est, en particulier dans une phase exploratoire (pseudo-sprint 0) de mener plusieurs modélisations ou études en //.

  1. - expr de besoins par les UC
  2. - analyse.conception : soit CRC cards, soit diag comm + classes UML, soit plutot des premiers protos.spikes.

autrement dit, mener seul un modèle expr besoins UC trop longtemps (plus de quelques jours) ne me parait pas pertinent en agilité (manque de feedback rapide).

4. Le mardi 05 mai 2009, 18:47 par Thierry

Pour ce qui est de l'enchainement, à utiliser uml, autant utliser aussi des diags dynamiques (use case = structurel) en particulier diag d'activités de tel ou tel acteur