Use Cases vs User Stories : y a-t-il une différence ?

En ce qui concerne les cas d’utilisation par rapport aux histoires d’utilisateurs, on m’a souvent demandé : « Sont-ils la même chose ? » Réponse courte : non. Le débat entre les cas d’utilisation et les histoires d’utilisateurs peut prêter à confusion, mais il existe des différences évidentes. Une façon d’y penser est de considérer le premier mot de chaque nom.

Bien Histoires d’utilisateurs exprimer une caractéristique souhaitable d’une solution numérique du point de vue d’un utilisateur (par exemple, un système humain ou automatisé interagissant avec une solution numérique existante ou proposée) et répond « Qu’est-ce que cela m’apporte ? »

UN utiliser Le cas capture une série d’interactions entre un « acteur » (par exemple, un système humain ou automatisé) et une solution numérique pour atteindre un objectif spécifié. Les développeurs peuvent utiliser un cas d’utilisation pour débusquer les détails de la façon dont un utilisateur pourrait utiliser la solution pour profiter d’une fonctionnalité demandée. Il peut également servir à fournir un contexte pour un ensemble de user stories.

Diagramme et affichez-le sur le mur

Pour illustrer mon propos, une user story serait ce dont vous avez besoin : « En tant que mère, j’ai besoin de conseils sur la façon d’enseigner le pardon à mon enfant. » Un cas d’utilisation montrerait COMMENT vous pouvez y parvenir. Par exemple, des instructions étape par étape sur la parentalité de votre enfant.

Un (très bref) historique de ces concepts complémentaires

Malheureusement, la réponse longue n’est pas vraiment aussi simple que cela. (Est-ce déjà le cas ?) Pour les passionnés d’histoire, Ivar Jacobson a introduit des cas d’utilisation dans le vocabulaire informatique en 1987, et il est devenu extrêmement populaire pour définir comment un utilisateur interagit avec une solution. Les user stories ne sont apparues dans leur contexte actuel qu’en 1998, quand Alistair Cockburn a déclaré : « Une user story est une promesse de conversation.

Du point de vue de la popularité, les histoires d’utilisateurs ont augmenté à mesure que le développement de logiciels Agile se répandait. Pendant ce temps, beaucoup (y compris l’auteur) considèrent la structure de la user story comme le meilleur modèle pour exprimer ce que les individus ou les groupes partageant un rôle ont besoin que la solution numérique fournisse.

Le paradigme de la user story exposé

User story illustrée

Ce qui est devenu plus ou moins institutionnalisé, c’est que les user stories (déclencheurs d’une conversation) répondent à la question « QUI a besoin de QUOI et POURQUOI ? Par exemple:

En tant que médecin (OMS),

Je peux obtenir une compilation des symptômes (QUOI)

de prescrire le bon médicament au patient (POURQUOI).

Il n’y a pas de COMMENT dans une user story

La prémisse est que la mise en œuvre de la story est le domaine du développeur, pas des utilisateurs, ce qui signifie que c’est le travail du développeur de comprendre comment fournir la fonctionnalité souhaitée pour permettre à la user story de fonctionner comme l’utilisateur le souhaite.

Un cycle de vie (très bref) de la user story

Les organisations qui adoptent le paradigme des user stories commencent souvent par définir des « épopées », qui décrivent les résultats commerciaux souhaités d’un projet logiciel à un niveau élevé. Une fois qu’une épopée est planifiée pour fonctionner dans un sprint (période de 2 à 4 semaines), elle est décomposée en un ensemble de récits d’utilisateurs qui sont au niveau de détail approprié pour l’équipe technique Agile.

Le degré de détail des user stories dépend entièrement de la sophistication et de l’expérience des développeurs. Il n’y a pas de norme universelle concernant un peu ou beaucoup de détails. La règle générale est qu’un développeur doit terminer une user story en quelques jours de travail.

Chaque user story individuelle est ensuite évaluée pour être incluse dans un sprint ou une itération à venir et, si elle est sélectionnée, sert de déclencheur pour une discussion entre le développeur chargé de livrer la story et l’auteur de la story (par défaut, le propriétaire du produit). Au cours de la discussion, des scénarios de test et des exemples de résultats attendus sont convenus.

Les meilleurs cours en Analyse d’entreprise

Les critères d’acceptation permettent à la communauté des affaires de définir les résultats attendus

Pour faire leur travail, les développeurs ont besoin de plus de détails à un moment donné. Pour cette raison, une user story entièrement étoffée fournit également des conditions de satisfaction (également appelées « critères d’acceptation ») qui spécifient comment la communauté commerciale reconnaîtra que la user story a été correctement mise en œuvre. Ces critères sont généralement développés par la communauté des utilisateurs avec l’aide du Product Owner/Manager et/ou des analystes métier.

Des scénarios de test valident la mise en œuvre de la user story

Les scénarios de test (souvent exprimés dans un format donné-quand-alors) poussent ce processus un peu plus loin. Ces détails sont souvent étoffés lors de la conversation déclenchée par la user story. Cela se produit entre le développeur chargé de mettre en œuvre la user story et l’auteur de la user story (éventuellement assisté par un analyste métier ou un propriétaire de produit). Idéalement, la conversation est planifiée au « dernier moment responsable » pour s’assurer que les développeurs obtiennent les informations les plus récentes possibles lorsqu’ils sont prêts à commencer à coder.

REMARQUE : les critères d’acceptation et les scénarios de test dépassent le cadre de cet article, mais vous pouvez tout apprendre à leur sujet dans notre cours Udemy, User Stories : un outil de collaboration pour les entreprises et l’informatique.

Les étudiants en Business Analysis apprennent également

Cas d’utilisation vs histoires d’utilisateurs : les cas d’utilisation fournissent un contexte et traitent de la complexité

Illustration de cas d'utilisation

Les cas d’utilisation sont beaucoup plus élaborés. Un cas d’utilisation fournit une réponse fondamentale à la question COMMENT en détaillant (à un niveau de détail approprié au bon moment) un ou plusieurs chemins potentiels qui mèneront à un résultat.

Composants d’une description de cas d’utilisation

Chaque chemin dans un cas d’utilisation décrit la série d’événements qui mènent finalement à un résultat spécifique (alors que plusieurs chemins peuvent mener à un résultat identique).

Un cas d’utilisation identifie également les préconditions et les postconditions. Les conditions préalables expriment des états et des données qui doivent être remplis pour que le cas d’utilisation fonctionne comme prévu. Les postconditions décrivent les états et les données qui sont créés si le cas d’utilisation se termine avec succès.

Exemple de cas d’utilisation métier

Par exemple, un cas d’utilisation traitant de la user story présentée précédemment pourrait commencer comme suit :

Nom du cas d’utilisation : Capturer les symptômes

Conditions préalables : Le patient a contacté l’établissement

Chemin standard :

1. Le médecin demande le dossier médical du patient

2. Le système affiche le dossier de santé

3. Le médecin interroge le patient pour identifier les symptômes

4. Le patient décrit les symptômes

5. Le médecin ajoute les symptômes au dossier de santé du patient

6. Le système prépare la vue du médecin des symptômes

7 …

Post-conditions : La liste des symptômes du patient est disponible pour le médecin

Chemins alternatifs :

A01 @ 2 Le patient n’a pas de dossier de santé

A01-01 Un médecin demande une nouvelle vue du patient

A01-02 Le système affiche une nouvelle vue patient

A01-03 Le médecin saisit les données personnelles du patient

A01-04 Reprendre @ 2

Les chemins standard, alternatifs et d’exception donnent une structure au cas d’utilisation

Il existe trois types de chemins dans un cas d’utilisation, ce qui le rend également unique lorsque l’on considère les cas d’utilisation par rapport aux histoires d’utilisateurs : un chemin standard (parfois appelé chemin « heureux »), plusieurs chemins alternatifs ou alternatifs (différentes façons d’atteindre le même résultat) et les chemins d’exception (que se passe-t-il en cas de problème). Un chemin d’exception ne conduit pas à une conclusion réussie du cas d’utilisation, ce qui signifie que la postcondition souhaitée n’est pas atteinte.

Un modèle de cas d’utilisation visualise les interactions avec les acteurs

Un modèle de cas d’utilisation comprend souvent un diagramme de cas d’utilisation décrivant les acteurs et les cas d’utilisation impliqués dans un processus complexe, ainsi qu’une description textuelle de chaque étape dans les différents chemins. Voici un exemple trop simplifié de notre scénario choisi :

Les cas d’utilisation fournissent un contexte supplémentaire si nécessaire

Étant donné que les témoignages d’utilisateurs sont spécifiques aux besoins d’un rôle unique (par exemple, visiteur de site Web, processeur de réclamations, agent commercial, etc.), ils peuvent être difficiles à comprendre sans le contexte. De nombreuses organisations, en particulier celles qui tirent parti des développeurs offshore, ont trouvé avantageux de fournir des modèles de cas d’utilisation qui montrent le contexte d’un ensemble de user stories. Chaque chemin à travers le cas d’utilisation a le potentiel de générer une ou plusieurs histoires d’utilisateurs. Il n’est pas rare que chaque étape d’un parcours soit exprimée sous la forme d’une user story avec tous les composants mentionnés ci-dessus.

REMARQUE : Une explication détaillée des cas d’utilisation dans les processus de développement de logiciels actuels est couverte dans notre cours Udemy, Analyse Métier Lean / Agile : Rédaction de Use Cases BUSINESS.

Les cas d’utilisation et les histoires d’utilisateurs fonctionnent bien ensemble

De toute évidence, la solution miracle très recherchée non plus. Pris ensemble, cependant, les cas d’utilisation et les témoignages d’utilisateurs brossent un tableau complet d’une solution numérique proposée et permettent aux développeurs de travailler avec plus de confiance sur ce qu’ils sont censés fournir. Étant donné que les cas d’utilisation définissent les post-conditions souhaitées et que les user stories fournissent à la fois des critères d’acceptation et des scénarios de test, les erreurs de communication sont minimisées, ce qui évite de nombreux problèmes qui affectaient les projets agiles dans le passé.