Si vous êtes engagé dans le développement de logiciels, vous devez avoir entendu parler des user stories. Peut-être même les écrivez-vous en tant que manager. Ou peut-être êtes-vous un client et votre développeur de logiciels veut que vous encadriez les demandes de fonctionnalités en tant que user stories.

Dans ce post, vous trouverez tout ce que vous avez toujours voulu savoir sur les user stories.

Qu’est-ce qu’une user story dans le développement de logiciels ?

Une user story est un format pour encadrer les fonctionnalités et/ou les exigences du logiciel. Comme la partie « utilisateur » le suggère, les user stories sont écrites à la première personne du singulier et décrivent une fonctionnalité telle qu’elle est perçue par l’utilisateur de l’application.

Une user story typique suit cette structure (si nous parlons du processus de développement Agile):

En tant que ,
Je veux ,
Pour que .

La première partie (en tant que….) précise le rôle de l’utilisateur dans l’application, qui est normalement associé à ce que l’on est autorisé à y faire.

La deuxième partie (la fonctionnalité) pointe vers le morceau de fonctionnalité qui est utilisé dans ce cas.

La troisième partie (le résultat souhaité) est la valeur que l’utilisateur veut obtenir de la fonctionnalité. Voici quelques exemples.

Exemple 1

En tant qu’utilisateur enregistré,
je veux être notifié lorsqu’un ami se rend à un événement à proximité
Pour que je puisse réagir à la nouvelle ou les rejoindre à l’événement.

Exemple 2

En tant qu’usager,
je veux obtenir une réduction de 10% sur chaque 10ème trajet
Pour que je sois récompensé pour avoir constamment dépensé de l’argent sur le service.

Il y a des raisons valables pour ce genre de structure. Lorsque les gestionnaires de produits/projets traitent des exigences logicielles qui proviennent de diverses sources, il leur est parfois difficile d’atteindre l’uniformité. La catégorie d’utilisateurs concernés par la fonctionnalité ou la valeur commerciale de celle-ci peuvent également ne pas être claires. Le format de l’histoire d’utilisateur aide à capturer ces détails critiques.

Approches de la composition des histoires d’utilisateur

Les histoires d’utilisateur peuvent être écrites de différentes manières, en fonction de ceux qui vont travailler avec elles.

The Gherkin Way

Gherkin est un langage en texte clair qui décrit le comportement sans spécifier son implémentation. Voici un exemple simple de la syntaxe Gherkin:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

Comme vous avez pu le remarquer, l’indentation définit la structure dans Gherkin. Les paramètres de base sont Given/When/Then, et ceux-ci peuvent être complétés par de multiples And si nécessaire. La syntaxe va au-delà de ces paramètres de base, cependant. Si vous êtes vraiment déterminé à maîtriser Gherkin, voici un bon tutoriel.

Bien que Gherkin ne soit peut-être pas le meilleur choix lorsque vous recueillez les exigences initiales du projet, il peut être bénéfique (surtout pour l’équipe d’assurance qualité) lors de la poursuite du développement des user stories. Les user stories écrites en Gherkin sont faciles à convertir en cas de test.

La méthode Agile

Plusieurs applications de gestion de projet Agile offrent une fonctionnalité de saisie des user stories. Par exemple, nous avons utilisé l’application Taiga sur certains de nos projets internes. Elle vous aide à organiser le travail autour des user stories qui peuvent être décomposées en tâches individuelles dans le backlog.

Source : Interface Taiga.io

Si vous y réfléchissez, il est parfaitement logique d’avoir des user stories en tant qu’éléments du backlog, puis d’ajouter plusieurs tâches à une user story. Pourquoi ? Parce que, disons, vous avez une fonctionnalité (= user story) et trois personnes qui travaillent dessus ; vous aurez besoin de tâches distinctes pour ces personnes. Vous aurez besoin d’un designer pour concevoir l’interface, d’un programmeur HTML/JavaScript pour programmer l’interface, et du DevOps pour mettre l’interface en production.

D’autres outils comme Pivotal Tracker (qui introduit le concept d' »épopées » pour regrouper des histoires connexes) vous permettent également de créer des histoires qui peuvent être de différents types : Fonctionnalités, Corvées, Bugs ou Releases.

Source : PivotalTracker.com

A part les différentes approches utilisées par diverses entreprises, rappelez-vous qu’il y a une façon simple et directe de formuler des histoires d’utilisateur – dont vous avez vu des exemples au début de ce post.

Qui devrait écrire des histoires d’utilisateur?

Alors, à qui incombe la responsabilité d’écrire des histoires d’utilisateur ? Eh bien, cela dépend. Si votre équipe a accepté de capturer des fonctionnalités sous forme d’user stories, il est fort probable qu’elles proviennent des actionnaires par le biais du Product Owner. Ainsi, il se peut que ce soit le PO qui les rédige réellement.

Il pourrait également s’agir d’un chef de projet ou d’un AQ qui peut également travailler avec le client pour discuter des fonctionnalités et des exigences. Ou, peut-être que vous êtes une startup de 15 personnes et que vous êtes le PDG, le CTO et le CMO ? Dans ce cas, vous pourriez montrer l’exemple et commencer à utiliser des histoires d’utilisateur pour documenter les fonctionnalités.

De nombreuses personnes dans le domaine de l’informatique parlent également du « développement d’histoires d’utilisateur », qui est le processus d’enregistrement des détails de haut niveau d’abord (par exemple, en commençant par une simple liste de fonctionnalités), puis de leur développement en histoires plus détaillées en ajoutant des tâches, des scénarios, etc.

En conclusion

En fin de compte, la formulation des fonctionnalités sous la forme d’histoires d’utilisateur vous aide à rester concentré sur les objectifs commerciaux. Cela vous aide également à rendre les exigences complètes. Et, comme cela a été dit, le modèle/les champs exacts que vous utilisez pourraient être différents, en fonction de la situation.