Ricerca
  • Ricerca
  • I Miei Storyboard
https://sbt-www-us-east-v3.azurewebsites.net/it/articles/b/agile-user-storie

Definire le User Story e lo Sviluppo Agile

Usa gli storyboard per spiegare i processi e l'interazione con i clienti

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.

Customer Care Generic Epic
Customer Care Generic Epic

Crea una User Story Agile*

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.

Acme Corp. Users
Acme Corp. Users

Crea una User Story Agile*

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

Acme Corp. - Looking up an Order
Acme Corp. - Looking up an Order

Crea una User Story Agile*

Eseguire un riordino

Acme Corp. Replacement Order
Acme Corp. Replacement Order

Crea una User Story Agile*

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?


Scopri Storyboard That 's Guida illustrata allo sviluppo del prodotto sul cliente Journey Mapping!
*(Avvia una prova gratuita di 2 settimane senza bisogno di carta di credito)
https://sbt-www-us-east-v3.azurewebsites.net/it/articles/b/agile-user-storie
© 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