Votre meilleure histoire d'utilisateur agile

Votre meilleure histoire d'utilisateur agile

Vues:
111 098

Vues:
111 098

Cet article vous montrera comment créer de meilleures user stories. Vous apprendrez à les écrire comme un designer, à les tester comme un entrepreneur et à les utiliser pour mener de meilleures discussions comme un coach agile.

Créer une user story

Qu'est-ce qu'une histoire d'utilisateur?

Les user stories ont un format spécifique:

"Comme un [persona],Je veux [do something] afin que je puisse [realize a reward]”

Ce format est conçu pour aider l'auteur de l'histoire à être descriptif et à mener de meilleures discussions sur la mise en œuvre avec le reste de son équipe. Si le format est correct, le format aide à poser les questions importantes suivantes: Si répondre à ces questions vous semble demander beaucoup de travail, je mentionnerai ici que le point sur le taux d'échec des nouveaux produits, des échecs de projets informatiques et de la part des fonctionnalités qui sont réellement substantielles Utilisé, quelque chose de l'ordre de la plupart ou du moins «beaucoup» de logiciels finit par être légèrement utilisé ou rapidement mis au rebut. Une utilisation habile des histoires améliorera vos résultats, vos données économiques et, surtout, le sentiment de votre équipe que le travail qu’elle accomplit compte pour l’utilisateur.

Si vous écrivez une histoire, votre travail consiste à remplir les blancs (en rouge). Le personnage est une description vivante, humanisée et pourtant opérationnelle de votre utilisateur (voir aussi le tutoriel sur les personas). Le '[do something]’Est un objectif que vous supposez que l’utilisateur a. Le '[realize a reward]La clause ’est une déclaration testable expliquant comment vous saurez si l’utilisateur a atteint cet objectif. le [realize a reward] Cette clause est la plus négligée par la plupart des rédacteurs d’histoires et pourtant c’est la plus importante. Le meilleur test décisif pour savoir si vous avez une bonne histoire est de savoir si vous pouvez mettre un prototype simple devant un utilisateur, lui demander d’agir en fonction de l’objectif que vous vous fixez et de voir s’il peut l’atteindre.

Examinons un exemple spécifique pour voir comment cela fonctionnerait dans la pratique. Enable Quiz est une société fictive que j'utilise dans beaucoup de mes exemples. Ils construisent (de manière fictive) une application permettant à un responsable des ressources humaines de sélectionner des candidats pour des compétences techniques spécifiques par rapport à une description de poste. Nous pourrions décrire l'objectif de la création d'un questionnaire pour la sélection d'une nouvelle description de poste ouverte avec cette histoire:

"En tant que responsable des ressources humaines, je souhaite faire correspondre les compétences requises d'un poste ouvert à des sujets de quiz afin de pouvoir créer un quiz pertinent pour la sélection des candidats."

Avec cette histoire, un concepteur ou développeur (ou une personne agissant dans ce rôle) pourrait placer un exemple de description de travail devant un directeur des ressources humaines, leur donner pour objectif de sélectionner des sujets de questionnaire et de voir s'ils sont en mesure de s'en rendre compte. objectif avec le prototype actuel de l’équipe ou le logiciel en fonctionnement.

Il y a des écoles de pensée que le format de l'histoire spécifique ou la troisième clause [realize a reward] n'est pas si important. Cela ne correspond tout simplement pas à mon expérience. Chaque fois que je discute avec une équipe peu habituée au format d’histoire, je vois des données qui indiquent qu’elles tireraient avantage d’une valeur ajoutée initiale et d’une définition plus précise des objectifs de l’utilisateur, de manière à ce qu’elles puissent accéder à quelque chose de précieux et éviter le gaspillage.

Astuce: Il existe une tendance à vouloir construire un logiciel «pas particulièrement faux» plutôt que spécifiquement correct ou particulièrement faux. Résiste. Les équipes qui réussissent forment de petites séries en observant avec soin si elles ont raison ou non, mais elles reposent sur des hypothèses bien définies concernant les objectifs de l’utilisateur.

Comment organisez-vous des histoires?

Les récits épiques décrivent une action de l'utilisateur et les récits d'enfants détaillent cette action. Les cas de test et les notes sont un endroit où ajouter des détails supplémentaires et des points à discuter par rapport à des histoires individuelles. Les deux types d'histoires ont le même format, le format que vous avez vu ci-dessus.

Il ya une école de pensée qui dit que les épopées sont vraiment grandes et qu’elles sonnent certainement très bien. Mon conseil général est de les garder relativement petits. Je fais beaucoup de formation sur les ateliers d'écriture d'histoires et 95% des histoires pour la première fois que je vois sont en fait ce que je commencerais par des épopées (et les ébauches d'épopées ont une portée trop large). Pourquoi? Bien, développer et utiliser un logiciel coûte cher. Vous pourriez aussi bien avoir une bonne couverture narrative avec des histoires sur tout ce que vous construisez pour mener de meilleures discussions sur ce qui sera précieux pour l'utilisateur et comment vous allez le tester. L'alternative consiste à deviner et je peux vous dire comment cela fonctionne – pas bien.

Regardons un exemple spécifique. Pour revenir au récit d’un responsable des ressources humaines qui souhaite créer un questionnaire de sélection pour une nouvelle description de poste, nous pourrions commencer par cette épopée:

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

Les histoires pour enfants et leurs scénarios de test les décomposent en étapes plus détaillées (voir la référence A pour un exemple complet). Soit dit en passant, si vous avez envie de commencer à rédiger, n'hésitez pas. Voici un modèle de Google Doc qui pourrait vous être utile: Modèle d’histoire d’utilisateur.

Les user stories sont un type de spécification, non?

NON! Ils sont censés servir de pièce maîtresse à de fréquentes discussions interdisciplinaires sur la manière de mettre en œuvre quelque chose de précieux pour l'utilisateur. C’est un peu là où l’utilisation d’histoires et la pratique agile doivent converger. Si vous n'êtes pas familier avec l'agile, je recommande le lien susmentionné ou, hé, mon parcours agile, mais l'idée de base est qu'au lieu de travailler de manière séquentielle (en cascade), de la spécification au développement, en passant par le test, vous êtes en train de le faire. toutes ces choses ensemble en petits lots. Dans la section suivante, nous expliquerons comment créer des histoires comme un concepteur, mais je terminerai par quelques notes de mise en garde sur les points à surveiller avec vos histoires d'utilisateurs.

Pourquoi la plupart des histoires d'utilisateurs sont-elles si mauvaises?

  • Croyance erronée que le logiciel est automatiquement MagicJe sais que ça a l'air ridicule, mais vous travaillez probablement avec des personnes qui le pensent implicitement jusqu'à un certain point. C’est vrai, il se passe des choses incroyables avec les logiciels. Mais ce logiciel n’était pas automatiquement magique; il fallait que quelqu'un y mette de la magie. Ce quelqu'un c'est toi. La prochaine section vous montrera comment conjurer cette magie.
  • Nous mesurons localement notre efficacité À un certain degré, nous voulons tous finir notre travail et aller voir Netflix. C'est très bien. C'est naturel. Toutefois, si vous souhaitez créer un logiciel de qualité, vous devez constamment poser les questions difficiles de vos collègues et de votre travail pour savoir si ce que vous faites a toujours un sens. Existe-t-il un cas solide et testable qui sera précieux pour l’utilisateur? C’est difficile à faire régulièrement. Un grand nombre de responsables de produits ajoutent simplement des histoires d'utilisateurs à JIRA et appellent cela une journée. Ce n’est pas si difficile de gérer un programme plus réfléchi et plus discipliné, mais ce n’est pas si facile non plus. Vous devez vraiment le vouloir.
  • Pas de donnéesVous devez connaître votre utilisateur et son contenu pour écrire de bonnes histoires d'utilisateurs. Sans cela, vous allez simplement chercher une idée de ce que le logiciel peut faire et ensuite dépenser beaucoup plus d’argent que nécessaire pour déterminer si vous avez raison ou non. Il existe un moyen plus simple (et beaucoup moins cher), et c’est le sujet de cette section.
  • Savoir si vous avez une histoire

    De qui parle-t-on?

    Rappelez-vous quand votre professeur d’anglais au lycée vous a dit de "écrire ce que vous savez?". C’était toujours difficile pour moi au lycée parce que, en réalité, je ne savais pas grand-chose. De même, si vous ne connaissez pas votre utilisateur, il sera difficile d’écrire de bonnes histoires. Cela ne signifie pas pour autant que ce que vous écrivez importe maintenant. Vous êtes sur le point de définir beaucoup de dépenses pour la création et l’exploitation de logiciels.

    L’alternative est d’aboutir à l’un de ces deux anti-pôles d’échec de conception:

    Faites précisément ce que demande l'utilisateur et vous aboutirez probablement à ce que mon ami David Bland appelle le "cycle de la mort du produit": a) personne n'utilise le produit b) vous demandez aux clients quelles fonctionnalités manquent c) vous créez ces "manquants" 'caractéristiques d) revenir à' a '. Supposons que vous avez déjà toutes les réponses et que vous aurez probablement une taille de marché proche de une (vous et peut-être quelques personnes comme vous).

    Qu'est-ce qu'un produit consciencieux à faire? La bonne nouvelle est qu’il existe une approche qui fonctionne de manière constante. La mauvaise nouvelle (c’est pas vraiment mauvais;)) est qu’il faut un travail d’un genre qui pourrait être nouveau pour vous. L’outil avec lequel je commencerais est l’idée de «personas». Il s’agit de vues humanisées de votre client, qu’il s’agisse d’acheteur ou de utilisateur de votre produit. Il s’avère que c’est le moyen le plus efficace et le plus testable de créer des produits et des systèmes.

    L’idée de base est que vous souhaitiez nommer la personne qui les humanise («Helen, la responsable des ressources humaines») et avoir une idée de la vie qui les attend. Quelles chaussures portent-ils? Quelle est la première chose qu’ils font le matin? Ensuite, vous voulez creuser dans la façon dont ils se rapportent à votre produit ou système. Que pensent-ils de la façon dont les choses fonctionnent maintenant et comment ils voudraient qu’ils soient? Que voient-ils que les autres font qui influencent cette perspective? Que ressentent-ils à propos du travail ou des habitudes que vous développez pour améliorer les logiciels? Que font-ils réellement dans votre domaine d'intérêt? Combien? À quelle fréquence?

    Vous constaterez probablement que vous devez sortir et parler à quelques-uns d'entre eux pour obtenir ces informations, mais si vous comprenez fort bien votre utilisateur de Think-See-Feel-Do, vous constaterez que les histoires sont nombreuses. plus facile à écrire et à discuter.

    Pour plus de détails et quelques exemples, voir: Tutoriel Personas.

    Pour savoir comment interroger les utilisateurs pour créer des personas, voir: Manuel de découverte de la clientèle (Hypothèse de Persona).

    Pour une visite structurée de ces éléments, voir Agile Meets Design Thinking sur Coursera et la section Personas de Running Design Sprints.

    Que veulent-ils?

    Une fois que nous avons un personnage fort, nous devons examiner et tester quels emplois ou désirs sous-jacents nous allons améliorer pour cet utilisateur. Est-ce qu'ils existent vraiment? Sont-ils importants? Cela vaut la peine d’explorer cela, car si vous résolvez un problème qui n’existe pas, vous pouvez développer un logiciel parfait sans toujours fournir aucune valeur à l’utilisateur.

    Comment identifiez-vous et décrivez-vous ces scénarios de problèmes? Tout d’abord, considérez simplement ce que vous faites réellement pour l’utilisateur: l’aider à rester en contact avec ses amis? vérifier leurs comptes fournisseurs pour des modèles suspects? Assurez-vous ensuite de pouvoir décrire une alternative (idéalement, vous avez parlé à des utilisateurs et vous le connaissez déjà). Peut-être que votre utilisateur envoie une carte de vacances pour rester en contact avec ses amis. Peut-être se contentent-ils de regarder les gros comptes fournisseurs et de les vérifier / vérifier. Assurez-vous que votre définition du scénario du problème est générale et pourrait s’appliquer aussi bien à l’alternative actuelle qu’à ce que vous envisagez de faire pour améliorer les choses. Cela vous aidera à éviter les préjugés et à rester concentré.

    Regardons un exemple spécifique. Pour le questionnaire d'activation (voir ci-dessus), leur scénario de problème principal peut être:

    «Sélection des talents techniques».

    J'ai dit qu'un bon scénario de problème peut être appliqué aussi bien à l'alternative qu'à votre nouvelle proposition. Helen, la responsable des ressources humaines, pourrait choisir parmi les solutions suivantes: vérifier les curriculum vitae, appeler des références ou tout simplement se fier à leurs paroles. Je dirais que la définition du scénario du problème fonctionne également pour ces alternatives.

    Et si nous prenions le scénario du problème et montions d'un niveau d'abstraction? Ensuite, cela pourrait être quelque chose comme «Recruter du talent technique». Maintenant, c'est probablement trop large, mais il est utile de le savoir de sorte que a) vous sachiez que vous aviez atteint le niveau d'abstraction approprié avec votre scénario de problème principal et b) que vous 'ont identifié le domaine général dans lequel vous travaillez.

    Et si on descendait d'un niveau? Ensuite, nous aurons probablement beaucoup plus de scénarios de problèmes tactiques comme:

    «Le responsable des ressources humaines prépare un nouveau questionnaire à partir d’une description de poste ouverte.»

    "Le responsable des ressources humaines envoie des notes sur les candidats au responsable fonctionnel."

    Celles-ci découlent toutes du scénario du problème principal du filtrage, mais nous souhaitons tout de même nous assurer de leur importance avant de commencer à écrire des articles et d’envisager d’investir dans des logiciels. Un résumé des premiers scénarios de problèmes pour Enable Quiz pourrait ressembler à ceci:

    Lorsque vous travaillez en avant pour développer votre compréhension, la séquence va comme ceci:

    Voici un exemple de ce à quoi cela pourrait ressembler dans le cas d’Activer le questionnaire:

    Maintenant, vous remarquerez peut-être la note sur «Pourquoi? (Motivation) ’- Je recommande également de vérifier si le client préfère vos solutions à un scénario problématique par rapport à leurs alternatives actuelles. Cependant, je ne veux pas m'éloigner trop du sujet. Si l’ensemble du processus vous intéresse, consultez la page Venture Design.

    Pour des tutoriels, des modèles et des cours en ligne, reportez-vous à la fin de la section ci-dessus sur Personas.

    Concevoir de meilleures histoires d'utilisateurs

    Quel est le bon niveau de détail?

    Une fois que vous avez suffisamment appris sur votre utilisateur pour savoir que vous devez vraiment créer un logiciel, il est temps de passer en revue certaines histoires. Qu'est-ce que vous voulez faire pour améliorer leur vie? Comment saurez-vous si vous avez fait cela?

    Vos user stories doivent être détaillées et testables. Pourquoi? Eh bien, c’est vous qui décidez vraiment quelle quantité de logiciels / systèmes que vous allez investir dans la construction sera étayée par des idées soigneusement étudiées sur ce qui est précieux pour l’utilisateur. D'après les statistiques que j'ai citées à l'introduction. (Quelque chose comme à peu près la moitié des logiciels aboutit à un échec), je dirais que de nombreuses équipes ont des chances d’être améliorées. C’est facile à dire, mais difficile à faire. Je sais que je travaille toujours pour faire mieux. Jetons un coup d’œil à quelques exemples spécifiques.

    Si vous n’avez jamais écrit une histoire auparavant, vous commencerez probablement par quelque chose de trop large. Pour Enable Quiz, cela pourrait ressembler à ceci: "Je souhaite sélectionner correctement les candidats ingénieurs afin que mon entreprise obtienne les meilleurs résultats possibles en matière de recrutement". Vous pouvez vous en servir comme point de départ pour vos prochains articles, mais cette action n'est pas immédiatement exploitable pour la conception. ou codage. De plus, si vous ne travaillez qu'avec une couche supplémentaire d'abstraction dans vos histoires (histoires d'enfants sous une épopée), je pense que vous allez vous retrouver avec des histoires trop vagues et un environnement de travail qui n'est pas bien géré. par récit. L’histoire ci-dessus est vraiment analogue au scénario-problème dont nous avons parlé dans la dernière section: «Sélection des talents techniques». Pour les histoires, je commencerais par des détails plus exploitables (et les lier à des scénarios de problèmes si vous voulez vous assurer qu'ils sont bien pris en charge par la découverte de clients).

    Voici une histoire plus précise: «Je souhaite sélectionner facilement un candidat en ingénierie afin de connaître son profil de compétences». Cette histoire présente quelques problèmes. Allons le resserrer! Premièrement, il manque la première clause identifiant le personnage. C’est un problème, car au moins deux personnalités distinctes sont impliquées: Helen (ou Hank), la directrice des ressources humaines, et Frank (ou Francine), la responsable fonctionnelle. Nous devons savoir pour qui nous concevons et si nous devons rechercher des sujets qui correspondent à Helen ou à Frank lorsque nous testons la convivialité. (Nous aurons peut-être des tests de résultats très différents avec Helen / Hank qui a une formation en ressources humaines par rapport à Frank / Francine qui a une formation en logiciels). Voici une version mise à jour de l’histoire: «En tant que responsable des ressources humaines, je souhaite sélectionner facilement un candidat en ingénierie, afin de connaître son profil de compétences."

    Voyez-vous des problèmes avec cette histoire maintenant? Je dis toujours aux étudiants d’éviter les termes normatifs comme «facilement». Je veux dire, qu'est-ce que cela signifie pour un designer? Un développeur? Avez-vous pensé qu'ils allaient le concevoir pour rendre les choses difficiles? Si vous pensez que des moments particuliers du parcours client sont importants, saisissez-les dans un scénarimage et / ou affichez-les sur une carte récit (voir la section "Développer des histoires") et décrivez réellement ce qui est important et pourquoi et comment. vous observerez si vous réussissez. (Je sais, concevoir avec soin représente beaucoup de travail !!) Supprimons «facilement» de l’histoire: «En tant que responsable des ressources humaines, Helen, je souhaite sélectionner un candidat en ingénierie afin de connaître son profil de compétences."

    Et maintenant? S'agit-il de la bonne portée pour une épopée? Je ne sais pas pour vous, mais j’ai des résultats mitigés en pensant cela dans ma tête. Je dois travailler sur le papier. Une chose que je trouve vraiment utile pour explorer une épopée (particulièrement au début d’un nouveau projet) est de la scénariser. Voici un aperçu des étapes majeures de l’épopée ci-dessus: En regardant cela, je vois beaucoup de choses: créer le quiz, payer pour Activer le questionnaire (si c’est la première fois ou si un changement d’abonnement est nécessaire), consulter un collègue (Frank), qui a administré le quiz et mis les résultats à la disposition de Frank. Je dirais que chacune d’elles se sent comme une épopée. Ce que je pense faire, c’est commencer par une épopée sur la création du questionnaire: "En tant que responsable des ressources humaines, Helen, je souhaite créer un questionnaire de présélection afin de connaître leur profil de compétences."

    Je dirais que cela se rapproche, mais cette dernière clause sur la récompense, "donc je sais que leur profil de compétences" a encore besoin de travail. Cet article est si important qu'il mérite son propre paragraphe! C'est à côté.

    Le storyboard est un excellent outil qui pousse votre équipe et vous-même à réfléchir de manière approfondie à vos clients, à ce qu’ils attendent de vous et à ce qu’ils font réellement dans la vie réelle. Surtout si vous développez quelque chose de relativement nouveau, je vous recommande vivement de scénariser vos user stories épiques et agiles.

    Le processus de scénarimage vous aidera à:

  • tester la profondeur et la portée de votre compréhension des personnages et des scénarios de problèmes
  • stimuler l'intérêt et la discussion dans l'histoire avec votre équipe de mise en œuvre (et vos pairs du côté du produit)
  • vous pousser à réfléchir à travers les détails pour que vos développeurs ne soient pas obligés de partir de zéro
  • Ce dernier point est particulièrement important si vous débutez dans le développement de produits. Je coache de nombreux entrepreneurs pour la première fois, et leur principal défi lors de la phase de mise en œuvre du produit consiste à réfléchir à ce qu'ils veulent avec suffisamment de détail. La plupart de leurs histoires sont en fait des histoires épiques (ou plus larges) et ont besoin de plus de granularité et de récit de scénario. Un mode d'échec classique laisse votre équipe de développement concevoir votre produit. Cela ne veut pas dire que vos développeurs ne peuvent pas penser de manière créative ou répondre à ces questions, et une partie du but de ces entrées est de stimuler des discussions créatives avec eux afin de maximiser l'imagination collective de l'équipe et son expertise, mais votre travail en tant que personne productrice consiste à: fournir un point de départ bien articulé et réfléchi.

    Pour en savoir plus sur le processus de scénarimage (y compris les outils et les modèles), veuillez consulter: Didacticiel de scénarimage.

    Quelle est leur récompense?

    La dernière clause de votre user story doit toujours contenir une récompense testable. La récompense semble passionnante, mais tout ce dont nous parlons est la suivante: a) décrit-elle la réussite de l’objectif qui a déclenché le récit en premier et b) peut observer un test utilisateur?

    La 3ème clause actuelle ("je connais leur profil de compétences") répond-elle à ces critères? Je pense que nous pourrions le tester: placer un prototype devant un sujet, le faire créer un quiz, puis l'administrer et voir les résultats et leur demander de nous communiquer le profil de compétences. Mais cette récompense est-elle encore pertinente? Cela n’a pas vraiment de sens avec l’intention. Que veut vraiment Helen à ce stade? Il y a quelques possibilités. Fondamentalement, elle veut déterminer, avec le responsable fonctionnel, les personnes à interroger et celles à embaucher pour la meilleure solution possible (ajustement mutuel). Je dirais "pour pouvoir comprendre si je veux envoyer les recrues possibles au responsable fonctionnel" est un bon candidat. Une autre possibilité plus immédiate est «pour que je puisse être sûr de pouvoir l’utiliser lorsque j’entretiens des candidats». Essayons-le en grand: "En tant que responsable des ressources humaines, je souhaite créer un questionnaire de présélection afin de m'assurer que je suis prêt à l'utiliser dès que j'interviewe des candidats."

    Maintenant, comment la clause sur nos tests décrit-elle a) décrivant leur réalisation et b) est-elle observable dans un test? Je dirais que cela décrit l’objectif immédiat du responsable des ressources humaines, à savoir pouvoir utiliser le test. Est-ce testable? Nous pourrions guider l'utilisateur dans la création d'un nouveau test, puis lui demander comment il l'administrerait et voir s'il avait la bonne réponse. Je dirais que c’est testable.

    Test des histoires d'utilisateurs

    Que testons-nous?

    En ce qui concerne les tests, je pense que le plus important est de a) faire une distinction claire entre convivialité et motivation et b) de comprendre la relation qui les unit. Mon outil préféré pour traiter ce problème est la courbe de BJ Fogg:

    En gros, cela signifie que si le client / utilisateur est vraiment motivé pour faire quelque chose (imaginez un point en haut à gauche), cela peut être relativement plus difficile pour lui. Si un utilisateur n’est pas motivé (imaginez un point en bas à droite), l’action doit être relativement plus facile.

    Si vous construisez un produit ou une fonctionnalité, cela implique clairement que vous devez avoir une vision équilibrée de la motivation par rapport à la convivialité. La plupart des produits et projets que je vois sont très axés sur la convivialité. Cependant, la plupart d’entre eux n’ont pas testé la motivation: l’utilisateur préférera-t-il vraiment ce produit ou cette fonctionnalité par rapport à leurs alternatives actuelles?

    Au lieu de cela, ils le confondent souvent avec leurs tests d’utilisabilité, par exemple en demandant un prototype: «Aimez-vous cela? Vas-tu [use it, buy it]? ’. Cela ne fonctionne pas – le sujet vous donnera toujours un "oui". Pour en savoir plus sur pourquoi voir plus précisément ce billet sur le «problème du baladeur jaune» ou plus généralement le tutoriel ici sur Lean Startup. Il suffit de dire ici que le type de test que nous effectuons par rapport aux histoires d’utilisateur porte sur la facilité d’utilisation, c’est pourquoi ils appellent cela le «test de convivialité».

    Ce qu’ils veulent dire, c’est que nous supposons qu’ils sont motivés (en contrôlant pour la motivation, si vous voulez) et que nous ne testons que pour la facilité d’utilisation. Cela signifie que si nous testons un logiciel permettant aux utilisateurs de peindre des murs virtuels (avec moi), nous ne leur demandons pas "Voulez-vous peindre ce mur?". Nous ne leur avons même pas demandé: "De quelle couleur voudriez-vous peindre ce mur?". Nous leur demandons: «Veux-tu me montrer comment tu as peint ce mur en jaune?». Nous verrons ensuite à quel point il est difficile pour eux de le faire et nous pensons à la manière dont nous pourrions le rendre plus facile.

    Comment testons-nous les histoires?

    Avez-vous déjà entendu quelque chose comme ceci: "Nous ne faisons pas autant de tests utilisateur que nous le devrions probablement car, à l'heure où nous pouvons tester le logiciel, nous avons déjà dépassé notre échéance." Aussi sympathique que je le sois pour ces échéances, Je ne pense pas que ce soit une bonne raison de ne pas tester la convivialité.

    Selon une vue généralement acceptée (bien que non universelle) des tests utilisateur, il est préférable d’envisager les phases suivantes:

    Lorsque vous effectuez des tests préliminaires, les prototypes approximatifs (physiques ou virtuels) fonctionnent correctement. Vous n'avez pas besoin d'un ingénieur ni (avec le processus approprié) même d'un concepteur dûment formé pour tester l'efficacité de différentes approches. Mon conseil est de maximiser ces opportunités tôt dans la formulation de votre histoire. Par ailleurs, je vous recommande fortement (2 très fortement) d’ancrer vos éléments de test dans des récits d’utilisateur, par opposition à des objectifs spécifiques à l’interface, tels que «Voir si l’utilisateur comprend notre menu déroulant».

    Pour un aperçu rapide de la procédure à suivre, je vous recommande la section Tests d'utilisabilité du Manuel de découverte de la clientèle.

    Pour une vue plus détaillée, je vous recommande d'exécuter Running Design Sprints (cours 2 dans ma spécialisation agile sur Coursera) et de tester avec Agile (cours 4).

    Quand une histoire est-elle terminée?

    Je pense que vous constaterez que c’est une question précieuse à laquelle répondre avec votre équipe. Je l’ajouterais à l’autre extrémité de la question plus large, qui est «Quand une histoire commence-t-elle?

    La pensée dominante concernant le développement de logiciels modernes est que vous devez traiter votre produit, en fait, chaque fonctionnalité de votre produit, comme une expérience continue.

    Bien qu’elle s’appuie beaucoup sur l’agile, c’est vraiment le travail autour de Lean Startup qui a popularisé cela. Leur heuristique centrale est «construire-mesurer-apprendre». Je préfère les termes que vous voyez dans la boucle bleue ici, mais ils correspondent fondamentalement à la même chose.

    Le début de toute bonne réponse à la question ci-dessus commence par la reconnaissance du fait que vous ne pouvez tout simplement pas prédire (de manière cohérente) ce qui sera précieux pour l’utilisateur. Par conséquent, vous devez utiliser des idées testables et des expériences en boucle fermée pour déterminer si vous avez raison ou non.

    Idéalement, vos histoires commencent par une sorte d'observation sur votre utilisateur et sur les problèmes (tâches, désirs) qu'il a. Ensuite, vous proposez une formulation testable de la manière dont vous saurez si votre idée de solution est vraiment meilleure qu’elle ne l’a actuellement. Un exemple très tactique de Lean UX est que vous pouvez insérer un élément de menu ou un bouton d’espace réservé pour votre nouvelle fonctionnalité et voir si les utilisateurs cliquent dessus (à quel moment ils reçoivent un message «Prochainement»). Une fois que vous avez validé l'existence d'une certaine motivation pour votre fonctionnalité, vous passez à de véritables user stories et testez la convivialité au fur et à mesure. Ensuite, une fois que vous avez libéré ladite fonctionnalité dans la nature, vous disposez de quelques mesures de convivialité et de motivation qui vous indiquent si, en fait, vous avez vraiment raison (et dans quelle mesure). Idéalement, cette fonctionnalité que vous avez implémentée est la version la plus simple possible (produit viable minimum) qui vous permettra de savoir si vous avez raison ou non. En gros, vous voulez réaliser quelque chose comme ceci:

    Yup, c'est beaucoup de choses. Mon approche particulière pour le rendre gérable et exploitable est Venture Design, qui est décrite dans le diagramme ci-dessous. Si vous voulez vraiment creuser et assurez-vous d’itérer quelque chose de précieux avec un minimum de gaspillage, je vous recommande vivement de jeter un coup d’œil. Ceci dit, passons au développement d’histoires!

    Développer avec des histoires et des cartes d'histoires

    Qui écrit les histoires d'utilisateurs?

    Les chances sont bonnes que si vous faites de l’agile, vous utilisez scrum ou une approche agile en mode scrum. Si vous avez une personne dans le rôle de «propriétaire de produit» (PO) prescrit par Scrum, vous avez probablement entendu dire que c’est à eux d’écrire les user stories. C'est un point de départ raisonnable. Cela dit, la meilleure façon de voir les choses est probablement que le bon de commande est le principal responsable de la rédaction des récits d'utilisateurs par opposition à celui uniquement responsable.

    ATTENDEZ! C’est très important, il ne s’agit pas uniquement de choses délicates et délicates. Cela pourrait même avoir plus d'importance que les mécanismes prescrits de la mêlée. Voici les raisons spécifiques pour lesquelles: 1. Le problème 1/40 Sur la base de résultats expérimentaux, il est possible (je suppose que probablement) que les gens ne comprennent réellement que 1/40 de ce que nous pensons leur avoir dit. Un candidat au doctorat à Stanford a fait une expérience dans laquelle une personne (un «tapeur») écoutait une chanson et un autre parti (un "auditeur"). Les tapeurs ont deviné qu’ils avaient été compris 50% du temps alors que les auditeurs n’avaient en fait compris que 2,5% du temps de pause 20 fois. Beurk!

    Et si c’est le cas des histoires que nous écrivons et de la compréhension que nous supposons d’un concepteur et / ou d’un développeur quant à la façon de concevoir un logiciel en fonction de cette histoire? Est-ce que cela correspond quelque peu au type de déconnexion que vous voyez entre les "hommes d’affaires" et les "techniciens"?

    Si vous claquez vos user stories dans JIRA et supposez qu'elles seront comprises, vous rencontrerez probablement des problèmes. En passant, j’ai d’abord lu à ce sujet dans l’excellent livre «Made to Stick» des frères Heath.

    2. Nous mesurons notre efficacité localementUne partie de nous-mêmes veut simplement savoir de manière simple quel est notre travail et combien nous devons faire. Nous avons besoin de certitude et d'un sentiment d'accomplissement immédiat. Si quelqu'un me dit que mon travail consiste à creuser six trous, une partie de moi veut simplement le faire et être fait. C’est bien, c’est juste la nature humaine.

    Malheureusement, vous ne pouvez pas créer un logiciel intéressant pour les utilisateurs de cette façon (du moins sans cohérence). Si vous ne co-créez pas d’histoires avec votre équipe, elles ne se sentiront tout simplement pas comme si elles leur appartenaient et leur travail ne serait pas aussi sérieux. Étant donné que les histoires sont probablement votre travail, je vous prie de m'excuser à l'avance, mais ne blâmez pas l'équipe de mise en œuvre, vous agissez de la même manière dans leurs fonctions. Encore une fois, c’est juste la nature humaine.

    Dans la salle de classe, je parle souvent du «moment du bouton bleu». Dans une équipe agile peu performante où les développeurs ne comprennent pas et / ou n’ont pas adhéré à l’idée, cela ressemble à ceci: Dans une équipe agile très performante, cela ressemble à ceci: Si vous êtes en tête du classement créer des histoires, une partie de votre travail consiste à résoudre les deux problèmes ci-dessus et à aider votre équipe à devenir une pratique agile de haut niveau.

    Comme si cela ne suffisait pas, il y a une raison de plus pour écrire des histoires en équipe.

    3. Vous n’avez pas toutes les meilleures idéesNaturellement, d’autres auront de très bonnes idées sur ce que l’utilisateur peut vouloir et sur la façon de le mettre en œuvre dans un logiciel. Au-delà de la rédaction de votre histoire avec l'équipe élargie, c'est la raison pour laquelle toute l'équipe est généralement associée à la pratique de plus en plus répandue consistant à exécuter des sprints de conception.

    Une méthode spécifique pour encourager les bons résultats autour des histoires est d’organiser des ateliers d’écriture d’histoires animés par les OP / histoires, que nous aborderons dans la section suivante.

    Comment utilisez-vous les histoires au sein d'une équipe?

    Les histoires d'utilisateurs sont votre point d'ancrage pour travailler ensemble sur ce que vous allez construire et comment vous saurez si cela fonctionne. Dans un monde parfait, toute l’équipe organise ensemble des sprints de conception pour en apprendre davantage et pour cultiver une compréhension commune. Quoi qu’il en soit, pour parvenir à une compréhension commune forte, il est essentiel de formuler les histoires ensemble et de les rendre très visibles à l’équipe. La carte de l’histoire, popularisée par Jeff Patton:

    Le scénario présente quelques tâches pour vous: 1) vous aide à réfléchir aux histoires appropriées, 2) vous aide à les hiérarchiser et 3) sert de "radiateur d'information" pour que les histoires restent visibles pendant que vous les travaillez au cours des semaines. ou des mois. Si vous êtes responsable de la gestion des ateliers de rédaction d’histoires de votre équipe, je pense que vous trouverez que c’est un outil très précieux.

    Parlons de la façon d’en faire un. La première bande (0) définit l'axe des x de la carte récit et représente le parcours client / utilisateur. Il est préférable de construire avec des carrés de storyboard. La raison pour laquelle les détails apparemment stupides dans les carrés de storyboard est importante est que tout ce que vous pouvez faire pour vous aider à rester concentré "en dehors du bâtiment" et sur la vie de l'utilisateur vous aidera à obtenir de meilleurs résultats plus efficacement. Point fin: si vous êtes un scénariste de vos épopées (bonne idée!), Alors ce que vous voudriez probablement faire sur la «bande 1» est de choisir parmi celles-ci pour créer une sorte de résumé. C’est une bonne idée, c’est qu’une épopée bien articulée aura généralement beaucoup plus de carrés de storyboard que vous ne voudrez, avec la taille et la densité d’une carte d’histoires typique.

    Parlons de la bande 1+ et de l’axe des ordonnées. L'axe des y décrit la priorité relative, de sorte que la bande 1 a une priorité supérieure à la bande 2, etc. If you have a bunch of stories about how a user would search for a product, you’d put what you assume is the most common/important story in stripe 1, and then less common types of search stories in the same vertical space within stripes 2, etc. Careful prioritization on this axis relative to the x-axis/user journey is a subtle but important part of any high-functioning agile program.

    The best explanation I’ve heard comes from agile thought leader Bill Wake: Let’s say you’re building a site where the basic  user journey is a) search b) select c) purchase. It’s natural (but a terrible idea) to build out all the search functions and then move on to select, etc. The reason it’s a terrible idea is that you won’t be able to do any meaningful user testing or market/release testing. The user can’t do anything potentially valuable by just searching for stuff. In a high-functioning agile team, you’re iterating through the thinnest possible slices of your story map, testing, assessing, and then building more software.

    How do you use stories day to day?

    In a high-functioning agile environment, when anyone is unsure of an implementation detail, they have a discussion around user stories- see the blue button moment above. I’ve shown you how to put yourself in a position to write strong stories that are anchored in the life of the user and highly testable. You’ve also seen how to organize and prioritize stories with a story map.

    It takes practice to consistently write good user stories and apply them effectively to help your team work better. For overall breadth on how to think about this, my favorite heuristic on user stories is Bill Wake’s INVEST acronym. Bill Wake introduced the INVEST mnemonic in his seminal post on creating better stories, suggesting they should be Independent, Negotiable, Valuable, Estimable, Small, and Testable. The INVEST checklist is a guideline, not a commandment, as Bill Wake makes clear in his post. When in doubt, always do what you think makes sense. All that said, here’s an overview of INVEST:

    Independent

    Ideally, you should be able to implement your stories in any order while still realizing the benefit of seeing something working at the end. This is important for two reasons. First, you lose a lot of the adaptability agile’s supposed to deliver if your stories have (many) interdependencies. Second, independence makes it much more likely that you can sequence what you do such that it’s meaningful to users and testable with them by the end of an iteration.

    Spotify is known for its success with agile and other adaptive techniques. This slide from one of their talks summarizes the value of Independent (and Valuable and Testable).

    Negotiable

    User stories are not requirements. It’s a combination of stories and regular discussions that are meant to replace requirements. You should revise stories freely as you and your collaborators come up with better ideas.

    Valuable

    Each story once implemented should be both functional and relevant to the customer/user.  We’ve talked a lot in this post about how to achieve that.

    A quote from Bill Wake’s original post on why this is important in software development projects: Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.

    Estimable

    It should be possible for a developer with relevant experience to roughly estimate a story. That estimate’s then used by the product person to prioritize their list of stories, taking account of both value and cost (in terms of developer time).

    Estimating’s kind of controversial in the agile community and not without good reason: It can lead unnecessary overhead and pointless recriminations when the final output doesn’t ‘agree’ with the original estimates. These are all things agile strongly tries to help avoid.

    If I were to offer three silver bullets on this, they would be: 1) Write good stories based on validated insights about the user. 2) Make sure everyone understands and agrees that the estimates are very approximate (like Small-Medium-Large) and for purposes of prioritization. 3) If you want to do post-mortems on estimates vs. actuals, make sure there’s general agreement that it’s to help the team in some actionable way and not just because someone’s frustrated there isn’t more implementation done.

    Small

    Your unimplemented stories are like a box of chocolates…ah, scratch that, reader; never mind.

    Basically, your stories need to be Small for you to get the adaptability and reduction in overhead that agile offers. Big stories reduce opportunities for incremental testing and require more elaborate planning.

    Testable

    As the author of a story, you should be able to write tests that would allow you to validate that an implementation delivers on your intent. Many teams operate this way, but regardless of what everyone else does, you’ll do yourself a big favor by writing some functional test cases in advance- you’ll be much more likely to get what you want more easily.

    Example A: Example User Stories from Enable Quiz (Startup)

    Example Epic I

    This epic story deals with the example company Enable Quiz and the HR manager wanting to create a quiz to screen engineering candidates. is organized in a more conventional fashion (vs. the epic above that’s storyboarded).

    Epic Story: “As the HR manager, I want to create a screening quiz so that I make sure I’m prepared to use it when I interview job candidates.”

    USER STORY
    TEST CASES
    As a manager, I want to browse my existing quizzes so I can recall what I have in place and figure out if I can just reuse or update an existing quiz for the position I need now.
    Make sure it’s possible to search by quiz name

    Make sure it’s possible to search by quiz topics included.

    Make sure it’s possible to search by creation and last used date.

    As an HR manager, I want to match an open position’s required skills with quiz topics so I can create a quiz relevant for candidate screening.
    Make sure the quiz topics are searchable by name.

    Make sure the quiz topics have alternate names, terms for searching

    As an HR manager, I want to send a draft quiz to the the functional manager so I make sure I’ve covered the right topics on the screening quiz.
    Make sure it’s possible to add another user by email in this flow

    Make sure it’s possible to include notes and customize the email

    Make sure it’s possibly to just copy a link (for case where HR manager wants to send their own email)

    As a functional manager, I want to send feedback on the screening quiz to the HR manager so I make sure I’m getting the best possible screening on candidates.
    Make sure it’s possibly to supply comments in-app.

    Make sure the above are quiz-specific by default but can also be general.

    Make sure it’s also easy to copy the name or URL of the quiz for their own correspondence.

    As an HR manager, I need to purchase an upgraded service tier so I can add additional topics to my quiz.
    Make sure that users with billing privileges can upgrade the service.

    Make sure that If the users don’t have billing privileges, they see a list of those that do and can contact them.

    Make sure the charges are correctly prorated against the billing anniversary of the account.

    As an HR manager, I want to add custom questions to the quiz so we cover additional topics that are important to the functional manager.
    Make sure the customer is not charged for this bank.

    Make sure the custom bank is owned by the client organization and not accessibly by any other accounts on the system.

    ’As the HR manager, I want to try out the screening quiz so that I can make sure it works as I expected and that I’m ready to both give it to candidates and share the results with the functional manager.’
    Make sure there is a clear indication that the user can (and should) test the quiz

    Make sure there’s a ‘view as test taker’ mode available to the admin.

    Here are a few other epics that might follow this one.

    Example Epic II

    ‘As the HR manager, I want to give the screening quiz to a job candidate so I can assess their skill sets against the needs of the position.’

    Example Epic III

    ‘As the HR manager, I want to share and explain the results of our screening with the functional manager so they can decide who they want to interview.’

    READY TO WRITE USER STORIES LIKE A DESIGNER?

    Example B: Example User Stories from HVAC in a Hurry (IT Project)

    Example Epic I

    ‘As Ted the HVAC technician, I want to know the pricing and availability of a part that needs replacing so I can decide my next steps.’

    USER STORY
    TEST CASES
    I know the part number and I want to find it on the system so I can find out its price and availability.
    Make sure it’s possible to search by part number.Make sure descriptive info. appears as the search narrows (photo?) to help avoid error.
    I don’t know the part number and I want to try to identify it online so I can find out its price and availability.
    Make sure it’s possible to search by make/model of unitsMake sure it’s possible to search by type
    I don’t know the part number and I can’t determine it and I want help so I can find out its price and availability.
    Make sure an estimate of the turnaround time for an expert to review is available
    I want to see the pricing and availability of the part so I decide on next steps and get agreement from the customer
    Make sure it’s possible to dispatch a request by email to the customer in case they order their own parts and/or carry their own inventory of spares.NOTE: How would the customer respond so we can help structure the next steps as we would otherwise?

    Citations and Image Credits

    Pair Programmers: By Lisamarie Babik (Ted & Ian Uploaded by Edward) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia CommonsChemist: By Linda Bartlett (Photographer) [Public domain or Public domain], via Wikimedia CommonsPresent: By Kgbo (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia CommonsChocolates: By Dwight Burdette (Own work) [CC-BY-3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia CommonsMeter: By Iainf 05:15, 12 August 2006 (UTC) (Own work) [GFDL (http://www.gnu.org/copyleft/fdl.html), CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/) or CC-BY-2.5 (http://creativecommons.org/licenses/by/2.5)], via Wikimedia Commons

    Votre meilleure histoire d'utilisateur agile
    4.9 (98%) 32 votes