Qu'est-ce qui fait une bonne histoire ? Une bonne histoire est une histoire qui attire l'attention du lecteur avec un crochet captivant, un complot intéressant avec des conflits et des drames, un cadre vivant et immersif, et des personnages multiformes qui sont confrontés à des défis et les résolvent tout au long du récit.
Eh bien, ce n'est pas le cas des histoires d'utilisateurs. Ils n'ont pas tous ces éléments (à l'exception des personnages), mais les histoires d'utilisateurs n'ont pas besoin d'eux pour jouer un rôle important dans le développement de logiciels. Étant un élément indispensable de la philosophie Agile, ils reflètent ses principes fondamentaux d'inspiration de la créativité, de promotion de la collaboration et de se concentrer sur les besoins de l'utilisateur final.
Comme vous l'avez peut-être déjà deviné, cet article est consacré aux histoires des utilisateurs. Nous parlerons de ce qu'ils sont et expliquerons en détail comment les écrire et les gérer.
Qu'est-ce que les histoires des utilisateurs?
Les histoires d'utilisateurs sont un moyen de décrire la fonctionnalité d'un produit logiciel du point de vue de l'utilisateur final ou du client. Elles ont été introduites à la fin des années 90 par Kent Beck dans le cadre de la programmation extrême en tant qu'autre approche de la documentation des exigences.
Il est important de le décrire, une histoire d'utilisateur ne décrit pas la fonctionnalité elle-même ou comment développer la fonctionnalité, mais définit plutôt le besoin de l'utilisateur - l'objectif final, laissant ainsi à l'équipe de développement une place pour la créativité dans la mise en œuvre de la fonctionnalité.
Format de l'histoire de l'utilisateur
Les histoires d'utilisateurs sont des déclarations courtes, simples et concises, généralement rédigées dans un style informel. Ils décrivent le qui, le quoi et le pourquoi derrière la fonctionnalité en cours de développement. Même s'il peut y avoir une marge de manœuvre dans la façon de les écrire, la norme commune est une phrase à une seule ligne dans le format suivant:
En tant que type d'utilisateur, je veux effectuer une action - de sorte que - une raison ou un avantage -
Exemples d'histoire d'utilisateurs
En d'autres termes, chaque histoire d'utilisateur comprend un personnage d'utilisateur spécifique, l'opération intermédiaire qu'il veut faire, et le résultat souhaité qu'ils veulent atteindre.
Exemples d'histoires d'utilisateurs
Il est plus facile de comprendre les histoires des utilisateurs à travers des exemples. Voici quelques cas liés à l'utilisation de logiciels (même si vous pouvez certainement écrire des histoires d'utilisateurs sur l'achat de ces beignets de chocolat ou le lancement d'une fête du vendredi soir).
En tant que chef de projet, je veux suivre les performances de afin .
En tant qu'acheteur en ligne, je veux filtrer les produits par prix, catégorie et classement afin de trouver facilement ce dont j'ai besoin.
En tant que voyageur, je veux choisir des sièges d'avion en ligne pour que je m'assoie avec mes amis.
En tant que joueur en ligne, je veux voir des informations de santé tout le temps sur l'écran afin que je surveille commodément mon statut.
En tant que passager, je veux voir le numéro de téléphone du conducteur afin que je puisse l'appeler ou lui envoyer un SMS au cas où nous ne nous trouvions pas.
En tant qu'utilisateur de médias sociaux, je veux ajouter une photo à mon profil afin que les autres utilisateurs sachent à quoi je ressemble.
En tant que titulaire d'une carte de crédit, je veux voir la liste des transactions récentes afin que je contrôle mes dépenses.
En tant que restaurant, je veux voir les restaurants sur la carte pour que je choisisse le plus proche.
Notez que certaines histoires d'utilisateurs (en particulier liées à la fonctionnalité d'arrière-plan) n'auront pas le client final en tant qu'acteur. Dans ce cas, l'histoire de l'utilisateur peut se concentrer sur l'utilisateur professionnel, comme l'administrateur du système ou l'exécutif. Comme Dmytro Hurkovskyi, un analyste d'affaires chez AltexSoft, plaisante : « Tout peut être écrit comme des histoires d'utilisateurs. Si quelqu'un ne peut pas écrire une histoire d'utilisateur sur quelque chose, il doit aller chercher une formation BA supplémentaire ».
Histoires d'utilisateurs dans Agile
Les histoires d'utilisateurs sont un élément essentiel des divers cadres Agile, soutenant la philosophie de premier plan des utilisateurs et leurs besoins (au lieu du processus de codage ou de la documentation technologique). Dans le cadre de la philosophie Agile, ils aident à créer une compréhension partagée de ce que l'utilisateur veut, soutenant la collaboration entre les membres de l'équipe et d'autres parties prenantes sur la façon dont le logiciel peut fournir cette valeur.
Histoires d'utilisateurs dans le cadre de l'arriéré
Dans de nombreux cadres Agiles comme Scrum et Kanban, les histoires des utilisateurs sont les éléments de base de l'arriéré. Du point de vue de l'équipe des développeurs, les histoires d'utilisateurs – ou les éléments d'arriéré – peuvent être considérées comme le travail nécessaire à faire au cours d'une itération.
Et c'est ce qui rend les histoires d'utilisateurs si cruciales puisque les équipes organisent essentiellement leurs activités de projet autour d'eux. Ils sont également essentiels pour l'accumulation de temps de préparation et la réalisation d'estimations de projets dont nous parlerons un peu plus tard.
Histoires d'utilisateurs ou cas d'utilisation
Comme nous l'avons mentionné, les histoires des utilisateurs sont essentiellement apparues dans Extreme Programming comme un moyen de gérer les exigences alternatives aux cas d'utilisation. Et la similitude des deux termes provoque souvent la confusion. Les histoires d'utilisateurs sont parfois même utilisées indifféremment avec des cas d'utilisation parce que les deux décrivent comment l'utilisateur interagit avec le système. Toutefois, ils présentent d'importantes différences de format, d'objectif et de niveau de détail.
Format. Contrairement au format d'histoire d'utilisateurs succinct et informel, les cas d'utilisation sont généralement écrits de manière plus structurée et formelle, y compris des éléments tels que les acteurs (il peut s'agir de l'utilisateur ou un autre système), des conditions préalables, du système (exigences fonctionnelles), des déclencheurs, des flux alternatifs, des post-conditions, etc.
Niveau de détail. Les histoires d'utilisateurs sont très brèves et ne décrivent que l'intention de l'utilisateur, tandis que les cas d'utilisation sont beaucoup plus détaillés et donnent plus de contexte.
Objet. Les cas d'utilisation déterminent et officialisent les besoins fonctionnels, définissent la portée du projet et donnent aux ingénieurs des orientations approfondies sur le processus de développement. Pendant ce temps, les utilisateurs fournissent une orientation générale de développement et aident à garder tout le monde sur la même page (à la fois les équipes techniques et les parties prenantes non technologiques).
Comme l'a expliqué Dmytro Hurkovskyi, « les histoires d'utilisateurs ont en fait évolué en tant que successeurs pour utiliser des cas. Ils ont permis aux équipes Agile matures qui n'ont pas besoin de cas d'utilisation détaillés pour réduire le temps de . Cependant, en réalité, un modèle hybride est souvent mis en œuvre, et certains contextes sont ajoutés aux histoires des utilisateurs pour fournir aux développeurs plus de lignes directrices.»
Histoires d'utilisateurs vs épopées vs tâches
Différentes équipes utilisent diverses approches pour structurer leurs travaux. Un scénario commun est de décomposer l'ensemble des épopées de portée du projet, des histoires des utilisateurs et des tâches.
Épises, histoires des utilisateurs et hiérarchie des tâches
Une épopée peut être définie comme un groupe d'histoires d'utilisateurs qui constitue un plus grand nombre de travail qui est généralement fait au cours de plusieurs sprints. Une épopée n'est donc pas un problème spécifique, mais plutôt un flux entier comme l'enregistrement, la gestion du profil, la recherche, la réservation, le paiement, etc.
Pendant ce temps, une histoire d'utilisateur peut être décomposée en tâches qui sont les plus petits segments de travail à faire pour terminer une histoire.
Vous pouvez également rencontrer le terme d'initiative qui est essentiellement un objectif de haut niveau qui doit être atteint à la suite du projet (par exemple, lancer un produit pour commercialiser ou augmenter le bénéfice de l'entreprise de X %). Certaines équipes utilisent des initiatives pour décrire un ensemble d'épopées.
Maintenant que vous avez une idée de ce que sont les histoires des utilisateurs, de plus en plus pratiques et voyons comment elles sont créées.
Comment écrire des histoires d'utilisateurs ?
Tout d'abord, revenons à l'origine et regardons les trois aspects clés des histoires d'utilisateurs connus sous le nom de 3 Cs.
Les 3 C d'histoires des utilisateurs
Ron Jeffries, le fondateur de Extreme Programming, a proposé une formule dite 3 C, décrivant les trois éléments essentiels des histoires des utilisateurs: Carte, Conversation et Confirmation.
La carte fait référence à une représentation tangible d'une exigence puisque, dans un premier temps, les histoires d'utilisateurs étaient écrites à la main sur des cartes à index qui pouvaient ensuite être déplacées tout en hiérarchisant l'arriéré, remises aux développeurs qui travaillent sur la tâche connexe, ou donnés au client à l'achèvement de la tâche. Les cartes donnent rarement des détails sur l'exigence mais définissent l'intention et servent d'invitation à la conversation.
La conversation a lieu au fil du temps (souvent pendant la planification itorisation/printemps) lorsque les membres de l'équipe (et d'autres parties prenantes) partagent des réflexions et des opinions sur l'histoire en discussion. La conversation est nécessaire car elle aide à développer une compréhension commune, à fixer l'objectif et à faire des estimations. La conversation est en grande partie verbale et peut être complétée par de la documentation.
La confirmation fait référence à des conditions dans lesquelles l'histoire de l'utilisateur sera définie comme accomplie, et l'objectif fixé pendant la conversation est atteint. Ils sont également connus sous le nom de critères d'acceptation - que nous allons décrire en un certain temps.
Meilleures pratiques des utilisateurs et modèle de qualité INVEST
Voici quelques lignes directrices pratiques sur la façon d'écrire de grandes histoires d'utilisateurs.
Gardez-le simple. Tenez-vous au format concis et informel des histoires des utilisateurs et évitez les détails inutiles ou l'argot technologique. De cette façon, vous serez en mesure d'engager différentes parties prenantes dans une conversation productive.
Éviter l'ambiguité. Les histoires bien écrites des utilisateurs sont claires pour les parties prenantes et ne permettent pas d'interpréter plusieurs fois.
Mettez d'abord l'utilisateur. Au lieu de se concentrer sur les aspects commerciaux ou techniques, gardez toujours à l'esprit le point de vue de l'utilisateur.
Commencez par les épopées. Les épopées sont un excellent moyen de capturer l'ensemble de la fonctionnalité du produit. Vous pouvez ensuite les décomposer en petites histoires plus spécifiques d'utilisateurs plus faciles à gérer.
Déterminer les personas de l'utilisateur. Définir le type d'utilisateur qui interagit avec le produit sur la base d'une étude de marché. S'il y a plusieurs types d'utilisateurs, écrivez plusieurs histoires d'utilisateurs.
Encourager la collaboration et le retour d'information. Laissez toutes les parties prenantes communiquer leurs pensées et leurs opinions sur ce qu'un produit devrait faire afin que vous puissiez développer la meilleure solution qui satisfasse tout le monde.
Affinez les histoires des utilisateurs. Réaliser régulièrement un arriéré de toilettage, c'est-à-dire, examiner constamment vos histoires d'utilisateurs pour s'assurer qu'elles sont pertinentes et hiérarchisées.
S'assurer qu'ils respectent les critères INVEST.
INVEST est synonyme d'une liste de contrôle largement acceptée qui aide à évaluer la qualité des histoires des utilisateurs. Assurez-vous donc qu'ils sont
I – Indépendant (chacun ne devrait pas dépendre des autres afin qu’ils puissent être faits dans n’importe quelle séquence et ne pas s’affecter mutuellement s’ils sont modifiés),
N – Négociable (il ne devrait pas y avoir de flux de travail rigide, mais plutôt une marge de manœuvre pour la conversation et les ajustements),
V – Valable (chaque histoire de l'utilisateur doit apporter de la valeur à l'utilisateur final),
E – Estimable (l'équipe devrait être en mesure d'estimer l'effort nécessaire pour compléter l'histoire de l'utilisateur),
S – Petit (chaque histoire d'utilisateurs ne devrait pas prendre plus d'un sprint à compléter), et
T – Testable (il est possible de définir au moins un critère d'acceptation pour confirmer la bonne achèvement de l'histoire de l'utilisateur).
Ajouter des critères d'acceptation. Précisions détaillées des conditions qui doivent être remplies pour considérer l'histoire de l'utilisateur complète.
Les critères d'acceptation constituent un sujet vaste et important qui mérite d'être approfondi. Découvrez l'article lié pour en savoir plus sur leurs objectifs, leur format et les meilleures pratiques, ou regardez l'expliquant de la vidéo ci-dessous. Dans ce billet, nous fournirons un bref résumé des points clés.
Critères d'acceptation des histoires d'utilisateur
Les critères d'acceptation (AC) sont une liste de conditions que le produit développé doit remplir pour définir l'histoire de l'utilisateur comme « fait ». Ces critères aident toutes les personnes concernées à comprendre que le produit répond aux attentes du client et de l'utilisateur final. Ils clarifient également les exigences en ajoutant des détails aux histoires des utilisateurs, fournissant ainsi aux ingénieurs de meilleures orientations grâce au processus de développement.
Exemples de critères d'acceptation
En plus de faciliter le développement, l'AC sert également de base aux tests d'acceptation.
Modèles d'histoires d'utilisateur
Maintenant que vous savez tout sur la création d'histoires d'utilisateurs, vous pouvez les écrire dans n'importe quel support qui vous convient, qu'il s'agisse de notes collantes, d'un document Microsoft Word, d'un bloc-notes numériques ou d'un tableau blanc dans votre bureau. Voici quelques modèles téléchargeables suggérés par Ahaa pour vous permettre de choisir le niveau de format et de détail (ils téléchargeront automatiquement lorsque vous cliquerez dessus).
- Une histoire d'utilisateur simple avec des critères d'acceptation
- Modèle Word, Épès, histoires d'utilisateurs et critères d'acceptation
- Thèmes, histoires d'utilisateurs et critères d'acceptation
- Un modèle Excel d'histoire de l'utilisateur Excel (Cind du cadre Agile) l'échelle
Une autre façon – et sans doute plus efficace – est de créer et de gérer des histoires d'utilisateurs dans des logiciels spécialisés. Nous parlerons plus avant de certains outils numériques – juste après avoir discuté des autres actions possibles avec les histoires d'utilisateurs.
Comment travailler avec les histoires d'utilisateurs?
Faisons un zoom un peu plus. Vous ne pouvez pas simplement écrire des histoires d'utilisateurs et les oublier. Ils ont leur propre cycle de vie dans le cadre du projet, de sorte qu'ils doivent être gérés correctement. Traçons donc l'évolution de l'histoire de l'utilisateur et commençons par la question qui dérange toujours les parents et les flics – qui est responsable ?
Qui écrit des histoires d'utilisateurs et quand ?
Typiquement, c'est le propriétaire du produit/le chef de produit qui écrit des histoires d'utilisateurs – et il est également de leur responsabilité de retrouver un arriéré. Souvent, la recherche sur l'adéquation produit/marché est menée avec l'aide d'analystes d'affaires pour connaître les besoins des consommateurs - à convertir en exigences dans le format de l'histoire de l'utilisateur.
En réalité, cependant, ce n'est pas si simple et direct. La nature même des histoires d'utilisateurs est coopérative (souvenez-vous de la partie conversation?), de sorte que toutes les parties prenantes sont censées participer à leur développement. Et ce n'est que naturel. Il est courant qu'un client trouve des idées sur la valeur que le produit devrait apporter à l'utilisateur final. D'autre part, les membres de l'équipe suggèrent souvent des moyens d'améliorer le logiciel développé – et ajoutent de nouvelles histoires d'utilisateurs à l'arriéré.
Quant à quand, généralement, la majorité des épopes sont écrites aux premiers stades du projet (la phase dite de découverte) puis décomposées en histoires d'utilisateurs. Dmytro Hurkovskyi a déclaré : « Les histoires d'utilisateurs sont continuellement développées tout au long du projet. »
Il est important de se rappeler que les histoires des utilisateurs ne sont pas des exigences strictes et évoluent au cours du projet. Nous avons déjà expliqué que les équipes ajoutent souvent plus de détails aux histoires des utilisateurs lorsqu'elles les classent en matière de hiérarchisation en retard. En outre, lorsque l'équipe commence à estimer des histoires spécifiques d'utilisateurs, il pourrait s'avérer que certaines d'entre elles sont trop grandes – et doivent être décomposées en petites histoires.
Cartographie des histoires d'utilisateurs
Disons que vous avez écrit un certain nombre d'histoires d'utilisateurs vraiment cool qui décrivent toutes les fonctionnalités du produit. Et maintenant, vous avez un tas de fonctionnalités formalisées que vous devez construire - mais cela ne vous donne aucune idée de par où commencer et comment procéder.
La cartographie de l'histoire de l'utilisateur est le processus d'agencement des histoires d'utilisateurs sous la forme d'un récit qui décrit le parcours de l'utilisateur lorsqu'ils interagissent avec le produit.
Une carte d'histoire vous permet d'organiser visuellement des éléments d'arriéré en deux dimensions: l'horizontale (une colonne vertébrale) représente le parcours de l'utilisateur, et le plus vertical désigne la priorité. Dans cette structure, il y a aussi une place pour les épopées, les user personas et ce que l'on appelle les « belles d'avoir » les caractéristiques qui sont en discussion.
L'organisation d'histoires d'utilisateurs dans des cartes d'histoires selon une version programmée ou un sprint donne aux équipes une meilleure vue des objectifs et de la vision des produits, vous permet de découvrir les éléments manquants, facilite l'arriéré de toilettage et inspire une conversation productive sur la façon d'apporter plus de valeur.
Estimation de l'histoire des utilisateurs
Nous avons mis dans cette chose d'estimation ici et là – mais qu'est-ce que c'est exactement ? Eh bien, tout client veut connaître à l'avance la durée et le coût du projet. Et cette prédiction est ce avec quoi toute équipe de développement a toujours du mal parce qu'il y a trop d'inconnues dans le développement de logiciels, en particulier au stade initial
Même s'il y a des fans du mouvement «No Estimates» (qui a émergé parce que quelqu'un en a marre de toujours faire les délais), la plupart des équipes font encore des estimations. Et l'une des approches populaires implique d'utiliser des points d'histoire pour mesurer la quantité d'effort nécessaire pour compléter une histoire d'utilisateur.
En bref, les estimations de points de l'histoire sont faites en jouant au poker de planification, qui est essentiellement le vote avec des cartes qui contiennent des nombres de Fibonacci, des tailles de T-shirts ou d'autres unités de mesure relatives. Une fois que tous les membres de l'équipe se sont mis d'accord sur la valeur, l'estimation est fixée.
Ces points d'histoire sont ensuite présentés au client et sont également utilisés pour mesurer la vitesse, c'est-à-dire la productivité d'équipe. Si vous souhaitez plus d'informations sur les points d'histoire et leur fonctionnement, veuillez consulter notre billet dédié.
Logiciel d'histoire d'utilisateur
Comme nous l'avons mentionné à l'origine, les histoires d'utilisateurs étaient écrites sur des cartes ou des notes collantes pour la facilité de les gérer – et certaines équipes adhèrent encore à ce format tangible. Cependant, au fur et à mesure que le monde numérise, il en va de même des flux de travail, y compris de gestion de projet.
Aujourd'hui, vous pouvez créer et gérer des histoires d'utilisateurs dans divers outils numériques qui les aident à les visualiser et à les partager avec les parties prenantes pour soutenir la collaboration.
Les outils de gestion de projet les plus populaires comme Jira et Trello incluent la fonctionnalité liée à l'histoire de l'utilisateur, donc si vous utilisez l'un de ceux pour organiser vos activités, ils fonctionnent très bien.
Histoires d'utilisateurs dans Trello
Il existe également des outils plus spécialisés pour travailler avec les utilisateurs. Voici une liste de certaines plateformes bien examinées compilées par The Product Manager.
- https://www.productboard.com/ Carte de produit - logiciel d'histoire utilisateur pour la hiérarchisation des caractéristiques de produit.
- https://www.avion.io/ Avion - logiciel d'histoires d'utilisateurs pour les arriérés complexes.
- https://www.featuremap.co/fr FeatureMap - logiciel gratuit d'histoire de l'utilisateur.
- https://www.featmap.com/ Featmap - logiciel d'histoire de l'utilisateur open source
- https://www.visual-paradigm.com/ Paradigme visuel - pour une communication et une collaboration efficaces.
D'autres outils pratiques méritent d'être mentionnés, à la carte, à StoriesOnBoard et à Miro.
Faiblesses d'histoires des utilisateurs et pièges potentiels
Les histoires d'utilisateurs sont un instrument pratique qui peut être appliqué à n'importe quel projet de développement, mais ils ne sont pas parfaits et ont quelques limites dont vous devez être conscient.
Manque de compréhension des besoins réels de l'utilisateur. Si vous écrivez des histoires d'utilisateurs comme des hypothèses sur ce que les utilisateurs veulent sans mener des études de marché préliminaires, vous risquez l'échec du projet, car le produit ne sera tout simplement pas quelque chose dont les gens ont besoin. Rappelez-vous donc toujours de donner une oreille aux vrais consommateurs finaux.
Manque de contexte. Les histoires d'utilisateurs peuvent parfois être trop vagues ou incomplètes et ne peuvent certainement pas être utilisées pour rédiger une documentation formelle. Cependant, c'est leur essence car ils sont censés être une invitation à la discussion.
Omission de prescriptions non fonctionnelles. Les histoires d'utilisateurs sont toutes d'exigences fonctionnelles. Les exigences non fonctionnelles sont néanmoins importantes et doivent également être prises en charge.
Absence de directives techniques. Les histoires d'utilisateurs ne disent pas aux développeurs comment construire la fonctionnalité (ce qui peut être un problème pour les ingénieurs inexpérimentés). Au lieu de cela, l'équipe doit devenir créative, développer une vision commune, et écrire des cas d'utilisation et des critères d'acceptation qui serviront de lignes directrices précises.
Les expériences d'utilisateurs aident à résoudre les problèmes des utilisateurs finaux et à recentrer les équipes de développement, de l'écriture de code abstrait à la satisfaction des besoins des personnes qui interagissent réellement avec le produit. Ils encouragent également la créativité et la collaboration entre les différentes parties prenantes. Considérez donc nos recommandations et mettez en œuvre des histoires d'utilisateurs dans votre projet afin d'accroître l'efficacité et de créer des produits qui apportent une réelle valeur à vos clients.
