Aller au contenu
Read this post in: de_DEen_USes_ESfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW
Home » Agile & Scrum » Histoires d’utilisateurs et cas d’utilisation : un guide complet sur le développement agile

Histoires d’utilisateurs et cas d’utilisation : un guide complet sur le développement agile

Le développement agile est une méthodologie qui se concentre sur le développement itératif et incrémental des produits logiciels. Elle met l’accent sur la collaboration entre les équipes pluridisciplinaires, les retours continus et la flexibilité pour modifier les exigences tout au long du processus de développement. Deux techniques populaires utilisées dans le développement agile sont les histoires d’utilisateurs et les cas d’utilisation. Dans ce guide complet, nous explorerons ces deux techniques et soutiendrons qu’elles conviennent toutes deux au développement agile si elles sont utilisées de manière appropriée.

User story vs Use Case

Histoires d’utilisateurs

Les histoires d’utilisateurs sont des descriptions courtes et simples d’une fonctionnalité, racontées du point de vue de l’utilisateur final.

Ils suivent généralement un modèle spécifique :

« En tant que [type d’utilisateur], je veux [un certain objectif] afin que [une certaine raison].”

Les histoires d’utilisateurs sont un outil puissant dans le développement agile car elles aident les équipes à se concentrer sur les besoins de l’utilisateur final, et elles favorisent la communication et la collaboration entre les parties prenantes.

Exemple : Supposons que notre équipe développe une nouvelle plateforme de commerce électronique.

Une histoire d’utilisateur pourrait ressembler à ceci :

« En tant que acheteur, je veux pouvoir filtrer les résultats de recherche par plage de prix afin que je puisse trouver des produits correspondant à mon budget.”

Pourquoi s’agit-il d’un bon choix pour le développement agile ?

Les histoires d’utilisateurs sont un excellent choix pour le développement agile car elles sont légères, faciles à rédiger, et elles offrent une compréhension partagée de ce qui doit être construit. Elles sont également flexibles et peuvent être facilement modifiées tout au long du processus de développement. Cela les rend idéales pour les équipes agiles qui valorisent la collaboration, les retours continus et l’adaptabilité.

Cas d’utilisation

Les cas d’utilisation sont des descriptions détaillées du comportement d’un système du point de vue d’un acteur (généralement un utilisateur ou un autre système). Ils comprennent généralement une série d’étapes que l’utilisateur suit pour atteindre un objectif spécifique, et décrivent les interactions entre l’utilisateur et le système. Les cas d’utilisation sont un outil essentiel dans le développement agile car ils aident les équipes à comprendre le comportement du système et à identifier les problèmes potentiels dès les premières étapes du processus de développement.

Exemple : Continuons avec l’exemple de notre plateforme de commerce électronique.

Un cas d’utilisation pourrait ressembler à ceci :

« Un acheteur recherche un produit sur la plateforme. Il applique un filtre de prix et trie les résultats par notes des clients. Il ajoute le produit à son panier et passe à la caisse. Après avoir revu les détails de la commande, il soumet ses informations de paiement et finalise l’achat. »

Pourquoi s’agit-il d’un bon choix pour le développement agile ?

Les cas utilisateurs sont également un excellent choix pour le développement agile car ils fournissent une compréhension détaillée de la manière dont un système devrait se comporter. Ils aident les équipes à identifier les problèmes potentiels dès les premières étapes du processus de développement et à s’assurer que le système répond aux besoins de l’utilisateur final. Ils sont également utiles pour le test et la validation, qui constituent un aspect essentiel du développement agile.

Contraste entre les histoires d’utilisateurs et les cas utilisateurs

Bien que les histoires d’utilisateurs et les cas utilisateurs soient tous deux adaptés au développement agile, ils diffèrent de plusieurs manières. Les histoires d’utilisateurs sont légères et se concentrent sur les besoins de l’utilisateur final, tandis que les cas utilisateurs sont plus détaillés et décrivent le comportement du système. Les histoires d’utilisateurs sont généralement utilisées pour capturer des exigences de haut niveau, tandis que les cas utilisateurs servent à décrire des interactions spécifiques entre l’utilisateur et le système.

En fin de compte, le choix entre les histoires d’utilisateurs et les cas utilisateurs dépend des besoins spécifiques du projet. Les histoires d’utilisateurs sont plus adaptées aux projets dont les exigences sont floues ou susceptibles de changer, tandis que les cas utilisateurs sont plus appropriés pour les projets dont les exigences sont bien définies et précises. En pratique, de nombreuses équipes utilisent les deux techniques pour s’assurer qu’elles ont une compréhension complète du comportement du système et des besoins de l’utilisateur final.

Exemple – Magasin d’épicerie en ligne

Exemple d’histoire d’utilisateur : «En tant que mère occupée, je souhaite pouvoir créer une liste de courses dans l’application afin de pouvoir suivre facilement les articles que je dois acheter. Je souhaite également pouvoir ajouter et supprimer des articles de la liste et marquer les articles comme achetés une fois que j’ai terminé mes courses.”

Dans cette histoire d’utilisateur, nous avons décrit une fonctionnalité spécifique qui répond aux besoins de l’utilisateur final (les mères occupées) et leur apporte de la valeur (suivre facilement leur liste de courses). L’histoire d’utilisateur est rédigée du point de vue de l’utilisateur final et utilise un modèle spécifique pour assurer clarté et cohérence.

Exemple de cas utilisateur : L’utilisateur souhaite créer une nouvelle liste de courses dans l’application. Il ouvre l’application et accède à la fonctionnalité de liste de courses. Il clique sur le bouton « Créer une nouvelle liste » et entre un nom pour la liste. Ensuite, il commence à ajouter des articles à la liste en cliquant sur le bouton « Ajouter un article » et en tapant le nom de l’article. Il peut également préciser une quantité ou des notes supplémentaires. Une fois que l’utilisateur a ajouté tous les articles dont il a besoin, il peut enregistrer la liste et y revenir plus tard. Il peut également marquer les articles comme achetés une fois qu’ils ont été achetés.

Dans ce cas utilisateur, nous avons décrit un scénario spécifique dans lequel l’utilisateur interagit avec la fonctionnalité de liste de courses de l’application. Nous avons décrit les étapes que l’utilisateur suit pour atteindre son objectif ainsi que les interactions entre l’utilisateur et le système. Le cas utilisateur est plus détaillé que l’histoire d’utilisateur et fournit une compréhension complète du comportement attendu de la fonctionnalité.

Les deux approches, histoire d’utilisateur et cas utilisateur, sont utiles pour le développement agile. L’histoire d’utilisateur fournit un aperçu de haut niveau de la fonctionnalité et se concentre sur les besoins de l’utilisateur final, tandis que le cas utilisateur fournit une description plus détaillée du comportement de la fonctionnalité. L’utilisation des deux approches assure que l’équipe de développement dispose d’une compréhension complète de la fonctionnalité et des besoins de l’utilisateur final, ce qui est essentiel pour un développement agile réussi.

Détailler une histoire d’utilisateur avec les 3C

Voici une possible analyse des 3C pour l’exemple d’histoire d’utilisateur :

  1. Carte : « En tant que mère occupée, je souhaite pouvoir créer une liste de courses dans l’application afin de pouvoir suivre facilement les articles que je dois acheter. Je souhaite également pouvoir ajouter et supprimer des articles de la liste et marquer les articles comme achetés une fois que j’ai terminé mes courses. »
  2. Conversation :
  • Product Owner : « Pouvez-vous me dire plus sur la raison pour laquelle vous devez suivre votre liste de courses ? »
  • Mère occupée : « Bien sûr, en tant que mère avec un emploi du temps chargé, je dois m’assurer de ne rien oublier lorsque je vais à l’épicerie. Ce serait vraiment utile si je pouvais facilement créer une liste de courses sur mon téléphone et ajouter ou supprimer des articles selon mes besoins. »
  • Product Owner : « Je comprends. Et à quel point est-il important pour vous de pouvoir marquer les articles comme achetés ? »
  • Mère occupée : « C’est important car ainsi je peux rapidement voir ce que j’ai déjà acheté et ce que je dois encore acheter. »
  1. Confirmation : « En tant que mère occupée, je peux créer une liste de courses dans l’application, ajouter et supprimer des articles de la liste, et marquer les articles comme achetés une fois que j’ai terminé mes courses. »

Détailler un cas utilisateur avec une description de cas utilisateur

Voici un exemple de description de cas utilisateur basé sur la description du problème et l’histoire d’utilisateur :

Nom du cas utilisateur : Créer et gérer une liste de courses

Acteurs :

  • Utilisateur : la personne qui souhaite créer et gérer une liste de courses dans l’application.

Préconditions :

  • L’utilisateur a téléchargé et installé l’application sur son appareil mobile.
  • L’utilisateur dispose d’une connexion internet stable.

Postconditions :

  • L’utilisateur a créé et géré avec succès une liste de courses dans l’application.

Déroulement des événements :

  1. L’utilisateur ouvre l’application et accède à la fonctionnalité de liste de courses.
  2. L’application affiche une liste des listes de courses existantes ou invite l’utilisateur à créer une nouvelle liste.
  3. L’utilisateur clique sur le bouton « Créer une nouvelle liste ».
  4. L’application invite l’utilisateur à saisir un nom pour la nouvelle liste.
  5. L’utilisateur saisit un nom pour la nouvelle liste et clique sur « Enregistrer ».
  6. L’application affiche la liste de courses vide avec le nom que l’utilisateur a saisi.
  7. L’utilisateur clique sur le bouton « Ajouter un élément ».
  8. L’application invite l’utilisateur à saisir le nom de l’élément qu’il souhaite ajouter à la liste.
  9. L’utilisateur saisit le nom de l’élément et clique sur « Ajouter ».
  10. L’application affiche le nouvel élément dans la liste de courses.
  11. L’utilisateur répète les étapes 7 à 10 jusqu’à ce qu’il ait ajouté tous les éléments nécessaires à la liste.
  12. L’utilisateur peut supprimer un élément de la liste en cliquant sur le bouton « Supprimer l’élément » à côté de l’élément.
  13. L’utilisateur peut marquer un élément comme acheté en cliquant sur le bouton « Marquer comme acheté » à côté de l’élément.
  14. L’application met à jour la liste de courses pour refléter tous les changements apportés par l’utilisateur.
  15. L’utilisateur peut consulter la liste de courses à tout moment en revenant à la fonctionnalité de liste de courses dans l’application.

Flux alternatifs :

  • Si l’utilisateur annule la création d’une nouvelle liste à l’étape 5, l’application ramène l’utilisateur à la liste des listes de courses existantes ou invite à nouveau l’utilisateur à créer une nouvelle liste.
  • Si l’utilisateur annule l’ajout d’un nouvel élément à l’étape 9, l’application ramène l’utilisateur à la liste de courses sans ajouter l’élément.

Différences entre les user stories et les cas d’utilisation

Le tableau présente un résumé des différences entre les user stories et les cas d’utilisation. Les user stories sont des descriptions courtes et simples centrées sur les objectifs et besoins de l’utilisateur, tandis que les cas d’utilisation fournissent des descriptions détaillées étape par étape du comportement et des fonctionnalités du système.

User Stories Cas d’utilisation
Description courte et simple d’une fonctionnalité du point de vue de l’utilisateur. Descriptions détaillées étape par étape de la manière dont un utilisateur interagit avec un système.
Centrée sur les objectifs et les besoins de l’utilisateur. Se concentre sur le comportement et la fonctionnalité du système.
Met l’accent sur la conversation et la collaboration entre les parties prenantes. Mettre l’accent sur une approche plus formalisée et structurée.
Souvent rédigé dans un style plus informel et conversationnel. Souvent rédigé dans un style plus formalisé et technique.
Typiquement utilisé pour capturer les exigences et fonctionnalités de haut niveau. Typiquement utilisé pour capturer les exigences fonctionnelles détaillées.
Typiquement plus facile et plus rapide à rédiger et à examiner. Typiquement plus chronophage à rédiger et à examiner.

Résumé

L’article explore l’utilisation des histoires d’utilisateurs et des cas d’utilisation dans le développement agile, soutenant que les deux approches sont adaptées lorsqu’elles sont utilisées de manière appropriée. Les histoires d’utilisateurs sont des descriptions courtes et simples d’une fonctionnalité du point de vue de l’utilisateur, tandis que les cas d’utilisation fournissent une description détaillée et étape par étape de la manière dont un utilisateur interagit avec un système.

Un exemple de problème lié à la création et à la gestion d’une liste de courses est utilisé pour illustrer comment les deux approches peuvent être utilisées. L’article met l’accent sur l’importance des 3Cs (Carte, Conversation, Confirmation) dans la création d’histoires d’utilisateurs efficaces, ainsi que sur l’importance des acteurs, des préconditions et des postconditions dans la création de cas d’utilisation efficaces. Globalement, l’article fournit un guide complet pour les développeurs logiciels sur la manière d’utiliser efficacement les histoires d’utilisateurs et les cas d’utilisation dans le développement agile.

En conclusion, les histoires d’utilisateurs et les cas d’utilisation sont tous deux des outils précieux dans le développement agile lorsqu’ils sont utilisés de manière appropriée. Les histoires d’utilisateurs sont légères, faciles à rédiger et flexibles, ce qui les rend idéales pour les projets dont les exigences évoluent. Les cas d’utilisation sont détaillés et offrent une compréhension complète du comportement du système, ce qui les rend idéaux pour les projets dont les exigences sont bien définies. En utilisant les deux techniques, les équipes agiles peuvent s’assurer d’avoir une compréhension complète du comportement et des objectifs du système.

Laisser un commentaire