Una delle maggiori sfide nello sviluppo del software è il compito quasi impossibile di raccogliere requisiti chiari e quindi ottenere che tali requisiti rimangano invariati durante lo sviluppo del codice. Nell’approccio a cascata allo sviluppo del software, nonostante gli sforzi per definire, documentare e approvare ogni possibile contingenza prima dell’inizio dello sviluppo, il prodotto consegnato è raramente ciò che il cliente desidera.
L’alternativa agile? Creazione storia utente.,
Uno dei maggiori vantaggi dell’utilizzo di un approccio agile allo sviluppo del software è che i requisiti non sono scolpiti nella pietra, ma dovrebbero invece cambiare, con un feedback costante da parte degli stakeholder e dell’azienda. Metodologie agili come Scrum e Extreme Programming (XP) sostituiscono i tradizionali e lunghi documenti sui requisiti con un product backlog con priorità costituito da storie utente concise, i cui dettagli emergono più vicini a quando la storia è pronta per essere implementata.,
Sebbene la creazione di storie utente sia più arte che scienza, questo tutorial ti fornirà le informazioni, gli esempi e i passaggi necessari per creare storie utente di alta qualità.
La storia delle storie utente
XP ha introdotto per la prima volta il concetto di storie utente nel 1998, confrontandole con casi d’uso. In Object-Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson ha introdotto i casi d’uso come un modo per documentare i requisiti definendo le interazioni tra un ruolo (una persona che utilizza il sistema) e il sistema stesso per raggiungere un obiettivo utilizzando il Unified Modeling Language (UML).,
Questo approccio era popolare nello sviluppo orientato agli oggetti ed è ancora usato come processo chiave nei framework di sviluppo software, come il Processo unificato (UP), l’IBM Rational Unified Process (RUP) e l’Oracle Unified Method (OUM). L’utilizzo dei casi d’uso, piuttosto che delle storie degli utenti, consente uno sviluppo iterativo e incrementale ed è considerato un approccio agile alla definizione dei requisiti.,
Con l’introduzione delle storie utente molto più brevi e la popolarità di XP e Scrum, un product backlog composto da storie utente è diventato l’approccio più comunemente noto alla definizione dei requisiti agili. Molti professionisti pensano ancora che le storie degli utenti siano l’unico approccio agile accettabile. Tuttavia, Alistair Cockburn, uno dei firmatari del Manifesto Agile, preferisce i casi d’uso alle storie degli utenti.
Sebbene ci siano molte opinioni forti sul significato di “agile”, sia i casi d’uso che le storie degli utenti sono compatibili con questo approccio., Alcuni dicono che le storie degli utenti alla fine diventano simili ai casi d’uso una volta che il team concorda sui dettagli dell’implementazione. Nelle fasi iniziali, la storia utente è semplicemente una breve frase, ma non è completa fino a quando i dettagli e i criteri di accettazione non sono definiti.
Creazione di storie utente
Ci sono opinioni diverse sulla definizione di una storia utente e su come crearne una al meglio., Alcune linee guida per una buona storia utente sono i seguenti:
- dovrebbe essere scritto da qualcuno che rappresenta gli utenti business (di solito il proprietario del prodotto)
- Si, inizialmente, dovrebbe includere una breve descrizione del “chi, che cosa, e perché,”ma non il “come”
- dovrebbe produrre una fetta verticale del codice di lavoro
- dovrebbe essere abbastanza piccolo che può essere codificata e testato in una iterazione (di solito uno-a-periodo di quattro settimane)
Vari modelli, le tecniche e gli acronimi sono utilizzati per aiutare i proprietari di prodotti di scrivere storie utente., Tre delle tecniche più comuni sono il modello role-feature-reason, le tre C (card, conversation, confirmation) e INVEST (independent, negotiable, valuable, estimable, small, testable).
Esempi
Supponiamo che tu stia sviluppando un’applicazione che consenta ai formatori di caricare materiale didattico e attirare studenti interessati a frequentare una classe. Ecco come applicare le tecniche di storia utente.,
Role-Feature-Reason
Come spiega Mike Cohn di Mountain Goat Software, il modello role-feature-reason, o RGB (role, goal, benefit), assomiglia a questo:
“Come voglio così .”
Anche se ci sono variazioni, questa struttura breve frase mantiene l’attenzione sul chi, cosa, e perché. Ciò impedisce al proprietario del prodotto di fornire al team di sviluppo troppe informazioni su come implementare una soluzione. Concentrandosi su chi, cosa e perché, il team di sviluppo ha il potere di trovare la migliore soluzione tecnica.,
Esempio 1: Fornire a un formatore la possibilità di aggiungere un corso
Come formatore, mi piacerebbe essere in grado di aggiungere un nuovo corso, in modo da avere il potenziale per attirare nuovi studenti.
Esempio 2: Fornire a uno studente la possibilità di cercare un corso
Come studente, mi piacerebbe essere in grado di cercare le offerte dei corsi, in modo da essere in grado di trovare un’offerta che mi interessa di più.
Il ruolo (chi)
Il ruolo descrive chi trarrà beneficio da questa funzione. Si noti che il ruolo non è semplicemente ” l’utente.,”Ci sono diversi tipi di utenti, quindi vogliamo che il ruolo sia più specifico di “utente” ma descriva il tipo di utente che trarrà beneficio dalla storia. I proprietari di prodotti sono spesso incaricati di entrare nella mente dei loro utenti per capire cosa sarebbe più prezioso per loro.
Esempio 1 Role = trainer
Esempio 2 Role = student
La caratteristica (cosa)
Questo passaggio descrive molto brevemente ciò che l’utente vuole. Questo rappresenta più da vicino il requisito che descrivi nello sviluppo di software tradizionale., Tuttavia, si desidera fare attenzione a non essere troppo specifici o descrivere come scrivere il codice. Ciò verrà determinato alla fine, ma non quando si crea per la prima volta la storia dell’utente. La storia dell’utente dovrebbe essere scritta dal punto di vista dell’utente che trarrà beneficio dalla funzione, non dal punto di vista dello sviluppatore che la codificherà.
Esempio 1 Feature = aggiungi un nuovo corso
Esempio 2 Feature = cerca le offerte dei corsi
Il motivo (perché)
Infine, vogliamo indicare perché l’utente vuole questa funzione. Quale valore otterrà l’utente da esso?, Questo aiuta il proprietario del prodotto a valutare come dare priorità alla storia utente nel backlog. Se il valore o il beneficio non possono essere articolati, potrebbe essere qualcosa che non è necessario. Comprendere il valore spesso aiuta il team di sviluppo a trovare modi innovativi per implementare il codice al fine di risolvere l’obiettivo—modi che possono essere diversi da ciò che il proprietario del prodotto ha in mente.,
Esempio 1 Motivo = attrarre nuovi studenti
Esempio 2 Motivo = trovare un’offerta che mi interessa di più
Le Tre C: Card, Conversation, Confirmation
La formula delle Tre C, sviluppata da Ron Jeffries, aiuta a raggiungere un accordo tra l’azienda e il team tecnico sul significato della user story. I tre C li guidano attraverso l’elaborazione progressiva di una storia, da una breve dichiarazione a una storia utente completamente sviluppata.,
Scheda
La storia dell’utente inizia volutamente breve, con una semplice dichiarazione che potrebbe adattarsi a una scheda indice 3×5, in genere seguendo il formato ruolo-funzione-beneficio che ho appena coperto. Ad esempio:
Come formatore, mi piacerebbe essere in grado di aggiungere un nuovo corso, in modo da avere il potenziale per attirare nuovi studenti.
Conversazione
Sebbene la storia dell’utente inizi come una semplice dichiarazione, i dettagli devono emergere prima che il team inizi a lavorare sulla storia., Invece di descrivere ciò che è necessario nella documentazione, il team includerà 1) la rappresentazione dell’azienda (di solito il proprietario del prodotto) e 2) il team di sviluppo stesso, inclusi sviluppatori, tester, analisti aziendali o chiunque altro nel team.
Questa conversazione consente al team di sviluppo di porre domande per assicurarsi di avere una chiara comprensione di ciò che viene richiesto e del valore fornito. Ad esempio:
Sviluppatore: il formatore dovrà caricare il materiale didattico su un sito web?,
Product owner: No, il formatore aggiungerà solo informazioni sul corso che verrà offerto e la funzione dovrebbe includere un modo per lo studente di entrare in una lista di interessi. Questa storia dà al formatore la possibilità di pubblicizzare un corso.
Sviluppatore: Quali campi dovrebbero essere inclusi?
Product owner: Titolo del corso, abstract, date e orari, posizione.
Sviluppatore: Questo sarà solo per la pubblicità di lezioni faccia a faccia?
Proprietario del prodotto: Sì., Potremmo aggiungere un’opzione di classe virtuale in seguito, ma questa storia riguarderà solo l’aggiunta di informazioni sul corso per le offerte di classe faccia a faccia.
Sviluppatore: Quali informazioni dovrebbero essere raccolte quando un potenziale studente chiede di entrare in una lista di interessi?
Proprietario del prodotto: Nome, numero di telefono e indirizzo email.
Il team aggiornerà la storia utente con le informazioni raccolte dalla conversazione e discuterà l’implementazione—o il “come”—che spesso crea compiti specifici che devono essere eseguiti per completare la storia., Sebbene la storia dell’utente sia scritta dal punto di vista dell’utente, il team di sviluppo scrive le attività per gli sviluppatori e include i dettagli tecnici dell’implementazione.
Conferma
Il team di sviluppo deve avere una chiara comprensione di come la funzione funzionerà in diverse situazioni, incluse le condizioni di errore. Hanno bisogno di ottenere conferma per quanto riguarda i criteri di accettazione da parte del proprietario del prodotto. Questi sono i criteri che devono essere soddisfatti perché la storia sia considerata fatta e accettata., Ecco un esempio di criteri di accettazione:
- Un allenatore è in grado di aggiungere un nuovo corso inserendo titolo del corso, abstract, date e orari, e la posizione di un modulo e premere un pulsante “aggiungi corso”.
- Se mancano campi o date o orari non validi, verranno visualizzati messaggi di errore.
- Una volta che il corso è stato correttamente aggiunto, verrà visualizzato pubblicamente sul sito web del corso e ci sarà un pulsante per uno studente per esprimere interesse.,
- Il pulsante di interesse consente all’utente di inserire nome, indirizzo email e numero di telefono, e questi dati verranno memorizzati e associati al nuovo corso.
INVEST: Gli attributi di una solida user story
INVEST è un acronimo che aiuta a valutare se si dispone di una user story di alta qualità. Ecco come gli attributi nell’acronimo si applicano alla storia su cui abbiamo lavorato.
I = Independent-Questa storia può essere completata dal team? Vogliamo che il team sia in grado di completare l’intera storia piuttosto che dipendere da un team diverso per fare la GUI, ad esempio.,
N = Negoziabile—La storia non è così dettagliata da descrivere esattamente per quanto tempo dovrebbero essere i campi o fornire specifiche sui formati di data e simili. Molto probabilmente ci saranno routine o librerie comuni che permetteranno al team di sviluppo di implementare nel modo che ha più senso per loro.
V = Prezioso-Il proprietario del prodotto descrive che il valore ricercato è la capacità per il formatore di essere in grado di pubblicizzare le classi imminenti. Questo è chiaro nel “perché” della dichiarazione originale e ri-sottolineato nella conversazione.,
E = Estimable—Il team farà abbastanza domande e raccogliere i dettagli per sentirsi sicuri nella loro capacità di stimare la storia.
S = Small—Il team deve sentirsi sicuro che saranno in grado di completare la storia in uno sprint. Se non lo fanno, potrebbero dividere la storia. Ad esempio, nella nostra storia di esempio, possono decidere di rendere la capacità di raccogliere le informazioni degli studenti una storia diversa e semplicemente visualizzare le informazioni sulla classe per questa storia.
T = Testable – Con criteri di accettazione chiari, è possibile testare sia il percorso felice che le condizioni di errore.,
Allineamento a una visione
Ho coperto le basi della creazione di una storia utente, ma è comunque necessario comprendere il quadro generale prima di creare le proprie storie utente. C’è molto lavoro che devi fare in anticipo, a un livello più alto, per determinare quali sono le caratteristiche di valore più alto che dovrebbero essere consegnate ai clienti. Questi sono in definitiva scomposti in storie degli utenti.
È importante che il team comprenda prima la visione di alto livello e si assicuri che le funzionalità, e in definitiva le storie degli utenti, si allineino a quella visione di alto livello.,
In genere, si suddivide il prodotto in raggruppamenti che vanno da nomi come “temi” o “caratteristiche.”Sebbene l’etichettatura di questi elementi di backlog possa differire a seconda del metodo agile e degli strumenti utilizzati per descriverli, l’idea è di assicurarsi che si allineino in modo che il lavoro possa essere ricondotto alla tua visione, il che garantirà il raggiungimento degli obiettivi e dei valori della visione del prodotto.
Ancora una volta, non avviare un progetto creando storie utente; inizia creando una visione., Per il nostro esempio, mostro semplicemente una dichiarazione di visione di esempio, che porta ad alcune funzionalità di esempio, che possono essere ulteriormente scomposte in storie utente.
Vision
Fornire un sito web di alta qualità che consentirà ai formatori di pubblicizzare i corsi e consentire agli studenti di seguire quei corsi.
Caratteristiche
- Fornire una pagina di offerta del corso che permetterà agli studenti di iscriversi ai corsi.
- Fornire una home page che dirà agli utenti ciò che il nostro sito è tutto.
- Fornire un processo di registrazione che consente agli utenti di accedere, creare un profilo, e tenere traccia delle loro classi.,
- Fornire un blog che vi aiuterà a pubblicizzare le nostre offerte e guadagnare pubblicità per il nostro sito web.
User stories
- Fornire trainer con la possibilità di aggiungere un corso sulla pagina offerta corso.
- Fornire agli studenti la possibilità di cercare un corso.
Nell’esempio sopra, puoi vedere come sono nate le storie degli utenti. Le storie degli utenti facevano parte di una funzione per “fornire una pagina di offerta di corsi” che si allinea alla visione di alto livello.,
Impact mapping
Sebbene l’allineamento a una visione ti aiuti a popolare il tuo backlog iniziale, non è l’unico modo per farlo. Ci sono molti strumenti e tecniche che i product manager possono utilizzare per creare le storie che vanno in un nuovo backlog e che si allineano con la visione.
Una tecnica di pianificazione strategica utilizzata per aiutare a comprendere il quadro generale, impact mapping, è stata resa popolare da Gojko Adzic, autore di cinquanta idee rapide per migliorare le storie degli utenti e Impact Mapping: fare un grande impatto con i prodotti software e progetti., Impact mapping è una mappa mentale che inizia con l’obiettivo, che dovrebbe affrontare la questione del valore e perché si sta costruendo il prodotto.
Il livello successivo elenca gli “attori” o le persone che aiuteranno a raggiungere l’obiettivo. Successivamente, la mappa elenca i comportamenti, o “impatti”, che gli attori eseguiranno per contribuire a raggiungere tale obiettivo. Il livello finale della mappa presenta i “deliverable” che il team può implementare. Questi consentono e supportano gli attori a creare gli impatti desiderati. È da questi risultati finali che derivano le caratteristiche e le storie del software.,
- Obiettivo: Rendere ampiamente disponibili corsi che gli studenti vorranno prendere
- Attori: Formatori, studenti
- Impatti: gli Allenatori di fornire alta qualità, le classi che sono di interesse per gli studenti; gli studenti potranno fornire i rinvii e le raccomandazioni
- Prodotti: Alta qualità, le classi sono accessibili agli studenti
- Potenziale storie:
- “Come allenatore, voglio pubblicizzare classi, in modo che io possa ottenere gli studenti.
- “Come allenatore, voglio ottenere feedback dagli studenti, in modo da poter migliorare continuamente.,”
- ” Come allenatore, voglio scoprire cosa vogliono gli studenti, in modo da poter aggiungere al mio curriculum.”
- ” Come studente, voglio trovare le classi che più mi interessano.”
- ” Come studente, voglio trovare classi che sono in grado di prendere online, in modo che non avrò bisogno di viaggiare.”
- ” Come studente, voglio leggere le recensioni degli altri, in modo da poter decidere quali classi mi si adattano meglio.”
La mappatura delle storie degli utenti in questo modo consente la tracciabilità nel processo di pensiero di come le storie alla fine creano valore e come le usi per raggiungere l’obiettivo finale., L’idea non è di implementare tutto, ma di trovare il percorso più breve attraverso la mappa per raggiungere il tuo obiettivo.
Dividere le storie
Uno dei problemi più comuni in cui i team agile si imbattono è quando le storie sono troppo grandi e non possono essere completate in un’iterazione. Quando il team crea le attività associate alla storia, si rendono conto che ci sono troppe incognite o che le attività coinvolte richiederanno più tempo di quanto il team abbia a disposizione in una singola iterazione. Le squadre a volte affrontano questo problema dividendo una storia più grande in storie più piccole.,
Ricorda, tuttavia, che vuoi che una storia utente fornisca software funzionante che aggiunga valore all’utente. Invece di creare una storia utente che completerà solo parzialmente una funzione, dividere le storie in” sezioni verticali ” che forniranno funzionalità end-to-end.
Rivolgiti alla community per un apprendimento più approfondito
Soluzioni dettagliate su come risolvere i problemi più difficili relativi ai requisiti e alle storie degli utenti sono uniche per ogni situazione. Tuttavia, una caratteristica comune dei professionisti agili di successo è che sono desiderosi di aiutare gli altri e condividere ciò che sanno.,
Il sito web userStories di Cohn consente a coloro che lavorano con product backlog e user stories di condividere prodotti, risorse e conoscenze. La pagina dei prodotti include un impressionante elenco di strumenti, molti disponibili gratuitamente, con opportunità di recensioni e input degli utenti. Cohn nota sul sito che spera di espandere il sito in modo che i backlog di prodotto possano essere condivisi.
Non ci sarà mai una risposta unica su come scrivere storie utente perfette., Tuttavia, nel tempo, con un sano mix di esperienza, consigli degli esperti e sperimentazione con strumenti e tecniche suggerite, è possibile migliorare continuamente.