Use cases, User stories ?

MàJ: Le comparatif sous forme de tableau synthétique dans ce billet Use Case vs User Story

user stories vs use cases Ou plutôt Cas d’utilisation (pratique Processus Unifié, UP), Récits d’utilisateur (pratique Extreme Programming, XP) ?… la question se pose car il s’agit de deux modes de représentation des exigences (fonctionnelles) utilisées dans le cadre des Méthodes Agiles.

J’ai toujours utilisé (moi même rédiger, former, et exploiter) les Cas d’utilisation (MàJ du 08/11/2007: des conseils de rédaction, un modèle et le lien avec UML dans ce billet Cas d’utilisation UML … oui mais… ).

Bien rédigés, ils complètent idéalement le travail que je peux produire pour les utilisateurs, concepteurs et développeurs sur un projet. Mais je réfléchis, comme pour SCRUM (cf. « UP et une dose de SCRUM ») à ce que je pourrais tirer des « User Stories« .
Soyons clairs, les « Use Cases » me semblent plus adaptés à la plupart des projets sur lesquels j’interviens (projets et problématiques métiers importants, taille de l’équipe moyenne, nécessité de formalisation, équipe sur deux sites et Offshore envisagé) mais pour certains projets (délais courts, « métier connu« , équipe réduite, client disponible), les « User stories », plus concis, allant à l’essentiel et plus rapidement écrits pourraient s’avérer plus appropriés; j’ai déjà quelques idées…

Une « User story » est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur.

Exemples de « User stories »: « En tant qu’utilisateur, je peux réserver des chambres d’hôtel », « En tant que recruteur, je peux déposer des offres d’emploi ».
Ron Jeffries utilise les 3 C pour la décrire:

• Card (l’histoire est courte et écrite sur une carte 8×13 cm)
• Conversation (les détails de l’histoire sont discutés)
• Confirmation (l’histoire est confirmée par des tests d’acceptation rédigés au même moment que celle-ci, au dos de la carte).

Un « Use case » modélise un sevice rendu par le système. Il représente un ensemble de séquences d’actions qu’un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système.

Exemples d’intitulés de « Use cases »: « S’authentifier », « Rechercher un livre ». Ces titres ne sont qu’une partie du « Use Case » qui comporte d’autres parties (Acteur, Résumé, Déclencheur, Scénario principal, Extensions…). Un « Use Case » est donc plus détaillé, et nécessite un travail approfondi d’analyse et de formalisation.

Alors pourquoi cette réflexion ? d’une part, comme je le disais, j’ai le sentiment que certains contextes se prêtent mieux aux « User Stories« , d’autre part « User stories » et « Use cases » se rejoignent sur beaucoup de points (pour les différences, consulter ce billet):

• « User Stories » et « Use Cases » formalisent les besoins utilisateurs et sont orientés « But »
• Ils font facilement l’objet d’ateliers de travail avec les utilisateurs pour les découvrir, les expliciter
• Ils vont être priorisés et vont ainsi guider les développements
• Ils mettent en avant les rôles, les différents profils d’utilisateurs
• Ils ne traitent que des exigences fonctionnelles (les aspects « non fonctionnels » sont décrits dans « les exigences non fonctionnelles » (contexte UP) et dans les « Constraints Cards » (contexte XP))
• Ils sont textuels et obéissent à des régles de construction trés précises (Travaux de Rachel Davis, ou critères « INVEST » pour les « User Stories »)
• Ils ne traitent pas des aspects interface et ergonomie (détails abordés dans les exigences d’ergonomie (contexte UP), livrables d’ergonomie, prototypes (contextes UP et XP))
• Ils peuvent être rédigés par les analystes (pour les UC c’est conseillé; pour les « User Stories« , c’est plutôt l’utilisateur ou un membre de l’équipe Client, composée de ceux qui vont s’assurer que le produit répond aux besoins des utilisateurs, c’est à dire Utilisateurs eux-mêmes, Directeur de produit, Analyste ou encore Ergonome)
• Ils ont chacun leur auteur et ouvrage de référence (Alistair Cockburn, « Rédiger des cas d’utilisation efficaces« , Mike Cohn, « User Stories Applied For Agile Software Development« ).

Dans un prochain billet, j’aborderai les différences majeures entre « Use Cases » (Cas d’utilisation) et « User Stories », ce qui me permettra de détailler davantage leur mode de construction et d’envisager l’impact de telle ou telle technique notamment en terme de Qualité Logiciel.