Accueil > Méthodes Agiles, UML / Enterprise Architect > Use Cases versus User Stories (1 sur 2)

Use Cases versus User Stories (1 sur 2)

Que de choses ont été dites, pour les définir, les comparer, les opposer, les réunifier ! Alors, afin d’entretenir la confusion ambiante, Henri Darmet y va de son petit avis.

Commençons d’abord par examiner les deux bestioles.

 

Les Use Cases

 

D’abord un peu d’histoire : les Use Cases ont été définis par un des pères d’UP (Unified Process), donc d’UML (Unified Modeling Language) : monsieur Ivar Jacobson. Il l’a fait de manière formelle et précise :

« Un Use Case est une activité ou une série d’activités, initiées par un acteur, et qui apportent une valeur du point de vue de l’acteur. »

Première remarque : un Use Case n’est donc pas une « chose » que je détourne à ma guise et que je vais représenter par une « patate » liée à un bonhomme « fil de fer ». Pour prendre un exemple, « se connecter au système » ne peut pas être un Use Case, car il n’apporte pas de valeur du point de vue de l’acteur (vous arrive-t-il de vous connecter au système et de vous dire juste après : « Ah ! super ! Ma tâche est terminée ! »). 95% des Uses Cases que j’ai rencontrés dans les projets sur lesquels je suis intervenu… n’en étaient pas. Le Use Case est une notion aussi connue que mal comprise.

Le Use Case s’utilise au sein d’un processus bien défini de captation et de formalisation des besoins. Ce processus, lorsqu’il fonctionne s’organise autour :

  • d’une définition formelle du processus justement (qui fait quoi, comment)
  • d’une démarche de captation des besoins par un professionnel MOA
  • d’une activité de gestion et synthèse des besoins captés
  • d’une activité de formalisation de la réponse à ces besoins (dont le point d’entrée est justement le Use Case)
  • d’une démarche de restitution du besoin à l’utilisateur (le fameux feedback, à partir de Story Boards par exemple)
  • d’une démarche de soumission de ces Use Cases aux équipes de développement

Exemple :

Description / cycles avec uses casesPaul est un MOA chevronné qui utilise les Use Cases. Il a rassemblé les docs, les mails, les interviews, les screenshots de l’application à remplacer dans un répertoire projet. Tous ces éléments sont référencés (par morceau, généralement) dans un fichier Excel appelé « besoin de l’application APP.xls ».

A partir de ce fichier, Paul a construit douze Use Cases et a vérifié que toutes les lignes de son fichier Excel sont bien traitées par un User Case (principe de complétude). Chaque Use Case est décliné en scénarii où figurent les différents acteurs qui interagissent, l’un d’entre eux étant le « système », c’est-à-dire l’application APP.

Les Use Cases sont à des stades différents de formalisation : pour certains, la liste des scénarii est établie, mais non développée, pour d’autres, une partie seulement des scenarii ont été rédigés, et enfin, pour les Use Cases les plus critiques, tous les scenarii ont été rédigés.

Paul utilise UML pour décrire les Use Cases.

Un scenario est illustré systématiquement par un Story Board, ce qui permet à Paul de présenter à Marie, la responsable de l’équipe métier, de façon très visuelle, ce à quoi va ressembler APP dans sa dynamicité. Elle peut alors valider avec Paul les scenarii qui seront soumis à l’équipe de développement pour le prochain Sprint.

Lorsque Marie veut faire évoluer son besoin, Paul réceptionne les documents qui l’expriment, ajoute les lignes nécessaires dans le fichier Excel de gestion des besoins, étudie l’impact sur la cartographie fonctionnelle (c’est-à-dire qu’il détermine le ou les Use Cases impliqués) et construit ou amende les scenarii afférents. Il reporte ses mises à jour sur les Story Boards qui sont présentés à Marie pour feedback.

A tout moment, l’ensemble des Use Cases et de leurs scenarii forment un ensemble cohérent (pas de contradiction) et homogène (tout est défini avec le même niveau de précision) dont on peut mesurer la complétude (y a-t-il encore des scenarii non rédigés ?).

Bref, lorsque le projet se termine, on peut prendre les documents de Paul et les classer comme spécifications fonctionnelles de APP.

Quels sont les inconvénients d’une telle démarche ? En bref : « Il faut Paul ». Marie ne peut pas se débrouiller toute seule. Entre le besoin qu’elle exprime avec ses mots à elle et le retour qu’elle perçoit et comprend de la restitution de Paul, il y a… tout le travail de Paul. Paul est l’homme clé de la démarche, et le Use Case, le squelette de sa démarche de formalisation. Le Use Case n’est utilisable tel quel ni par Marie (qui a besoin des Story Boards), ni par l’équipe de développement (qui utilise, elle, la formalisation des scenarii qui lui sont présentés).

Houlà, c’est compliqué ! Eh bien pas tant que ça ! En fait, cela demande surtout de la rigueur et de l’expérience. Ce qu’il faut, c’est :

  • éviter absolument le mode « arrache »
  • maintenir avec rigueur les Use Cases existants en fonction des besoins exprimés
  • bien tenir à jour la cohérence « gestion des besoins » (la feuille Excel) et les Use Cases
  • ne pas impliquer les utilisateurs dans les travaux de formalisation (ils n’y comprennent rien et ça ne les intéresse pas)
  • faire un feedback sous une forme compréhensible par les utilisateurs (c’est l’intérêt des Story Boards par exemple)

Alors, est-il pertinent d’utiliser les Use Cases ? En fait (j’anticipe sur la conclusion de l’article), plus l’application est importante, plus la cartographie des besoins est maîtrisée (on a la « big picture »), plus la technique des Uses Cases est pertinente. C’est la solution pour les « grands logiciels », ceux qui peuvent investir dans une ambitieuse démarche de spécifications afin d’éviter des développements incohérents ou inutiles.

 

Les User Stories

 

La User Story nous vient d’XP (eXtreme Programming) et non de SCRUM comme beaucoup le croient. Sa définition initiale était très simple : un besoin exprimé sur le recto d’une feuille de bristol B5, le verso étant utilisé pour préciser les conditions de recette de la dite User Story.

Changement radical de contexte. Une User Story est un « bon de travail » émis par le client (le Product Owner ou son représentant) vers l’équipe de développement, à l’instar d’un bon de travail émis par l’architecte (« fais-moi ce mur comme ça ») envers le maçon.

Les User Stories, comme leur nom l’indique, sont des « histoires de l’utilisateur », c’est-à-dire des histoires racontées par l’utilisateur. Un utilisateur n’étant généralement pas un professionnel de la formalisation (sinon, quelle serait la compétence spécifique de nos AMOA ?), il y a peu de chances que l’ensemble des histoires forme un ensemble totalement cohérent. Les User Stories peuvent se recouper, se contredire, laisser des trous, etc.

Est-ce grave ? Oui et non. Oui si on n’est pas capable de retrouver par ailleurs cette cohérence, non si on applique une méthode qui justement permet de palier au problème.

Description / cycles avec les User StoriesQuelle est cette méthode ? Elle consiste à utiliser le feedback, c’est-à-dire l’application elle-même. La méthode ne fonctionne, donc, que si User Stories et démos sont intrinsèquement liées : moi client, je te demande quelque chose, à toi développeur. Tu le réalises et tu me le montres. Je vois ce que tu as fait, cela modifie ma perception et donc fait progresser ma réflexion. Suit une autre demande, en partie corrective, que tu réalises et que tu me montres, etc. C’est l’application en construction qui soutient la cohérence, pas la User Story. Cela signifie :

  • que les User Stories ne se comprennent que dans un contexte donné (en considérant, par exemple, l’application telle qu’elle était au 20 novembre 2013)
  • que les User Stories peuvent sciemment se contredire (je te demande, par exemple, dans la US 103 de disposer le formulaire comme ceci et dans la US 117 de la disposer comme cela)
  • que certains points ne figureront jamais dans une User Story, car omis dans la User Story dans laquelle ils auraient dû être précisés, ils ont été décidés en live, au cours du Sprint, lorsque le développeur s’est rendu compte du trou

Comme on peut le deviner, les User Stories ont l’avantage de la simplicité et de faciliter la mise en œuvre (ce qui est considérable et dans bien des environnements, déterminant) et l’inconvénient de ne pas aboutir « naturellement » à une spécification vérifiable.

Alors, que choisir ? C’est ce qu’on verra dans le prochain article


cinq + 8 =