User stories et use-cases

Histoires d'utilisateur et cas d'utilisation, ce n'est pas la même chose.

jc de QualityStreet présente les différences entre les cas d'utilisation et les histoires d'utilisateur. Son étude présente bien ce que sont ces 2 techniques, mais sa comparaison s'inscrit dans le cadre de techniques de spécifications des exigences fonctionnelles. Or les histoires d'utilisateur ne sont pas vraiment une technique de spécification.

Les différences exposées dans son billet entre ces 2 techniques sont donc à replacer à l'aune de cette distinction.

En effet les histoires d'utilisateur, qui viennent de XP[1], reposent sur l'idée qu'il n'est pas efficace de rédiger des spécifications détaillées, mais qu'il est préférable :

  • de dialoguer pour arriver au détail
  • de rédiger (ou d'écrire) des tests fonctionnels et de les passer pour valider l'histoire. Ces tests remplacent la spécification détaillée.

La définition d'une histoire d'utilisateur : Un petit morceau fonctionnel qui a de la valeur pour le “métier” et qui peut être fourni en une itération montre aussi leur autre facette, que n'ont pas les cas d'utilisation : la gestion de projet par l'intermédiaire du backlog de produit. C'est pourquoi la question du choix entre cas d'utilisation et histoires d'utilisateur ne pose pas dans un développement agile : un cas d'utilisation ne remplit pas[2] les conditions pour devenir un élément du backlog sélectionné pour une itération.

Attention, je ne dis pas qu'il ne faut pas utiliser les cas d'utilisation. Si, sur les derniers projets pour lesquels j'étais directeur de projet je n'en ai pas eu besoin, un de mes clients utilise, sur mes conseils, ces 2 techniques :

  • d'abord les cas d'utilisation dans l'esprit des Essentials Use-cases de Constantine et Lockwood. Il est nécessaire d'avoir un document écrit dans ce contexte.
  • ensuite les histoires d'utilisateur. A chaque couple user intention et system responsability correspond, au départ, une histoire d'utilisateur.

Notes

[1] et popularisées ensuite par Mike Cohn

[2] sauf circonvolutions

Commentaires

1. Le mardi 10 avril 2007, 10:17 par jc

Je donne effectivement une orientation "exigence fonctionnelle" à mon billet, sans doute parce que les "use cases" ne me servent qu'à appréhender ce type d'exigences, et que c'est dans ce cadre là que j'envisage d'utiliser les "user stories" sur certains projets particuliers (les exigences non fonctionnelles, je les traite à part).

Claude : Mon point portait sur le mot spécification uniquement : au sens écrire une spec détaillée, les histoires d'utilisateur ne sont pas une technique de spécification. Sinon les histoires d'utilisateur comme les cas d'utilisation ne s'intéressent qu'à l'aspect fonctionnel des exigences.


Concernant l'aspect "discussion", je partage totalement votre avis: les stories sont négociées, discutées (pour les explorer en détails et lever les ambiguités) et tout n'est pas écrit : c'est pour moi une différence majeure avec les "uses cases"; je le garde à l'esprit et le considère même comme un atout pour certains contextes.
D'ailleurs ce besoin de formalisme est un élement déterminant pour le choix de telle ou telle technique, au même titre que la taille du projet, des équipes, de leur proximité, ou encore de la présence d'un client ou de la connaissance du metier de l'application.