Definire le User Story e lo Sviluppo Agile
Un principio fondamentale dei moderni processi di sviluppo è lo sviluppo agile . Questa metodologia di sviluppo sottolinea l'utilizzo di storie utente piccole e di dimensioni ridotte per definire cosa fa un sistema dal punto di vista dell'utente, non da quello tecnico. Un utente si preoccupa se un prodotto è veloce, facile da usare e risolve il suo problema. A loro non importa se segue un'architettura a 3 livelli, ha Mongo DB o se utilizza Rails o Asp.net.
Storie degli utenti:
- Sono facili da capire e chiunque può partecipare
- Lavora in modo iterativo; possono e devono essere cambiati o modificati frequentemente
- Allinea sviluppatori, utenti e specialisti aziendali su obiettivi e aspettative comuni
- Sono molto più facili da leggere rispetto ai documenti dei requisiti di 400 pagine
Storyboard That fornisce una piattaforma ideale per creare storie utente agili e stimolare la conversazione in un formato molto meno oneroso di un muro di testo.
Epico
Nel contesto delle storie utente, un "epopea" è semplicemente una storia molto ampia che verrà successivamente suddivisa in molte storie utente specifiche. Iniziare con un'epopea allinea tutti con un'unica visione di alto livello. La storia epica àncora un progetto dall'alto verso il basso, e se non ha senso costruire un'epopea, anche il lavoro di supporto sarà uno spreco di energie.
In questa storia, è molto chiaro qual è la visione a lungo termine e come dovrebbe essere il successo. Una buona storia epica dovrebbe includere:
- Impostazione o contesto
- Attori o utenti
- Traguardi e obbiettivi
- Attività ed eventi
Definizione degli utenti
Soprattutto quando si progetta un software, è importante avere una buona visione di come saranno gli utenti. Non tutti gli utenti corrisponderanno esattamente a questa visione e potrebbero esserci più categorie di utenti, ma queste visioni discrete richiedono un'articolazione. Pensare agli utenti prima di tutto protegge dall'eccesso di ingegneria e di complicazione, impedendo a un nuovo prodotto di avere qualcosa per tutti e di non essere utile a nessuno.
Creare una Storia
Una volta stabilita un'epopea e definiti gli utenti, è possibile costruire storie più piccole e specifiche su particolari esperienze utente. Le storie seguenti suddividono quanto descritto sopra in due narrazioni: cercare un ordine e riordinare un prodotto.
Queste narrazioni non contengono informazioni tecniche; agli utenti non interessa come vengono raggiunti i risultati, purché svolga i compiti desiderati. Allo stesso modo, la UX è rappresentata genericamente, per evitare di soffocare l'innovazione o forzare un percorso. In generale, le storie dovrebbero essere:
- Piccolo – Lavoro sotto i 10 giorni
- Prezioso: una volta completato, dovrebbe fornire qualcosa di utilizzabile
- Stimabile – In grado di creare una stima approssimativa di quanto sforzo è coinvolto
Ricerca di un ordine
Eseguire un riordino
Conversazione e pianificazione per i test
Queste storie dovrebbero invitare alla conversazione e alle domande, come:
- Sono queste le storie giuste per abbinare la nostra epopea?
- Quali altre storie dovrebbero essere create?
- Queste storie sono coerenti con ciò che sappiamo dei nostri utenti?
È perfettamente ragionevole creare molte storie; anzi, dovrebbe essere incoraggiato. Alcune di queste storie non verranno mai utilizzate, ma è importante vedere il percorso che hanno tracciato. Questa raccolta di storie eliminerà requisiti aggiuntivi e influenzerà i test.
Le storie dovrebbero provocare e informare la discussione su come verrà testato il software e quali regole aziendali devono essere definite in modo esplicito. Per esempio:
- Quanto deve essere veloce una ricerca?
- C'è un limite di tempo per i riordini?
- Cosa dovrebbe fare il sistema se si tratta del secondo riordino? Quinto?
- Quali test e domande di follow-up avresti?
© 2024 - Clever Prototypes, LLC - Tutti i diritti riservati.
StoryboardThat è un marchio di Clever Prototypes , LLC e registrato presso l'ufficio brevetti e marchi degli Stati Uniti