Méthodologie en ESM : Comment rédiger une user story ?
User Story kézako ?
Une user story est une formulation simple et compréhensible de tous d’un besoin fonctionnel, traduisant un cas d’usage souhaité par certains utilisateurs afin d’apporter une utilité à leur métier.
On l’utilise notamment dans le cadre de la gestion de projet agile en développement ou intégration de logiciels.
Exemple concret
En tant que Responsable des Incidents IT,
Je veux recevoir une notification mail lorsqu’un ticket est indiqué en tant que « incident majeur »,
Afin de décider d’actions et/ou communications spécifiques à mener rapidement.
Ici le responsable du support informatique a un besoin fonctionnel d’usage (recevoir une information par mail) pour une utilité sous-jacente (prendre ensuite des décisions), suffisamment précis et compréhensible de tous.
En restant agnostique de toute notion de produit, cela permet de proposer plusieurs solutions techniques pour y répondre.
A noter que pour aller plus loin dans les spécifications du besoin, notamment quand il s’agit de tester tous les cas d’usage possibles, il est parfois nécessaire de décliner une story en tests d’acceptation avec la syntaxe Gherkin :
Etant donné Marcel Patulacci, technicien au support Niveau 1
Quand il met l’indication « incident majeur » sur un ticket dans le statut En attente, puis clique sur Enregistrer
Alors un mail part bien au Responsable des Incidents IT
Méthode de rédaction
Pour rédiger correctement des user stories, différents critères sont à évaluer, que l’on regroupe sous l’acronyme INVEST :
I pour Indépendante : indépendante des autres au moins sur le sprint en cours.
N pour négociable : les détails doivent être négociables. d’où cette seule petite phrase afin de ne pas forcer les détails
V pour valeur : apporter de la valeur business pour les métiers ou les clients
E pour Estimable : estimable par les équipes de développement ; pour cela, ces équipes doivent bien les comprendre.
S pour Suffisamment petite : bien découpée afin d’être livrée au sein d’un seul Sprint.
T pour Testable : testables.
Outillage de réalisation
Pour réaliser ensuite le besoin, vous devez disposer de moyens techniques. Dans cet exemple, vous aurez besoin d’un outil qui permette de créer/modifier des champs dans un formulaire d’incident, ainsi qu’envoyer des notifications mails.
La solution Matrix42 ESM permet de répondre précisément aux exigences techniques :
- Créer un nouveau champ
- L’afficher avec une aide à l’utilisation
- Créer des rôles de gestion
- Créer des modèles de mails (multilingue)
- Créer le déclencheur sur événement
Afin de garantir une maintenabilité, le paramétrage se doit aussi d’être facilement adaptable. Par exemple pour un ticket à adresser à une équipe en particulier, Matrix42 permet de dynamiser le formulaire et mettre en place une variable plutôt que gérer chaque cas particulier.
Accompagnement au changement
DMI accompagne les directions informatiques et implémente des solutions de gestion des services informatiques et métiers. L’équipe consulting met en œuvre de nouveaux processus chaque jour à la demande de ses clients, en s’appuyant notamment sur cette méthodologie agile.
Contactez-nous afin d’échanger sur vos besoins/attentes, nous serions ravis d’atteindre vos objectifs.
