Développement

Une analyse approfondie des récits utilisateurs

Nathaniel Ram

min read

Vous êtes-vous déjà retrouvé au beau milieu d’un projet de développement logiciel Agile? Si oui, vous devez être familier avec le mot récit utilisateur (user story). Notre objectif est de définir ce qu'ils sont, pourquoi sont-ils importants, et de partager certaines de nos réflexions concernant la façon dont nous pouvons contribuer au bon déroulement des projets en maîtrisant l'art des récits utilisateurs.

Mais d’abord, qu’est-ce qu’un récit utilisateur?

L'une des définitions courantes d'un récit utilisateur est la suivante : Dans le développement de logiciels et la gestion de produits, un récit utilisateur est une description informelle, en langage naturel, des caractéristiques d'un système logiciel. Le concept des récits utilisateurs est né vers la fin des années 1990, mais c'est en 2001 que Ron Jeffries (l'un des trois fondateurs de la méthodologie de développement logiciel Extreme Programming) propose les « trois C» pour la création de récits utilisateurs. Encore d'actualité, ils sont utilisés lors de la rédaction des récits utilisateurs.

Carte ( i.e. post it note, carte Trello, carte Jira, etc.) en tant que support physique tangible des concepts. Généralement, celles-ci ne comprennent qu’une à trois phrases résumant les exigences détaillées. Leur but étant de mieux planifier. La carte est assignée à l'équipe de développement pour qu’elle la mette en œuvre. Une fois les modifications apportées, les développeurs déploient la nouvelle version sur l’environnement de préproduction pour que le client puisse valider.
Conversation - une conversation verbale et documentée entre les parties concernées (clients, utilisateurs, équipe de développement, testeurs (QA), etc.) L'objectif étant la compréhension de tous.
Confirmation - garantis que les objectifs de la conversation aient été atteints.

Quel doit être le format d'un récit utilisateur?

Le format de récit utilisateur Connextra est l'une des solutions possibles pour formater les récits utilisateurs. C’est un modèle que vous pouvez choisir de suivre pour vous aider à démarrer. Il doit répondre aux questions suivantes: Qui/Quoi/Pourquoi?

Par exemple: En tant que rôle, je veux une fonctionnalité (feature) qui apporte un bénéfice. C'est un moyen efficace de répondre à ces questions.

Quelles sont les caractéristiques d'un bon récit utilisateurs?

Bill Wake (consultant en développement logiciel) a proposé INVEST en 2003.

Indépendance - tous les récits utilisateurs que vous écrivez doivent être indépendants les uns des autres. Si vous pensez qu'un récit utilisateur est dépendant d'un autre, vous avez probablement décomposé l'histoire trop finement. De même, si votre récit utilisateur est trop large, il s'agit très probablement d' une épopée (méthodologie Agile - epic en anglais). Pour faire simple, un récit utilisateur doit être une fonctionnalité pratique et efficace dont les utilisateurs pourront tirer profit.
Négociable - Un bon récit utilisateur est négociable. Il ne s'agit pas d'un contrat explicite pour les fonctionnalités ; les détails seront plutôt co-créés par le client et le programmeur au cours de la conception. Un bon récit capture l'essence, pas les détails. Au fil du temps, la carte peut acquérir des notes, des idées de test, etc., mais il est inutile de les utiliser pour hiérarchiser ou planifier les récits.
Valeur - chaque récit utilisateur que vous priorisez et sur lequel vous travaillez doit apporter de la valeur à vos clients et résoudre leur problème.
Estimable - Nous n'avons pas besoin d'une estimation exacte, mais juste assez pour aider le client à classer et à planifier la mise en œuvre du récit. La capacité à estimer est en partie fonction de la négociation, car il est difficile d’estimer un récit que l’on ne comprend pas. C'est aussi une question de taille : un récit plus grand est plus difficile à estimer.
Petit (small) - Les récits représentent généralement tout au plus quelques semaines/jours/personnes de travail (selon l'équipe). Au-delà de cette taille, il est trop difficile de savoir ce qui est couvert par le récit. Dire « cela me prendrait plus d'un mois » ajoute souvent, implicitement : « car je ne comprends pas ce que cela impliquerait. » Les petits récits utilisateurs ont tendance à obtenir des estimations plus précises.
Testable - écrire une carte de récit comporte une promesse implicite : «Je comprends suffisamment bien ce que je veux pour pouvoir écrire un test en conséquence.» Plusieurs équipes ont signalé qu'en exigeant des tests de la part des clients avant de mettre en œuvre un récit utilisateur, l'équipe est plus productive. La « testabilité » a toujours été l’une caractéristique d’exigences de qualité ; l'écriture des tests en début de projet nous permet de savoir si cet objectif est atteint. Si les clients ne savent pas comment tester quelque chose, cela peut indiquer que le récit n'est pas assez clair, ou qu'il ne représente pas quelque chose d'important à leur yeux.

Que faire si les récits utilisateurs ne sont pas applicables?

Disons que vous travaillez sur une application/site/logiciel qui n'a pas de rôles utilisateurs. Il n'y a que des utilisateurs. Quelle valeur apporte un récit utilisateur? Nous savons déjà qui! Nous vous recommandons d'essayer les « job stories ».

Il s'avère que tous les récits utilisateurs peuvent être réécrits en « job stories » et vice versa.

Récit utilisateur : En tant qu'estimateur, je veux voir l'article que nous évaluons, afin que je sache ce pour quoi je donne une estimation.
« Job story » : Lorsque je trouve un item pour lequel je veux établir une estimation, je veux être capable de le voir, afin de pouvoir confirmer qu’il est le bon.

Récapitulons!

Les récits utilisateurs sont de courtes et simples descriptions de la façon dont une fonctionnalité sera utilisée. Ils sont écrits dans un langage informel et naturel, du point de vue de l'utilisateur. Il reflète leur besoin et l'objectif qu'ils ont l'intention d'atteindre en utilisant votre fonctionnalité.

Il s'agit d'un petit travail ayant une certaine valeur pour l'utilisateur et qui peut être réalisé par l'équipe de développement pendant le sprint agile. Il décrit ce que veut un utilisateur, qui est l'utilisateur et pourquoi il le réclame (il n'est pas nécessaire de suivre le format Connextra! - En tant que rôle, je veux une fonctionnalité qui apporte un bénéfice)

N'oubliez pas les trois C - carte, conversation, confirmation.

Un récit n'est pas un contrat. C'est une invitation à une conversation. Le récit capture l'essence de ce qui est demandé.

Un récit doit suivre INVEST