Histoires D'utilisateurs et Développement Agile

Définir les User Stories et le Développement Agile

Un principe de base des processus de développement modernes est le développement agile . Cette méthodologie de développement met l'accent sur l'utilisation de petites histoires d'utilisateurs pour définir ce qu'un système fait du point de vue de l'utilisateur, et non d'un point de vue technique. Un utilisateur se soucie de savoir si un produit est rapide, facile à utiliser et résout son problème. Ils ne se soucient pas de savoir s'il suit une architecture à 3 niveaux, a Mongo DB, ou s'il utilise Rails ou Asp.net.

Histoires d'utilisateurs:

• Sont faciles à comprendre, et tout le monde peut participer
• Travailler de manière itérative ; ils peuvent et doivent être changés ou amendés fréquemment
• Aligner les développeurs, les utilisateurs et les spécialistes métier autour d'objectifs et d'attentes communs
• Sont beaucoup plus faciles à lire que les documents d'exigences de 400 pages

Storyboard That fournit une plate-forme idéale pour créer des histoires d'utilisateurs agiles et déclencher une conversation dans un format beaucoup moins exigeant qu'un mur de texte.

Épique

Dans le contexte des histoires d'utilisateurs, une « épopée » est simplement une histoire très large qui sera ensuite décomposée en plusieurs histoires d'utilisateurs spécifiques. Commencer par une épopée aligne tout le monde sur une vision unique et de haut niveau. L'histoire épique ancre un projet de haut en bas, et si cela n'a pas de sens de construire une épopée, le travail de soutien sera également un gaspillage d'efforts.

Dans cette histoire, il est très clair quelle est la vision à long terme et à quoi devrait ressembler le succès. Une bonne histoire épique devrait inclure :

• Cadre ou contexte
• Acteurs ou utilisateurs
• Buts et objectifs
• Activités et événements

Définition des utilisateurs

Surtout lors de la conception d'un logiciel, il est important d'avoir une bonne vision de ce que seront les utilisateurs. Tous les utilisateurs ne correspondront pas précisément à cette vision, et il peut y avoir plusieurs catégories d'utilisateurs, mais ces visions discrètes ont besoin d'être articulées. Penser aux utilisateurs d'abord se prémunit contre la sur-ingénierie et la sur-complication, empêchant un nouveau produit d'avoir quelque chose pour tout le monde et d'être utile à personne.

Créer une histoire

Une fois qu'une épopée a été établie et que les utilisateurs ont été définis, des histoires plus petites et plus spécifiques peuvent être construites sur des expériences d'utilisateurs particulières. Les histoires ci-dessous décomposent les éléments décrits ci-dessus en deux récits : rechercher une commande et commander à nouveau un produit.

Ces récits ne contiennent pas d'informations techniques ; les utilisateurs ne se soucient pas de la façon dont les résultats sont obtenus, tant qu'il effectue les tâches souhaitées. De même, l'UX est dépeint de manière générique, pour éviter d'étouffer l'innovation ou de forcer un chemin. En général, les histoires devraient être :

• Petit – Moins de 10 jours de travail
• Précieux - Une fois terminé, ils devraient fournir quelque chose d'utilisable
• Estimable - Capable de créer une estimation approximative de l'effort requis

Rechercher une commande

Exécution d'une commande

Conversation et planification des tests

Ces histoires devraient inviter à la conversation et aux questions, telles que :

• Sont-ce les bonnes histoires pour correspondre à notre épopée?
• Quelles autres histoires faut-il créer ?
• Ces histoires correspondent-elles à ce que nous savons de nos utilisateurs ?

Il est parfaitement raisonnable de créer de nombreuses histoires ; en fait, il faut l'encourager. Certaines de ces histoires ne seront jamais utilisées, mais il est important de voir le chemin qu'elles ont tracé. Cette collection d'histoires éliminera les exigences supplémentaires et influencera les tests.

Les histoires doivent provoquer et informer la discussion sur la façon dont le logiciel sera testé et sur les règles métier qui doivent être explicitement définies. Par exemple:

• Quelle doit être la vitesse d'une recherche ?
• Y a-t-il une limite de temps pour les commandes?
• Que doit faire le système s'il s'agit de la deuxième commande ? Cinquième?
• Quels tests et questions de suivi auriez-vous?

Questions fréquemment posées sur les User Stories et le développement Agile

What is an agile user story?

An agile user story is a simple, clear description of a software feature from a user's perspective. It focuses on what the user wants to achieve, not technical details, making development more user-centered.

How do I create effective user stories for my class projects?

To create effective user stories, start with a high-level epic, define your users, and break down tasks into small, achievable goals. Use clear language and focus on real user needs instead of technical solutions.

Why are user stories important in agile development?

User stories are crucial in agile development because they help align developers, users, and stakeholders around shared goals, encourage frequent feedback, and make projects easier to manage and understand.

What is the difference between an epic and a user story?

An epic is a broad, overarching story that sets the project's vision. A user story is a smaller, specific task or feature derived from the epic, focused on a single user need.

How can storyboards help teach agile user stories to students?

Storyboards visually illustrate user stories, making concepts easier to grasp for students. They spark conversation, clarify requirements, and encourage participation in agile planning activities.