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

Use Cases versus User Stories (2 sur 2)

La semaine dernière, Henri Darmet nous rappelait ce qu’étaient un Use Case et une User Story (et aussi ce qu’ils n’étaient pas). Il nous propose maintenant de voir ce qui lie ces deux notions… Hé bien, pas grand chose. L’une est « l’anglais » du besoin utilisateur, l’autre le « chinois ». On peut traduire de l’anglais en chinois (et vice versa), mais pas plus.

OK, mais que faut-il mieux faire, des Uses Cases ou des User Stories ? Eh bien là aussi, la comparaison avec l’anglais et le chinois est pertinente : vaut-il mieux parler anglais ou chinois ? Ça dépend… généralement, c’est l’anglais, mais en Chine, le chinois est plus efficace et plus convivial.

Essayons quand même de voir ce qui rassemble les Use Cases et les User Stories, ce qui les sépare, et les contextes dans lesquels ces  approches sont les plus adaptées.

 

Ce qui rassemble Use Cases et User Stories

 

N’oublions pas l’essentiel, le besoin utilisateur !

Ce qui les rassemble est une notion qui ne doit jamais, jamais, jamais être perdue de vue : Use Cases et User Stories représentent un besoin dans l’optique de l’utilisateur.

  • Un Use Case N’EST PAS une fonctionnalité du système !
  • Une User Story N’EST PAS une tâche qui peut être entièrement exécutée lors d’un sprint, comme on l’entend trop souvent !

Use Cases et User Stories ont été définis pour rendre le pouvoir aux utilisateurs ! La tentative de rapt des équipes projet pour se réapproprier ces outils à leurs propres fins est une hérésie qui doit être combattue avec la dernière énergie (l’usage du bûcher semble néanmoins « too much », quoique… pour l’exemple, de temps en temps).

Est-ce que je peux les conjuguer ?

D’aucuns ont fait remarquer que les granularités pouvaient être rapprochées comme suit :

  • Le Use Case et l’EPIC (la « macro User Story ») représentent, peu ou prou, la même chose.
  • Le scénario du Use Case et la User Story représentent, peu ou prou, la même chose.

J’adhère à cette analyse. Il est donc possible, comme certains le suggèrent, de rédiger des scénarii en prenant le template des User Stories. Pourquoi pas ? Mais cela n’en fait pas, pour autant, des User Stories ! Je rappelle qu’une User Story est une User Story, c’est à dire une « story » du « user », pas une « story » de l’AMOA ou du Scrum Master…

Et vu de l’équipe de développement ?

Là où la similitude prend tout son intérêt c’est lors de la soumission de l’artefact à une équipe de développement : la logique de prise en compte d’une User Story ou d’un scénario de Use Case est strictement identique : découpage en tâches, estimation, négociation…

Et pour la spécification des tests ?

Les deux formalismes spécifient le test. Dans la User Story, le test d’acceptance est donné explicitement. Dans un scenario de Use Case, le scenario EST le test.

Donc – et c’est très important – les deux démarches sont « SCRUM compliant ».

 

Ce qui sépare Use Cases et User Stories

 

En terme d’artefacts ?

  • Les Uses Cases fournissent un cadre cohérent de spécifications dont on peut ensuite vérifier la complétude et l’homogénéité. Le résultat peut (et doit) être maintenu. Ce n’est pas le cas des User Stories.
  • La démarche Use Cases aboutit assez naturellement à une spécification fonctionnelle de qualité pour peu qu’elle soit suivie avec sérieux. Dans cette spécification, les contradictions sont résolues et les redondances, comme les impasses, sont rares, voire inexistantes. Dans la démarche User Stories, la spécification doit être déduite de l’observation de l’application et en s’appuyant sur les User Stories en suivant l’ordre chronologique inverse. Pas simple… donc si l’on désire avoir une spécification formelle avec les User Stories, ce sera une activité supplémentaire.
  • Les Use Cases ne s’intéressent qu’à la valeur apportée à l’utilisateur. Ceci ne suffit pas pour faire une spécification complète : il faut l’enrichir de spécifications non fonctionnelles qui s’expriment mal sous forme de scenarii (exemple : spécification de temps de réponse). Le format de la User Story, plus libre, s’adapte bien à toutes les situations. Ceci étant, c’est un souci mineur car il est facile de décider d’une formalisation pour les exigences non fonctionnelles des Use Cases. On peut prendre, par exemple…  celui des User Stories (qu’on aura le bon goût d’appeler « Technical Stories » puisqu’elles n’ont pas été racontées par un User).

Et en terme de coûts ?

  • L’approche Uses Cases est plus lourde à manier que l’approche User Stories (mais elle ne fournit pas les mêmes artefacts, comme expliqué ci-dessus).
  • Ceci étant, dans la démarche Use Cases, il est possible de s’épargner des développements en illustrant les scenarii sous forme de Story Board permettant d’avoir un feedback plus rapide et moins onéreux (qu’un véritable développement). La démarche « Use Case » n’est donc pas forcément la plus coûteuse…

Et en terme d’organisation ?

  • Pour rédiger les Use Cases, l’AMOA a besoin que l’utilisateur lui soumette un BESOIN alors que dans la User Story, l’utilisateur spécifie une SOLUTION. La différence entre les deux porte un nom : l’ergonomie. Conséquence : dans le Use Case, l’ergonomie est entre les mains de l’équipe de réalisation (au sens large, c’est-à-dire incluant l’AMOA), dans la démarche User Story elle est à la charge de l’utilisateur.
  • La démarche Use Cases nécessite de mobiliser un véritable dispositif AMOA alors que dans la démarche User Stories, ce dispositif peut être très léger (c’est suffisamment simple pour qu’un utilisateur final puisse se l’approprier). Il ne faut pas considérer que l’aspect coût, il y a aussi un aspect complexité : dans la démarche Use Cases, on crée un maillon supplémentaire, donc, forcément un point de fragilité. Le rôle de l’AMOA est alors critique. Si on est mal organisé ou si l’AMOA ne dispose pas de la compétence et de l’énergie nécessaires, on peut mettre en danger le projet.

 

 Conclusion : Use Cases ou User Stories ?

 

En première conclusion, je dirais que la démarche Use Cases est la plus adaptée aux grands projets, ceux qui se comptent en milliers de jours hommes. La démarche User Stories est davantage adaptée aux projets de taille plus réduite, ceux qui se comptent en centaines de jours. On arguera que de grands projets ont pu être menés avec des User Stories (des vraies…) et que des projets plus petits surent profiter de la démarche Use Cases. Certes. On peut abattre un arbre avec une hache et on peut fendre un rondin à la tronçonneuse. Est-ce que cela valide pour autant l’usage qui est fait de ces outils ?

En seconde et importante conclusion, vous pouvez constater que dans cet article, il n’a jamais été question de forme (comment, en UML, je représente un Use Case ou un scenario, comment j’utilise le pattern de phrase : « En tant que… Afin de… Je veux… » pour la User Story), c’est secondaire. Ce n’est pas cela qui fait que vous allez entrer dans l’une ou l’autre des démarches. Déguiser l’un en l’autre, c’est tromper et – plus grave – se tromper soi-même. Une fois de plus, je me permets d’insister sur le concept de stratégie qui supplante l’outil : quel est le dispositif de votre projet ? Quelle est la maturité de vos utilisateurs ? Quelle est la taille de votre application ? Avez-vous une équipe AMOA solide ? Voilà les vraies questions dont les réponses vont conditionner votre choix. Le reste n’est que détails.

Donc si je résume : la technique des Use Cases vous permet de développer dans une démarche agile, ces fameux « projets d’entreprise » où votre boss vous explique que c’est quand même un peu trop gros pour vos User Stories au ras des pâquerettes et que donc, on va les traiter de manière traditionnelle avec le fameux cahier des charges, suivi par le document d’architecture fonctionnelle, le document d’architecture technique, les spécifications en bonne et due forme, le document de conception, le planning, le cycle en V, le dépassement de 100% en fin de projet, la bataille de Verdun avec les équipes métier et votre augmentation accordée du bout des lèvres car vraiment, tout ça a beaucoup dérapé…

  1. jamel
    16/02/2014 à 22:05 | #1

    Super la conclusion 😉

  1. 14/02/2014 à 15:22 | #1


+ huit = 13