Dix attributs de qualité pour de meilleures user stories

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.

Exigences et témoignages d'utilisateurs : quelle est la différence

Les exigences logicielles sont plus une hiérarchie qu’un concept unique. Les exigences logicielles commencent par les résultats commerciaux (ou objectifs commerciaux), qui peuvent être décomposés en capacités (également parfois appelées exigences logicielles commerciales, Epics ou ensembles de fonctionnalités, qui peuvent être considérés comme ce qui doit être fourni pour fournir de la valeur commerciale). Celles-ci peuvent à leur tour être décomposées en user stories plus granulaires (ou exigences fonctionnelles des utilisateurs). Enfin les user stories peuvent être décomposées en tâches techniques. Un bon ensemble d’exigences logicielles nécessite TOUS ces éléments (à l’exception des tâches techniques).

Autres

Exigences non fonctionnelles (NFR),

Pour atteindre les résultats commerciaux énoncés, certains NFR seront probablement également importants. Il existe des dizaines de types de NFR, ceux-ci sont souvent appelés les fonctionnalités d'une solution logicielle. Curieusement, le « NFR » le plus souvent cité est celui de la sécurité, alors que les fonctionnalités de sécurité sont généralement fonctionnelles. Les NFR sont particulièrement difficiles à dimensionner.

Critères d'acceptation

Les critères d’acceptation sont une qualification détaillée de la user story OU du NFR. Ils définissent ce qui est acceptable et inacceptable de manière plus détaillée qu’une user story typique. La user story se situe généralement au niveau de l'objet tandis que les critères d'acceptation définissent souvent les limites au niveau des attributs.

Contraintes

Celles-ci ne sont pas toujours articulées comme telles sur un projet logiciel. Parfois, ils sont mal intégrés dans une user story. Elles peuvent être considérées comme des contraintes de projet et déterminent souvent la manière dont le logiciel peut être livré, et non ce qui est livré.

Les témoignages d'utilisateurs sont importants

Aucun projet logiciel substantiel ne sera livré dans les délais et dans les limites du budget s'il omet de produire un ensemble d'exigences fonctionnelles des utilisateurs ou de user stories. Et ceux-ci doivent être de haute qualité (nous en reparlerons plus tard). De plus, chaque mot de la user story compte.

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.

Source des défauts

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.

Résultats des tests de qualité des histoires d'utilisateurs

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é.

Communiquer

Une user story est avant tout un moyen de communiquer. Il doit transférer des connaissances sur tout ou partie des éléments suivants : le besoin, l'exigence, la fonctionnalité, le résultat, le but de l'exigence. S’il ne parvient pas à fournir une intention claire, cela entraînera une mauvaise interprétation qui peut à son tour conduire à des bugs.

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.

Centré sur les tâches de l'utilisateur

Les user stories ou les exigences axées sur ce que l'utilisateur doit faire du système pour accomplir une tâche seront plus utiles qu'une liste de fonctionnalités.

Art ou Science

L'art est subjectif alors que la science est objective, l'art exprime la connaissance. L’application de la science dans des scénarios du monde réel est généralement considérée comme relevant de l’ingénierie.

Lorsque nous écrivons une user story, nous acquérons et partageons à la fois des connaissances.

D'une part, la user story est une acquisition de connaissances auprès du client/utilisateur/propriétaire du produit et d'autre part, elle est également une expression de connaissances que l'équipe doit comprendre et sur laquelle travailler.

La mesure est commune à la science et à l’ingénierie, alors qu’elle est presque toujours absente des œuvres d’art.