Les user stories
Une user story
Une user story est une description simple et concise d'une petite fonctionnalité d'un logiciel, rédigée du point de vue de l'utilisateur final.
Une user story permet de définir ce que l'utilisateur souhaite accomplir et pourquoi.
Les user stories sont souvent utilisées dans les méthodologies agiles, comme SCRUM, pour planifier et développer des logiciels de manière itérative.
Les user stories favorisent la communication entre le client, le chef de projet et les développeurs.
Le format d'une user story
Une user story suit généralement un format en 3 parties.
En tant que [type d'utilisateur], je veux [action ou fonctionnalité], afin de [bénéfice ou objectif].
Ce format aide à clarifier trois éléments essentiels :
- Qui : l'utilisateur ou le rôle concerné.
- Quoi : la fonctionnalité ou l'action souhaitée.
- Pourquoi : l'objectif ou la valeur ajoutée pour l'utilisateur.
Les user stories doivent être :
- Indépendantes : elles peuvent être réalisées séparément.
- Négociables : elles peuvent être discutées et ajustées.
- Valorisées : elles apportent une valeur à l'utilisateur.
- Estimables : leur complexité peut être évaluée.
- Small (petites) : elles sont réalisables dans une itération (un sprint).
- Testables : elles incluent des critères d'acceptation clairs.
Ces caractéristiques sont souvent résumées par le sigle INVEST.
Les critères d'acceptation
Les critères d'acceptation définissent les conditions à remplir pour considérer la user story comme terminée.
Par exemple, pour une fonctionnalité de connexion, un critère pourrait être : "L'utilisateur reçoit un message d'erreur si le mot de passe est incorrect."
Le backlog
Les user stories sont souvent accompagnées d'un backlog.
-
Un backlog est une liste priorisée de user stories à réaliser dans un projet.
-
Le backlog est généralement rempli par le Product Owner, en collaboration avec le client et l'équipe des développeurs.
-
Les user stories servent de base pour planifier les sprints.
Il est important de ne pas confondre une user story avec une spécification technique.
- Une user story se concentre sur le besoin de l'utilisateur,
- tandis qu'une spécification technique détaille comment implémenter cette fonctionnalité.
Une bonne user story est claire, concise et centrée sur l'utilisateur, évitant les détails techniques dans sa description initiale.
Un epic
Un epic est utilisé pour représenter une grosse fonctionnalité.
Un epic est un regroupement de plusieurs user stories (descriptions simples d'une petite fonctionnalité).
- Une user story est petite et réalisable dans une itération.
- Un epic est plus vaste et nécessite généralement plusieurs sprints pour être complété.
Par exemple, dans une application de gestion de tâches, un epic pourrait être : "Mettre en place un système de collaboration pour les tâches."
Cet epic peut inclure plusieurs user stories :
- partager une tâche avec un autre étudiant,
- ajouter des commentaires à une tâche,
- assigner une tâche à un autre utilisateur.
Les epics aident à structurer le backlog en regroupant les user stories, pour faciliter la planification et la priorisation.
Exemple pratique
Imaginons que nous souhaitons ajouter des nouvelles fonctionnalités à l'application Web TodoMVC 
https://github.com/tastejs/todomvc.
Fonctionnalités actuelles
Actuellement avec TodoMVC, il est possible de :
- Créer un formulaire avec un champ pour le titre de la tâche et un sélecteur de date.
- Valider l'entrée pour s'assurer que le titre n'est pas vide.
- Enregistrer la tâche dans une base de données ou une liste en mémoire.
- Afficher la liste des tâches sur la page principale avec leur date d'échéance.
Ajout d'une fonctionnalité
Ajouter une petite fonctionnalité (plusieurs petites fonctionnalités peuvent être regroupées dans un epic).
Voici 5 étapes pour pour traduire les besoins des utilisateurs en code et enrichir l'application TodoMVC :
-
1) Identifier le besoin : Recueillir les attentes des utilisateurs via des discussions, par exemple avec des étudiants souhaitant regrouper leurs tâches par type (Études, Personnel, Projets, etc).
En tant qu'étudiant, je veux assigner une catégorie à une tâche, afin de mieux organiser mes activités par type.
- 2) Définir les critères d'acceptation : Lister les conditions pour valider la user story, par exemple :
- Ajouter un menu déroulant pour sélectionner une catégorie lors de la création d'une tâche.
- Afficher la catégorie à côté de chaque tâche dans la liste.
- Permettre de filtrer les tâches par catégorie.
- 3) Traduire en spécifications techniques : Transformer la user story en tâches techniques. Par exemple :
- Ajouter une propriété "category" à l'objet tâche dans le code JavaScript.
- Modifier le formulaire HTML pour inclure un
<select>avec des options prédéfinies (Études, Personnel, Projets). - Écrire une fonction JavaScript pour filtrer les tâches par catégorie et mettre à jour l'affichage.
- 4) Développer la petite fonctionnalité : Implémenter la solution dans un langage comme JavaScript.
Par exemple, dans TodoMVC, modifier le fichier
index.jspour inclure une fonctionfilterByCategoryqui affiche uniquement les tâches d'une catégorie sélectionnée.
- 5) Tester la petite fonctionnalité : Vérifier que les critères d'acceptation sont remplis, par exemple en ajoutant une tâche avec la catégorie "Études" et en filtrant pour confirmer que seules les tâches de cette catégorie s'affichent.
Ces 5 étapes garantissent que les besoins des utilisateurs sont traduits en fonctionnalités concrètes.
Pour être agile, les user stories sont régulièrement revues et modifiées en fonction des retours des utilisateurs.
Backlog pour gérer les user stories
Un backlog est une liste priorisée de user stories à réaliser dans un projet.
Voici un exemple de backlog pour ajouter des fonctionnalités à l'application TodoMVC.
| User Story | Critères d'acceptation | Priorité |
|---|---|---|
| En tant qu'étudiant, je veux assigner une catégorie à une tâche, afin de mieux organiser mes activités par type (Études, Personnel, Projets). | - Ajouter un menu déroulant pour sélectionner une catégorie. - Afficher la catégorie à côté de chaque tâche. - Permettre de filtrer les tâches par catégorie. | Haute |
| En tant qu'étudiant, je veux recevoir une notification avant la date d'échéance d'une tâche, afin de ne pas oublier mes devoirs. | - Configurer une alerte 24 heures avant la date d'échéance. - Afficher la notification dans l'application. - Permettre de désactiver les notifications. | Haute |
| En tant qu'étudiant, je veux ajouter une description détaillée à une tâche, afin de mieux comprendre ce que je dois faire. | - Ajouter un champ texte pour la description. - Afficher la description au survol de la tâche. - Enregistrer la description avec la tâche. | Moyenne |
| En tant qu'étudiant, je veux trier les tâches par date d'échéance, afin de prioriser mon travail. | - Ajouter un bouton pour trier par date. - Afficher les tâches dans l'ordre chronologique. - Permettre un tri ascendant ou descendant. | Moyenne |
| En tant qu'étudiant, je veux partager une tâche avec un autre étudiant, afin de collaborer sur un projet commun. | - Ajouter un bouton pour partager une tâche. - Générer un lien partageable pour la tâche. - Afficher un message de confirmation après partage. | Basse |
Test de mémorisation/compréhension
TP (en PHP/Symfony) avec Sylius
L'objectif est de rédiger des user stories pour enrichir une application Web appelée Sylius.
Sylius est une plateforme open-source construite avec le framework PHP Symfony, qui permet de gérer des produits, des commandes, et des paiements dans une boutique en ligne, accessible à l'adresse : https://github.com/Sylius/Sylius.
1) Découvrir Sylius
-
Visiter le dépôt GitHub de Sylius à l'adresse : https://github.com/Sylius/Sylius.
-
Lire le fichier
README.mdpour comprendre les fonctionnalités actuelles. -
Identifier 2 limitations ou besoins non couverts, en imaginant un étudiant achetant des livres universitaires.
Penser à des besoins simples, comme suivre la disponibilité d’un livre ou sauvegarder des produits pour plus tard.
Une solution
Vous devez être connecté pour voir le contenu.
2) Définir un epic
-
Rédiger un epic regroupant des fonctionnalités liées à un objectif commun pour Sylius.
-
Formuler l’epic en une phrase claire, représentant un besoin large nécessitant plusieurs user stories.
Choisir un objectif simple, comme améliorer l’achat de livres pour les étudiants.
Une solution
Vous devez être connecté pour voir le contenu.
3) Rédiger une user story
-
Choisir une fonctionnalité liée à l’epic.
-
Rédiger une user story au format :
En tant que [type d’utilisateur], je veux [action ou fonctionnalité], afin de [bénéfice ou objectif].
-
Inclure deux critères d’acceptation clairs et testables.
La user story doit être simple et utile pour un étudiant.
Une solution
Vous devez être connecté pour voir le contenu.
4) Traduire en spécifications
-
Transformer la user story en 2 tâches techniques pour son implémentation.
-
Inclure des modifications dans le code PHP/Symfony (par exemple, templates Twig ou contrôleurs).
-
S’appuyer sur la structure de Sylius.
Se baser sur la documentation Sylius pour identifier les fichiers pertinents.
Une solution
Vous devez être connecté pour voir le contenu.
5) Créer un backlog
-
Construire un backlog pour l’epic, incluant 2 user stories (dont celle de l’étape 3).
-
Présenter le backlog en tableau avec les colonnes : User Story, Critères d’acceptation, Priorité (Haute, Moyenne, Basse).
-
Vérifier que les user stories sont indépendantes.
Les user stories doivent être simples et respecter les principes INVEST.
Une solution
Vous devez être connecté pour voir le contenu.
TP (en Javascript) avec Notesnook
L'objectif est de rédiger des user stories pour enrichir une application Web de prise de notes appelée Notesnook, https://github.com/streetwriters/notesnook.
Notesnook est une application de prise de notes sécurisée et open source, qui permet aux utilisateurs de créer, modifier, supprimer et afficher des notes avec un accent sur la confidentialité via le chiffrement.
Notesnook permet actuellement de créer, modifier, supprimer et afficher des notes avec un titre et un contenu texte, avec un accent sur la confidentialité via le chiffrement.
Il vous est delandé de rédiger un epic et des user stories pour ajouter de nouvelles fonctionnalités, pour répondre aux besoins d'un client, en suivant un processus structuré.
1) Explorer l'application Notesnook
-
Accéder au dépôt GitHub de Notesnook à https://github.com/streetwriters/notesnook.
-
Lire la documentation (fichier
README.md) pour comprendre les fonctionnalités existantes. -
Identifier au moins 3 limitations ou besoins non couverts par l'application actuelle.
Imaginez que vous êtes un étudiant utilisant Notesnook pour organiser vos cours, réviser avant un examen, utiliser des schémas ou collaborer avec d’autres étudiants.
Une solution
Vous devez être connecté pour voir le contenu.
2) Définir un epic
Rédiger un epic qui regroupe un ensemble de fonctionnalités liées à un objectif commun pour améliorer Notesnook.
L'epic doit être formulé en une phrase claire, reflétant un besoin large qui nécessite plusieurs user stories (plusieurs sprints).
Une solution
Vous devez être connecté pour voir le contenu.
3) Rédiger une user story
-
Choisir une fonctionnalité spécifique liée à l’epic défini.
-
Rédiger une user story en suivant le format standard :
En tant que [type d’utilisateur], je veux [action ou fonctionnalité], afin de [bénéfice ou objectif].
Inclure au moins 3 critères d’acceptation clairs et testables, qui définissent les conditions pour considérer la user story comme terminée.
Une solution
Vous devez être connecté pour voir le contenu.
4) Traduire en spécifications
-
Transformer la user story rédigée en tâches techniques nécessaires pour son implémentation.
-
Lister au moins trois tâches précises, incluant des modifications dans le code (par exemple, structures de données, interface utilisateur, ou logique JavaScript).
S'appuyer sur le code du projet Notesnook (HTML, CSS, JavaScript, avec un backend Node.js) https://github.com/streetwriters/notesnook.
Une solution
Vous devez être connecté pour voir le contenu.
5) Créer un backlog
Construire un backlog pour l’epic défini, incluant au moins 3 user stories (dont celle rédigée à l’étape 3).
Présenter le backlog sous forme de tableau, avec les colonnes : User Story, Critères d’acceptation, Priorité (Haute, Moyenne, Basse).
S'assurer que les user stories sont indépendantes, valorisées, et cohérentes avec l’epic.
Une solution
Vous devez être connecté pour voir le contenu.