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.
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.
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.
(Cela va commencer un essai gratuit de 2 semaines - Aucune carte de crédit nécessaire)
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 :
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.
(Cela va commencer un essai gratuit de 2 semaines - Aucune carte de crédit nécessaire)
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 :
(Cela va commencer un essai gratuit de 2 semaines - Aucune carte de crédit nécessaire)
(Cela va commencer un essai gratuit de 2 semaines - Aucune carte de crédit nécessaire)
Ces histoires devraient inviter à la conversation et aux questions, telles que :
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: