Welcome to Our Website

Comment écrire une bonne histoire utilisateur: avec des exemples et des modèles

lorsque vous commencez à plonger dans Agile, la première chose que vous remarquez est à quel point cette approche est centrée sur l’utilisateur. Il passe du simple codage et de la conception à la création de valeur réelle pour vos utilisateurs finaux, vos parties prenantes et votre entreprise en général.

Les user Stories agiles sont une composante essentielle de cette idéologie qui vous permet de définir les avantages que votre produit apportera à votre public cible (et, éventuellement, comment il améliorera vos KPI et autres métriques).,

User Stories aider à améliorer constamment la valeur de votre produit pour les utilisateurs finaux (image par Aleksandar Savic)

Nous à Stormotion Histoires d’amour. En tant qu’équipe Agile, nous les utilisons activement pour mieux comprendre les avantages que les produits de nos clients apportent à leurs utilisateurs finaux. Ils stimulent également la collaboration et la créativité, nous poussant vers des solutions de développement non triviales.,

aujourd’hui, nous allons partager nos connaissances et notre expérience à ce sujet pour vous aider à améliorer vos compétences en rédaction D’histoires. Amusez-vous bien!

🤔 qu’est Ce qu’un Utilisateur de l’Histoire?

Les user Stories sont l’un des éléments fondamentaux de la méthodologie Agile. Cependant, ils sont souvent brouillés avec les exigences logicielles qui ne sont pas vraies. Donc qu’est ce qu’un Utilisateur de l’Histoire?

User Story est un petit (en fait, le plus petit) travail qui représente une certaine valeur pour un utilisateur final et peut être livré pendant un sprint.,

l’objectif principal de cet élément est de placer les utilisateurs finaux au centre de la conversation et de capturer les fonctionnalités du produit de leur point de vue. Ainsi, les développeurs ont une meilleure compréhension de quoi, pour qui et pourquoi ils construisent.,

les User Stories aident à comprendre la valeur qu’un produit apporte à ses utilisateurs finaux (image par Duo)

Les Great User Stories correspondent toujours aux critères INVEST de Bill Wake:

  • indépendant – ils peuvent être développés dans n’importe quelle séquence et les modifications apportées à une histoire utilisateur n’affectent pas les autres.
  • négociable – c’est à l’équipe de décider comment les implémenter; il n’y a pas de flux de travail fixe.
  • Valuable-chaque User Story fournit une unité de valeur détachée aux utilisateurs finaux.,
  • Estimable-il est assez facile de deviner combien de temps le développement d’une histoire utilisateur prendra.
  • petit-il devrait passer par tout le cycle (conception, codage, test) au cours d’un sprint.
  • Testable – il devrait y avoir des critères d’acceptation clairs pour vérifier si un User Story est implémenté de manière appropriée.

le format de L’histoire utilisateur (qui est également utilisé par L’équipe Stormotion) est assez simple et court:

en tant que , je veux que

ne ressemble à rien de difficile, hein?, Voici quelques exemples D’histoires D’utilisateurs qui correspondent à un projet d’application de taxi inventé:

  • En tant que conducteur, je veux bloquer les passagers mal comportés afin qu’ils ne me soient plus jamais montrés.
  • En tant que passager, je souhaite lier la carte de crédit à mon profil afin de pouvoir payer un trajet plus rapidement, plus facilement et sans espèces.
  • En tant que conducteur, je souhaite ajouter des photos de ma voiture dans mon profil afin d’attirer plus d’utilisateurs.
  • En tant que passager, je veux que plusieurs pilotes disponibles soient affichés afin que je puisse choisir l’option la plus appropriée pour moi.,

semble assez facile, mais le développement de L’Histoire de l’utilisateur n’est pas souvent aussi simple. Pourtant, plus tard, nous partagerons certains de nos conseils éprouvés qui vous aideront à faire que de bons coups.

quelques exemples d’articles de l’Utilisateur pour les sites web (image par Philipp Kühn)

Est-il autre chose?

bien que nous venions de comprendre que les User Stories agiles sont indépendantes et doivent être comprises comme des unités de travail totalement séparées, elles sont parfois regroupées., Donc, lorsque l’on travaille avec eux, vous êtes susceptible de rencontrer et d’utiliser le concept d’une Épopée. Qu’est-ce que c’est?

Une épopée est un corpus de travail de haut niveau qui s’associe à un groupe d’histoires connexes.

chez Stormotion, nous utilisons Epics pour décrire des tâches plus complexes et créer une hiérarchie claire qui permet de gérer le développement plus facilement et de fournir une nouvelle valeur aux utilisateurs tout en travaillant vers un objectif plus grand. Pourtant, le format de L’Histoire de l’Utilisateur lui-même reste le même.,

peut être implémenté pendant quelques sprints représente une valeur que l’utilisateur obtiendra après l’implémentation indique une tâche plus générale (par exemple, l’implémentation d’un utilisateur entier- assez facile à estimer plus difficile à estimer car la portée est flexible

imaginez que vous construisez une application de rencontres., génial je suis

une histoire: en tant qu’administrateur, je veux supprimer/bloquer des photos des profils des utilisateurs afin qu’ils n’effrayent pas les autres avec leurs photos nues (ou ne violent pas les règles de la communauté)

une histoire: en tant qu’utilisateur d’application, je veux avoir un champ séparé où mon penthouse dans le centre de New York

ainsi, les épopées nous fournissent une vue de haut niveau de nos objectifs et de la façon dont nous les atteignons., Cela nous aide également pendant le processus de priorisation car nous pouvons vérifier quelles épopées nécessitent le plus notre attention et, par conséquent, quelles histoires doivent être mises en œuvre en premier.

Lire Aussicomment prioriser le développement de fonctionnalités

Oh, encore une chose!

N’oubliez pas d’ajouter un critère d’acceptation.

Un des critères d’acceptation est un ensemble de conditions qui sont utilisés pour confirmer lorsqu’une Histoire est terminée.,

chaque histoire doit avoir des critères d’acceptation clairs (image Par Hai Peng)

également, ces Conditions nous fournissent une compréhension plus profonde et meilleure car elles incluent des informations clés sur la façon dont les histoires fonctionnent. Réutilisons l’un des exemples de L’histoire utilisateur du début de l’article:

en tant que passager, je veux que plusieurs pilotes disponibles soient affichés afin que je puisse choisir l’option la plus appropriée pour moi.,

quels critères d’acceptation peuvent être appliqués à cette histoire?

  • l’application montre les conducteurs qui étaient en ligne dans les 20 dernières minutes et n’ont pas de trajet en cours.
  • L’application montre seulement 5 pilotes qui sont plus proche de l’utilisateur.
  • Un utilisateur peut parcourir les profils de ces pilotes, y compris leurs photos et leurs tarifs.

comme vous pouvez le voir, nous connaissons maintenant non seulement la valeur de cette histoire pour les utilisateurs, mais nous comprenons également certaines caractéristiques clés qui nécessitent une attention particulière lors de la mise en œuvre.,

cependant, vous êtes libre de choisir dans quelle mesure vos critères d’acceptation seront détaillés. Cela peut aller de « laissez-le fonctionner de toute manière pratique » à des ensembles de conditions encore plus détaillés que dans l’exemple ci-dessus.

cela dépend grandement de votre équipe de développement, il n’y a donc pas de « bonne réponse ». Si votre équipe a besoin de conseils et de tâches claires et sans place pour l’interprétation, Vous feriez mieux de vous en tenir à des instructions détaillées sur la façon dont les histoires doivent fonctionner. Sinon, l’approche « Just get it done » peut également fonctionner.,

Lire Aussicomment évaluer votre idée de démarrage

Wow, on en a beaucoup parlé sur les User Stories. Mais pourquoi sont-ils si importants pour les équipes Agiles?

What Quels sont les avantages de créer des user Stories?

Si vous avez déjà travaillé avec des frameworks agiles, vous savez déjà que les équipes Scrum et Kanban bénéficient grandement de la rédaction D’User Stories.,

les User Stories offrent des avantages à toutes sortes d’équipes agiles (image par Andrew McKay)

dans Kanban, les équipes accumulent des Stories dans un Backlog, puis les exécutent une par une pour flux de travaux en cours. Cela permet de rester constamment sur la bonne voie et d’améliorer les KPI de l’équipe de développement.

Les équipes Scrum (que nous préférons habituellement chez Stormotion) aiment aussi les User Stories. Nous les utilisons activement pour faire des estimations, établir des priorités et planifier des sprints, ce qui nous aide à rester agiles et flexibles à tout changement., Ceci est particulièrement bénéfique lorsque nous travaillons avec des Startups qui sont au stade MVP et qui ont des ressources limitées avant de présenter leur projet à des investisseurs providentiels.

les Stories sont également activement utilisées par les équipes Kanban (image de Tahir Yousaf)

à L’exception de ce qui précède, il existe des avantages évidents communs à toutes les équipes agiles:

  • gardez-vous concentré sur la valeur de l’entreprise., Cela aide à rendre votre application non seulement bien construite du point de vue technique, mais également utile pour les utilisateurs finaux.
  • Permettre à la créativité. Comme il contient un minimum d’Informations, votre équipe est libre de conduire des idées créatives pour trouver la meilleure solution pour mettre en œuvre une histoire.
  • votre projet devient plus gérable. Chez Stormotion, nous savons qu’il est plus facile de travailler avec de petites histoires D’utilisateurs agiles et estimables plutôt qu’avec de grandes tâches complexes.
  • Ils inspirent l’équipe! Chaque développeur aime cette douce sensation d’une petite victoire qui le motive à travailler encore plus dur.,

plongeons maintenant dans le processus de création d’une histoire utilisateur!

Lire Aussidécouverte de projet: quoi et pourquoi?

📝 Comment Écrire des Histoires d’Utilisateur: Notre Flux de travail

Nous arrivons à la partie la plus excitante de notre article. Cependant, avant de partager nos instructions étape par étape sur la rédaction d’une histoire D’utilisateur, il est crucial de comprendre 2 questions essentielles: qui et quand les fait.

Qui est responsable de la création d’un Utilisateur de l’Histoire?,

en règle générale, les histoires sont principalement écrites par les propriétaires de produits car il est de leur responsabilité de garder le carnet de commandes rempli de tâches. Pourtant, N’oubliez pas Qu’Agile est basé sur la communication et l’échange d’opinions entre experts. Si…

Cela ne signifie pas nécessairement qu’ils doivent être écrit que par un Produit Propriétaire. Plus les gens se joignent à la conversation, mieux c’est.

chez Stormotion, les histoires sont écrites par tous les membres de l’équipe qui sont liés au côté métier du projet (directeurs des ventes, marketeurs, un product owner, etc.,), car il nous permet de regarder la future application du point de vue de tout type d’utilisateur potentiel. La responsabilité du Product Owner dans ce cas est de confirmer qu’ils correspondent aux critères D’investissement.

les Histoires sont créés grâce à la collaboration (image de Dmitrii Kharchenko)

Quand l’Utilisateur créé des Histoires?

Une réunion de rédaction D’histoires dans notre QG se tient généralement près du début du projet., Nous préférons nous équiper pour nous assurer qu’un projet se passe bien du premier au dernier jour.

plus tard, nous pourrons utiliser notre liste D’utilisateurs Scrum pour préparer des estimations plus détaillées (par exemple, à la fin de la phase de découverte), prioriser le développement de fonctionnalités pour les sprints, etc.

Lire Aussicomment Estimer avec précision le temps de développement logiciel?

de plus, nous complétons la liste originale lorsque nous travaillons sur un projet avec de nouvelles histoires pour rester à jour avec les exigences de nos clients.,

quelles sont les étapes pour écrire de superbes User Stories agiles?

tout d’Abord, permettez-nous de vous rappeler qu’un Utilisateur ordinaire des Histoires modèle:

Comme , je veux donc qu’

Semble court et facile à écrire. Au fait, vous pouvez créer votre propre modèle D’histoire utilisateur. Cependant, chez Stormotion, nous avons un flux de travail spécifique qui nous aide à livrer les meilleures histoires:

  1. Composez la liste de vos utilisateurs finaux. Définir ce qu’est leur « douleur” ou de « besoin”, que vous essayez de résoudre.
  2. définissez les actions qu’ils peuvent vouloir prendre.,
  3. découvrez quelle valeur cela apportera aux utilisateurs et, éventuellement, à votre produit. Demandez-vous aussi-est-ce qu’une partie nous paiera pour cela?
  4. discuter des critères d’acceptation et d’une stratégie de mise en œuvre optimale.

nous allons regarder par-dessus maintenant!

Étape 1: Penser le « Qui”

C’est la première et peut-être le plus fondamental de l’étape. Avant d’écrire une histoire D’utilisateur, vous devez réellement savoir qui sont les utilisateurs finaux de votre produit. Et plus important encore-quels besoins ils ont, que vous essayez de couvrir.,

lors de nos ateliers D’écriture D’histoires, nous essayons d’omettre d’utiliser un rôle comme simplement « l’utilisateur”. Il peut être appliqué à n’importe quelle personne – de vos clients aux administrateurs – et, par conséquent, il ne reflète pas la personnalité de groupes cibles particuliers, la façon dont ils interagissent avec l’application.

Il est important de définir correctement votre utilisateur persona (image par Grzegorz Oksiuta)

Si vous voulez obtenir des résultats de très bonne qualité vous pouvez plonger votre auditoire encore plus., Au lieu de simplement nommer les utilisateurs après leur rôle (par exemple, « un pilote”), essayez de créer une sorte de personnage d’acheteur.

Voici quelques conseils supplémentaires à partir de notre propre expérience:

  • Il est tout au sujet de l’utilisateur. Pas sur les développeurs. Et même pas à propos d’un propriétaire de produit. Chaque histoire devrait être précieuse pour un groupe de vos utilisateurs finaux.
  • ne considérez pas les utilisateurs uniquement comme des clients externes. Il est vrai que vos histoires seront principalement à leur sujet. Mais il est également vrai que vous devez considérer les utilisateurs internes tels que les administrateurs, les éditeurs, etc.
  • Ressentir une certaine empathie. Donnez à votre « user” un nom de., Pensez à ses habitudes mobiles, quel problème votre application va être résolu pour lui et comment vous allez rendre ce chemin plus facile et plus rapide. Rappelez-vous certaines personnes que vous connaissez dans la vie réelle et qui correspondent à ce portrait; sentez comment vous vous rapportez à ce groupe cible.

Étape 2: Penser le « Quoi”

Maintenant, nous avons quelques groupes d’utilisateurs finaux. La prochaine étape consiste à définir les fonctionnalités attendues par chaque utilisateur, comment il va interagir avec l’application.,

Ensuite, vous devez découvrir comment les utilisateurs interagissent avec votre produit (image par Johny vino™)

telles sont les principales règles à retenir lors de l’écriture d’une action pour un Kanban ou Scrum User Story:

  • Une action par une Histoire. Si vous voulez écrire quelque chose comme « en tant que client, je veux parcourir les articles et les ajouter au panier”, vous feriez mieux de le diviser en 2 Histoires.
  • Décrire une intention, pas une fonction., Par exemple, au lieu de « je veux gérer mon profil”, créez quelques Histoires comme « je veux être en mesure de s’inscrire”, « je veux charger ma photo de profil”, « je veux le lien de ma carte de crédit à mon profil” – chaque Histoire aura une valeur différente.
  • le Garder court. Les utilisateurs ne se soucient pas de la bibliothèque que vous utiliserez pour les laisser parcourir la liste des éléments, alors laissez tous les détails techniques de côté.
  • évitez de décrire L’interface utilisateur. Nous avons défini les histoires comme négociables, vous vous souvenez? C’est pourquoi tous les bons exemples D’histoire utilisateur n’incluent aucun détail D’interface utilisateur., N’essayez donc pas de composer une façon spéciale de les implémenter (nous le ferons plus tard).

Étape 3: pensez au « pourquoi”

enfin, le dernier morceau de notre modèle User Stories est dédié à une valeur que les utilisateurs obtiennent après avoir effectué une action. Cela peut sembler pas un gros problème, mais c’est souvent la partie la plus délicate du développement de L’Histoire de l’utilisateur.,

faites attention à la façon dont les utilisateurs interagissent avec votre application (image par Andrew McKay)

cependant, votre section doit toujours correspondre à vos métriques et KPI. Il devrait soit améliorer L’UX, augmenter les taux de rétention, raccourcir le parcours des utilisateurs vers la solution du problème ou autre. Chaque histoire devrait contribuer à l’objectif général de votre produit.,

Si vous ne pouvez pas répondre à la valeur que cette fonctionnalité apporte aux utilisateurs finaux et à votre produit, alors vous faites quelque chose de mal.

Par exemple, il existe quelques exemples D’histoires D’utilisateurs avec une valeur bien écrite pour notre projet d’application de commande de nourriture en cours:

  • En tant que client, je veux recevoir des notifications lorsqu’il y a de nouvelles offres chaudes afin de ne jamais manquer les meilleures offres. .
  • En tant que directeur de restaurant, je veux compléter la description du plat dans le menu avec une photo afin qu’elle soit plus attrayante pour les clients. .,

Étape 4: discuter d’une histoire

enfin, nous discutons toujours des histoires D’utilisateurs après leur création. Même si il semble ne ressemble à rien d’en parler.

ne sous-estimez pas L’importance de la séance de brainstorming (image de Monika Pola)

pendant cette Q& une session, nous demandons à l’auteur de l’histoire de fournir plus de détails ou de clarifier quelque chose si nécessaire. Cela nous aide à comprendre comment cela devrait fonctionner et à nous mettre d’accord sur les critères d’acceptation., De cette façon, nous examinons tous les exemples d’histoires d’utilisateurs d’applications mobiles un par un.

ensuite, nous organisons une séance de brainstorming avec toute l’équipe travaillant sur le projet. Cela nous permet de trouver les meilleures façons de mettre en œuvre des histoires D’utilisateurs du point de vue de la technologie.

Lire Aussicomment choisir une agence pour le développement de votre application?

voilà comment écrire des histoires D’utilisateurs en un mot. Notre équipe Stormotion utilise également les conseils suivants lorsque vous travaillez sur cette tâche:

  • commencez par Epics., Il est généralement plus facile de passer de tâches plus complexes à des tâches plus spécifiques, alors essayez d’écrire des épopées, puis de les diviser en histoires.
  • Écouter les commentaires. Parfois, vous n’avez pas besoin de deviner des histoires – demandez à vos vrais utilisateurs finaux des commentaires et utilisez leurs idées comme source d’inspiration.
  • n’introduisez pas les détails trop tôt. Il est préférable de tenir la session de brainstorming avant chaque sprint pour discuter de la mise en œuvre des histoires planifiées.

💡 Conclusion

l’Utilisateur Histoires sont un élément essentiel de l’approche Agile qui peut apporter de nombreux avantages à votre projet., Cependant, il est important de les écrire correctement, ce qui nécessite du temps et des compétences.,T critères, ce qui signifie qu’ils sont:

  • indépendant
  • négociable
  • précieux
  • Estimable
  • petit
  • Testable

le modèle common User Stories inclut l’utilisateur, l’action et la valeur (ou l’avantage) et ressemble généralement à ceci:

, je veux que

Les user stories puissent vous aider à améliorer constamment la valeur de votre produit, à estimer les efforts de développement de manière appropriée et à prioriser le développement de fonctionnalités pendant les étapes MVP et post-MVP.,

citation
Stimuler le Développement de Vos applications Avec Nous!
{« valeur »:, »count »:, »de »: »2018-07-20″}

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *