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?
© 2024 - Clever Prototypes, LLC - Tous les droits sont réservés.
StoryboardThat est une marque déposée de Clever Prototypes , LLC , et enregistrée auprès du US Patent and Trademark Office