User Stories

Lors des derniers projets auxquels j'ai participé ou que j'ai coachés, les exigences ont été définies par des "user stories".

J'ai depuis longtemps utilisé, et intensivement, les cas d'utilisation. J'ai pratiqué et recommandé le développement par itérations guidé par les cas d'utilisation(use case driven). Je trouve toujours que c'est une technique intéressante pour spécifier (bien qu'elle soit souvent mal utilisée).
Cependant elle ne permet pas, à elle seule, de bien gérer le contenu des itérations. En effet, un bon cas d'utilisation contient plusieurs "scénarios". Généralement on commence par décrire le scénario de succès le plus usuel, puis on identifie les scénarios alternatifs.

Lorsqu'il s'agit de planifier une itération, la pratique habituelle des projets que j'ai suivis depuis des années est de sélectionner un ou plusieurs cas d'utilisation. La réalité est que, dans la grande majorité des cas, les équipes n'ont pas réalisé tout le cas d'utilisation à la fin de l'itération, mais seulement un scénario, dans le meilleur des cas. Sans avoir déroulé des tests fonctionnels sur ce scénario. Il devient alors difficile de connaitre l'avancement avec des exigences partiellement réalisées.

Une User Story (non, je ne suis pas -encore- prêt à dire des histoires des utilisateurs, mais je suis ouvert à des propositions pour défendre le français) est de taille plus réduite qu'un cas d'utilisation. Je ne vais pas présenter ici cette technique issue de XP, mais seulement montrer comment elle permet de mieux maitriser l'avancement dans un projet.

Une story est une exigence (plus exactement, avec Scrum, une story est un item du Backlog de produit). La règle simple est qu'une exigence doit être réalisée (et testée, c'est fondamental) dans une seule itération. A la fin de l'itération, l'équipe fait une démo de ce qu'elle a vraiment réalisé. On peut ainsi connaitre les exigences (user stories) qui sont finies. Cela, couplé à l'estimation agile que j'aborderai dans un prochain billet, permet d'avoir une bonne idée de l'avancement du projet.
Et ça marche.

Commentaires

1. Le mardi 18 avril 2006, 19:28 par UmlGuru

J'ai un peu l'impression quand même qu'on en revient là aux exigences textuelles élémentaires avec l'inconvénient qu'elles sont tellement "petites" qu'on ne peut pas les tester individuellement.
Pour moi, le gros avantage du concept de cas d'utilisation, c'est justement le fait qu'il raconte une histoire, du début à la fin, et est donc testable ! Je suis d'accord que c'est la notion de scénario qui est plus appropriée pour la planification du contenu technique des itérations, mais revenir aux vieux Requirements comme le montre Ambler me paraît bien dangereux ...

Pascal


Claude : Non, il n'y a pas ce risque, une des caractéristiques primordiales d'une User story est d'être testable (les autres sont Indépendent, Valuable, Estimable, Small, ce qui fait le slogan INVEST). D'ailleurs on la teste lors de l'itération où on la réalise. Et donc on y spécifie aussi ses tests de recette (acceptance test). Elle n'existe que si elle apporte de la valeur à un utilisateur. Comme son nom le laisse deviner elle raconte aussi une histoire.
Quant à la différence/similitude avec les cas d'utilisation, je la développerai dans un prochain billet. Chez un des mes clients, on a fait d'abord des cas d'utilisation puis on est passé (facilement) aux User stories (pour la planification des itérations).