Apprenez à rédiger de meilleures histoires d'utilisateurs

Apprenez à rédiger de meilleures histoires d'utilisateurs

Que sont les user stories ?

Une user story est un espace réservé pour une conversation, une phrase ou quelques-unes utilisées par les équipes de développement de logiciels Agile pour décrire les fonctionnalités précieuses sur lesquelles elles ont l'intention de travailler.

La user story est un moyen de communication (et un déclencheur pour une communication ultérieure).

Les user stories sont un moyen de communiquer succinctement les besoins fonctionnels orientés utilisateur de logiciel. Il s'agit d'une manière abrégée et de haut niveau de décrire les exigences logicielles. Ils sont utilisés dans le cadre du travail logiciel Agile et sont conçus pour stimuler une conversation. Elles constituent souvent la seule forme écrite des exigences.

Les user stories doivent être écrites par quelqu'un avec un « point de vue utilisateur » et non un point de vue technique. Ils doivent décrire les fonctionnalités et la valeur que l'équipe est censée offrir à l'utilisateur. Lorsque nous écrivons une user story, nous acquérons et partageons à la fois des connaissances.

Les témoignages d'utilisateurs sont importants

Aucun projet logiciel important ne sera livré dans les délais et dans les limites du budget s'il commence avec des exigences de qualité ou des témoignages d'utilisateurs médiocres. De plus, chaque mot de la user story compte. Des mots inappropriés peuvent conduire à des interprétations erronées, à des gaspillages et à des retouches.

Créer des histoires de haute qualité

Les merveilles de la langue anglaise nous offrent de nombreuses façons d’exprimer la même chose. Cette flexibilité conduit à un potentiel différences de compréhension. Lorsque deux lecteurs d’une user story peuvent parvenir à une compréhension différente de la signification des mots, nous avons un malentendu. Et un malentendu susceptible d'aboutir à un défaut du logiciel.

Quelle devrait être leur durée ?

Plus court est généralement mieux. Nous avons vu des histoires aussi petites que deux mots et autant qu'une page de texte. En général, un format plus court est préférable, mais veillez à ne pas manquer des fonctionnalités critiques. Nous recommandons 5 à 50 mots selon la complexité (à l'exclusion du de sorte que déclaration).

Qui écrit les histoires d'utilisateurs

Idéalement, l’auteur des user stories est un propriétaire de produit possédant une vaste expérience dans le rôle de client ou d’utilisateur final. Parfois, cela n'est pas pratique et l'auteur est un mandataire de l'utilisateur final, généralement un Business Analyst (BA). Le BA crée la première édition de l'histoire, qui est ensuite discutée et affinée par l'équipe. Une fois qu’il y aura une compréhension commune de ce que cela signifie réellement. Il peut ensuite être travaillé. Le défi consiste à parvenir rapidement à une compréhension claire et commune en quelques mots.

Des histoires d'utilisateurs de meilleure qualité éviteront les bugs.

De nombreuses équipes logicielles n'apprécient pas à quel point il est important de travailler à partir d'exigences de qualité ou de user stories. Généralement, 20% ou plus, tous les problèmes de qualité liés aux logiciels sont causés par des problèmes d'exigences.

Commencez par le "OMS, Quoi et pourquoi"

Le besoin fonctionnel et la justification commerciale sont les aspects les plus fondamentaux d’une bonne user story. Nous entendons par là « Qui doit faire quoi et pourquoi ». OMS est l'utilisateur (humain ou système connecté), quoi les données sont-elles manipulées et déplacées, et pourquoi est ce qui suit le « pour que » dans une user story. Concentrez-vous sur ceux-ci et évitez le comment (excluez les déclarations de conception).

De meilleures user stories réduiront les retouches

Pour toute équipe de développement, se lancer dans un sprint avec une user story médiocre peut être agile, mais ce n'est certainement pas lean. Cela vaut la peine de consacrer du temps à rendre les tories de vos utilisateurs aussi bonnes que possible, aussi claires que possible afin de minimiser les malentendus. Les malentendus entraîneront des remaniements coûteux.

Quelle est la différence entre les user stories et les cas d'utilisation

Nous avons déjà beaucoup parlé des user stories. UN cas d'utilisation est une liste d'actions ou d'étapes d'événement définissant généralement les interactions entre un rôle (appelé acteur) et le système. Histoires d'utilisateurs sont généralement un sous-ensemble d’un cas d’utilisation. Une user story décrit généralement une seule des interactions pouvant être décrites dans un cas d’utilisation.

Tests automatisés des user stories

La qualité des user stories a été mal servie par l’automatisation. En fait, avant la sortie de ScopeMaster®, nous ne connaissions aucun outil pouvant vous aider à améliorer la qualité de vos user stories. Il existe actuellement quelques produits sur le marché qui se rapprochent de certaines fonctionnalités de ScopeMaster, mais aucun n'offre une analyse automatisée aussi complète et précieuse des user stories pour l'assurance qualité, l'estimation et la génération de tests.

Bases fonctionnelles vs critères d'acceptation

N'oubliez pas que la description principale des fonctionnalités utilisateur précède les critères d'acceptation. Les critères d'acceptation sont une élaboration et dépendent d'un ensemble fonctionnel clair d'énoncés du point de vue de l'utilisateur.

Test des exigences en temps réel et suggestions d'amélioration

ScopeMaster effectue des analyses, des tests, des corrélations et des dimensionnements en temps réel à partir du texte des user stories. Les commentaires fournis par ScopeMaster vous aideront à améliorer la formulation que vous utilisez. Vous obtiendrez des exigences plus claires, plus concises, plus complètes et plus cohérentes. Concentrez-vous d'abord sur OMS et Quoi. ScopeMaster génère et exécute des tests statiques et dynamiques sur chaque user story, qui vous aideront à détecter et à vous avertir des problèmes potentiels. Il réalise un niveau de examen automatisé des exigences qui était jusqu'à présent indisponible dans l'industrie du logiciel.

Non seulement ScopeMaster® examine et analyse le langage de chaque user story, mais il croise également chaque story avec toutes les autres au sein d'un ensemble – il détecte les incohérences, les omissions et les doublons. Cela vous aide à affiner vos besoins beaucoup plus rapidement. L'interface intelligente de ScopeMaster identifie dynamiquement les histoires manquantes et facilite encore plus leur ajout.

Gérer des possibilités infinies

ScopeMaster surmonte la vaste gamme d'expressions possibles d'exigences en utilisant une forme d'intelligence artificielle connue sous le nom de traitement du langage naturel. Cela vous permet d’exprimer vos user stories en termes spécifiques à votre secteur d’activité ; l’outil ne nécessite aucune formation préalable.

Créez de meilleures user stories plus rapidement

ScopeMaster analyse les user stories (ou les exigences logicielles) pour trouver un langage approprié, adapté aux exigences logicielles et qui vous aidera à rédiger des histoires plus claires, concises, cohérentes, complètes et sans ambiguïté.

Détecte les défauts potentiels

INVEST – est une liste de contrôle couramment utilisée pour la qualité des user stories agiles.

• Indépendant *
• Négociable / Concis *
• Précieux
• Estimable *
• Taille *
• Testable *

*ScopeMaster aide l'auteur à trouver et à résoudre ces problèmes (plus de 50% de tous les défauts liés aux exigences).

Notre propre liste de contrôle préférée et plus complète pour rédiger de meilleures histoires d'utilisateurs est la suivante :

• Sans ambiguïté / clair *
• Mesurable / Fonctionnel *
• Concis *
• Orienté utilisateur *
• Testable *
• Cohérent *
• Entier et complet*
• Unique *
• Conception gratuite *
• Traçable à la valeur commerciale

ScopeMaster aide dans une certaine mesure avec 9 sur 10 de ces critères de qualité, et dans l'ensemble, il vous aidera trouver plus de 50% de défauts potentiels d'exigences, pré-codage.

Dans nos propres tests sur plus de 250 000 user stories recueillies auprès de plus de 100 sources, nous avons constaté que ScopeMaster expose 0,3 à 0,7 défauts par CFP (à l'exclusion des incohérences, que nous exposons mais ne pouvons pas calculer), alors que le taux typique observé dans l'industrie est d'un peu moins de 1 défaut par CFP. FP (Capers Jones). Voilà, des données réelles montrant que ScopeMaster peut vous aider à rédiger de meilleures user stories.

En utilisant ScopeMaster de manière interactive au début de votre projet pour améliorer vos user stories, vous pouvez placer votre travail logiciel sur une base de qualité plus solide dès le début – avant que la conception et le codage ne soient en cours. Vous pouvez continuer à affiner les histoires ou tout au long du processus de développement, dans le cadre de l'affinement de votre backlog produit. Ce qui est bien, c'est que vous aurez évité les retouches en commençant par une meilleure base d'écriture de user stories de meilleure qualité.

Apprenez à rédiger des user stories que les développeurs et les testeurs adoreront

Laissez ScopeMaster vous aider à rédiger des user stories que votre équipe trouvera faciles à créer. Ces histoires seront claires, suffisantes, cohérentes, complètes, importantes et testables. Tout le monde peut devenir auteur de superbes user stories.

Alexander Cowan Histoire d'utilisateur raffinée

Alexander propose des étapes pour obtenir une user story de bonne qualité, en proposant les étapes suivantes : une user story « raffinée ».

« En tant que responsable des ressources humaines, je souhaite créer un quiz de sélection afin de m'assurer que je suis prêt à l'utiliser lorsque j'entretiens des candidats. »

Nous avons effectué cela via ScopeMaster de manière isolée et il a instantanément détecté l'intention fonctionnelle principale et mesuré la taille en 4 points de fonction cosmique.

Une autre source utile pour le définition d'une user story.

Exemple de chèvre de montagne

Nous avons également analysé l'ensemble des 238 user stories publié par Mike Cohn

• Temps pris
  • 64 secondes
• Évaluation de la qualité:
  • 54% sans ambiguïté, dimensionné à 629 CFP
  • 46% ambigu
  • 233 omissions potentielles
  • 28 doublons potentiels
  • Plus de 20 incohérences
• Dimensionnement / Estimation
  • Estimation de la taille totale de 1161 CFP.