Che cos'è una user story?
Secondo uno degli iniziatori del movimento Agile Alistair Cockburn, "Un cartellino con una story è una promessa di conversazione." In particolare, è una conversazione con il cliente che comporta una descrizione di una funzione software dal suo punto di vista. La base di una user story è questa: una parte essenziale del ciclo di vita dello sviluppo software Agile e Lean. Temi, iniziative, epic e story sono tutti mattoni, da grandi a piccoli, che aiutano a organizzare la funzionalità necessaria per costruire una soluzione software incentrata sull'utente. I termini possono suonare familiari dal punto di vista letterario, e a ragione. Una user story è una semplice narrazione, mentre story correlate costituiscono un racconto. Ecco come questi termini sono correlati:
Temi: uno scopo ambizioso o un obiettivo di alto livello.
Iniziativa: una raccolta di epic che aiuterà a raggiungere l'obiettivo principale.
Epic: una user story di livello aziendale o di grandi dimensioni. Sono difficili da implementare in un'unica iterazione, quindi vengono suddivise in story più piccole. Un'epic intera è solitamente inclusa in un singolo rilascio.
User story: brevi requisiti o scenari utente che forniscono un certo valore e vengono scritti dalla prospettiva dell'utente. Ogni story è limitata da uno sprint o da un'iterazione.
Ecco un esempio:
Il tema (completamente a sinistra) è l'obiettivo aziendale di alto livello, che è composto da iniziative associate, epic a supporto di tali iniziative e user story (completamente a destra) che descrivono requisiti granulari.
Un'organizzazione di sviluppo software può avere l'obiettivo di modernizzare la propria soluzione. Per portare a termine questo compito, deve offrire un'esperienza utente memorabile. Ad esempio, l'esperienza utente deve fornire un'interfaccia web moderna, esecuzione rapida e possibilità di lavorare su diversi dispositivi utente. In questo scenario, ciascuna di queste epic sarà suddivisa in user story specifiche.
Che cos'è una user story dell'epic?
Un'epic è una user story di livello aziendale o di grandi dimensioni. Le epic sono troppo complesse da implementare in un'unica iterazione o sprint, quindi vengono suddivise in story più piccole. Il vantaggio delle epic è la capacità di sviluppare e collaborare su idee più grandi prima di creare numerose user story. L'epic può essere mantenuta come l'idea originale, creando un punto di riferimento futuro.
Qual è lo scopo di una user story?
Una user story è pensata per favorire lo sviluppo di una soluzione software. Purtroppo non è raro sviluppare una soluzione software che semplicemente non si rivolge alla base di clienti prevista. Le user story sono concepite per mitigare questo rischio fornendo una comprensione chiara e approfondita dei requisiti degli utenti finali che assicurano che le funzioni software soddisfino le aspettative.
In che modo le aziende utilizzano le user story?
Le user story sono uno dei principali artefatti utilizzati nello sviluppo Agile. Vengono create per descrivere funzionalità e caratteristiche non funzionali e creare un elenco prioritario di funzionalità previste per lo sviluppo. Questo elenco è chiamato backlog di prodotto.
Le user story fanno parte di una mappa di user story, un metodo utilizzato per ordinare le user story lungo un asse orizzontale e verticale per rappresentare diversi livelli di usabilità. L'asse orizzontale procede attraverso le attività che spiegano come l'utente interagisce con il sistema per eseguire una funzione. L'asse verticale rappresenta un aumento dei livelli di complessità. La prima riga è una rappresentazione fondamentale della funzione. La riga successiva aggiunge una piccola funzionalità e così via. Ogni user story viene associata a uno story point o a una stima teorica di sforzi o difficoltà per sviluppare la funzionalità. Molte organizzazioni utilizzano strumenti di mappatura automatica delle story. I più popolari strumenti sono Jira, Rally by CA, StoryOnBoard e FeatureMap.
Modello di user story
Puoi anche utilizzare questo modello per creare la tua mappa di story. È possibile completare il modello utilizzando Microsoft Word o ricrearlo utilizzando i post-it da applicare su una parete. Regola il numero di caselle in base alle esigenze di sviluppo della tua azienda.
Scarica il modello in formato Word
Quali sono le caratteristiche di una user story?
Indipendentemente dal framework Agile utilizzato, Extreme Programming (XP), Kanban, DAD (Disciplined Agile Delivery), AMDD o Scrum, le user story sono uguali. La user story descrive il tipo di utente: la persona, la funzione che desidera e il vantaggio che si aspetta di ottenere dalla funzione. Una user story valida viene scritta a seguito della struttura di funzione del ruolo (RGB):
In qualità di
La user story dovrebbe avere le seguenti qualità:
Essere completa abbastanza da dimostrare il valore per l'utente.
Essere incentrata sugli utenti.
Iniziare con un'epic.
Essere breve, semplice e chiara.
Contenere file di supporto e documentazione, se necessario.
Essere completa abbastanza da dimostrare il valore, ma abbastanza semplice da sviluppare in un'unica iterazione.
Essere scritta in base all'input di tutte le parti interessate.
Essere flessibile e negoziabile senza influire su altre user story o funzioni.
Essere facile da testare.
Includere criteri di accettazione (condizioni di soddisfazione) per i tester.
I termini user story e requisiti di sistema potrebbero essere utilizzati in modo intercambiabile. Tradizionalmente, lo sviluppo Waterfall utilizza i requisiti di sistema per definire come una soluzione software dovrebbe funzionare. Entrano in dettagli approfonditi che comprendono rischi, ambito e altre linee guida specifiche per lo sviluppo. Le user story, d'altra parte, sono semplici, favoriscono la discussione e supportano la metodologia di sviluppo Agile, che adotta la collaborazione e il cambiamento.
Come già detto, le user story devono essere semplici ma complete. Ad esempio, una buona user story potrebbe essere questa:
Come cliente bancario, voglio essere in grado di depositare un assegno online, in modo da non dovermi recare in banca.
Ecco un esempio di user story che è troppo dettagliata:
Come cliente bancario, voglio essere in grado di depositare un assegno online, vedere e stampare i report di saldo passati, in modo da non dovermi recare in banca.
Che cos'è uno story point?
Ogni user story viene associata a uno story point, una misurazione dello sforzo o della difficoltà necessaria per lo sviluppo e l'implementazione. I team possono utilizzare numeri singoli (1, 2, 3), più cifre (100, 200, 300), o qualsiasi altro formato di numero scelto. Il rapporto è il fattore importante. Ad esempio, una story che viene assegnata a 200 story point richiederà due volte lo sforzo assegnato a 100 story point.
Che cos'è un criterio di accettazione dell'utente?
I criteri di accettazione, conosciuti anche come condizioni di soddisfazione, assicurano che la soluzione software soddisfi le esigenze degli utenti finali o delle parti interessate. Questi criteri possono includere requisiti di prestazione, standard, scenari e regole del comportamento del sistema. Il team di test utilizza i criteri di accettazione per verificare che lo sviluppo sia completato. Una volta raggiunti questi parametri, la storia o la funzione viene considerata "completata".
Come scrivere una user story efficace
Scrivere le tue prime user story può essere difficile, soprattutto perché sono la base per la funzionalità del tuo prodotto. Le user story vengono più comunemente sviluppate durante la fase iniziale dello sviluppo e utilizzate nella pianificazione delle iterazioni e degli sprint, ma possono essere create in qualsiasi momento (all'inizio, per fornire una portata all'intero progetto/soluzione; in corso d'opera, per identificare nuove user story, rimuovere user story non necessarie e suddividere le user story in parti più piccole; in fase di transizione) e aggiunte al backlog per l'iterazione successiva.
I seguenti 10 suggerimenti ti aiuteranno a creare user story efficaci:
Metti al primo posto l'utente: lo scopo di una user story è dimostrare la funzionalità dal punto di vista di un utente. Assicurati di intervistare o proporre agli utenti sondaggi e includi informazioni oggettive e definite dall'utente. In alcuni casi, l'utente potrebbe non essere una persona, ma piuttosto un sistema.
Definisci le persone: comprendere i tuoi utenti è un elemento essenziale per scrivere una user story. Crea caratteri fittizi che rappresentano i tuoi utenti finali target (possono includere consumatori, acquirenti, contabili, professionisti HR). I comportamenti di acquisto, i problemi che stanno cercando di risolvere e gli obiettivi generali sono tutti elementi importanti di informazioni da avere sul cliente ideale. Utilizza questi nomi di persona piuttosto che il ruolo generico dell'utente quando scrivi le tue user story.
Collabora: assicurati di raccogliere tutte le parti interessate pertinenti in una stanza per collaborare durante la creazione di una user story. Gestione dei prodotti, ingegneri/sviluppatori, tester, assistenza clienti, vendita e il cliente devono essere tutti rappresentati.
Mantieni la semplicità: mantieni la storia semplice e chiara. Utilizza una voce attiva e concentrati solo sui fatti importanti.
Inizia con epic e affina: inizia con una user story più ampia per comprendere pienamente la funzionalità complessiva e quindi approfondisci i dettagli della funzione effettiva. Ogni fase di un processo più ampio dovrebbe diventare una story unica. Questo processo consente di rendere la story adatta a un singolo sprint o iterazione.
Includi criteri di accettazione: scrivi criteri di accettazione che definiscono cosa viene considerato "fatto" per quella particolare story. I criteri di accettazione sono il contributo perfetto per i casi di test che il team di test utilizzerà per garantire che la funzione sia pronta per l'utente.
Inizia con cartellini post-it o indice: quando le user story sono emerse come parte di Extreme Programming (XP), venivano raccolte su cartellini semplici. L'utilizzo di questo metodo incoraggia la collaborazione e la discussione, la visibilità e la trasparenza ed è un modo semplice per spostare le cose in un ambiente collaborativo.
Visualizza le user story in un'area accessibile: rendere visibile la user story in un'area accessibile, come una parete o una lavagna, incoraggia la collaborazione durante il progetto di sviluppo. La visualizzazione della story può essere migliorata con diagrammi, modellini, diagrammi di flusso di lavoro, mappe di story e schizzi.
Accogli i feedback: lo sviluppo Agile comprende la flessibilità. Il feedback consente di perfezionare la funzionalità per garantire che il prodotto sia in grado di fornire valore all'utente.
Includi stime di tempo: il tempo necessario per completare lo sviluppo in base a una user story è importante per pianificare iterazioni e rilasci. Le stime di tempo possono aiutare ad assegnare attività e sottoattività ai membri del team.
Esistono due tecniche principali che possono aiutarti a scrivere user story:
Tre C: metodo ideato da Ron Jeffries nel 2001, la formula delle tre C include, un cartellino o un post-it, una conversazione tra gli utenti, gli sviluppatori, i tester e i proprietari dei prodotti sulla funzione e la conferma che l'obiettivo è stato raggiunto.
INVEST: criterio introdotto da Bill Wake nel 2003 e diffuso dal libro Mark Cohn, User Story Applied for Agile Software Development, per valutare il valore di una user story, assicurando che sia indipendente (può essere sviluppata in qualsiasi sequenza), negoziabile, di valore (per un utente o un'azienda), stimabile (per il completamento), piccola (design, test e codice in un'unica iterazione), e testabile.
Per saperne di più sulla scrittura di una user story e per ottenere suggerimenti e modelli per iniziare, leggi How to Write a User Story in Software Development that Actually Focuses on the User (Come scrivere una user story nello sviluppo software effettivamente incentrata sull'utente.
Chi scrive la user story?
Non si tratta necessariamente di chi scrive la user story, ma di chi è coinvolto nel processo di sviluppo della user story. L'obiettivo è una discussione collaborativa che si traduce in una user story. Gestione dei prodotti, ingegneri/sviluppatori, tester, assistenza clienti, vendita e, soprattutto, il cliente devono partecipare al processo. Il product manager o il proprietario del prodotto di solito è titolare delle user story durante il ciclo di vita dello sviluppo.
Qual è la definizione di "Fatto" in Agile?
Ogni team avrà la propria definizione di fatto o completato nello sviluppo Agile e questa definizione può variare in base a ciò che viene valutato per la completezza: una user story, uno sprint o un rilascio completo. Esistono criteri che possono essere inseriti per garantire che una funzione sia veramente completa. La checklist dei criteri può includere i seguenti elementi:
Il codice è stato scritto?
Il codice è stato testato?
La funzione soddisfa i criteri di accettazione?
La funzione si integra e funziona con la soluzione esistente?
Sono state aggiornate le specifiche tecniche del prodotto?
La documentazione del prodotto è stata aggiornata?
I casi d'uso e le user story sono la stessa cosa?
I termini user story e caso d'uso sono simili, ma i casi d'uso contengono molti più dettagli rispetto a una user story. Una user story viene scritta durante una discussione collaborativa e rappresenta la prospettiva di un utente, include l'obiettivo dell'utente e i criteri di accettazione.
I casi d'uso e le user story sono la stessa cosa?
I termini user story e caso d'uso sono simili, ma i casi d'uso contengono molti più dettagli rispetto a una user story. Una user story viene scritta durante una discussione collaborativa e rappresenta la prospettiva di un utente, include l'obiettivo dell'utente e i criteri di accettazione.
Queste stesse informazioni sono incluse in un caso d'uso, ma il caso d'uso va ancora più a fondo e delinea i requisiti funzionali della soluzione, comprese tutte le vie di interazione con l'utente/sistema e i possibili rischi. Molti progetti di sviluppo integrano la creazione di user story, la mappatura di story e i casi d'uso per creare un prodotto completo e accurato.
Esempi di user story, vantaggi e sfide
Le user story sono solitamente scritte in base agli attributi funzionali. Ad esempio: "Come cliente, voglio depositare un assegno elettronicamente, per evitare di andare in banca o presso un ATM." Tuttavia, ci sono caratteristiche non funzionali o vincoli tecnici, che sono anche importanti. Utilizzando questo stesso esempio bancario, puoi scrivere vincoli più tecnici come segue: "Come cliente, voglio depositare 12 assegni con una singola transazione elettronica." Comprendere i dettagli specifici (che potrebbero sembrare più tecnici) consente al team di sviluppo di pensare ai vincoli che potrebbero dover includere in una user story aperta per renderla fattibile.
I modelli di user story e altri modelli Agile sono disponibili qui per il download.
Vantaggi offerti dalle user story
Le user story sono un elemento comune dello sviluppo Agile e il loro corretto utilizzo offre vantaggi a coloro che stanno sviluppando la soluzione e al cliente che usa il software.
Vantaggio per il cliente
Maggiore valore nella soluzione software.
Rapporto positivo e collaborativo con il fornitore.
Maggiore soddisfazione.
Assenza di dettagli tecnici per includere clienti e parti interessate non tecniche.
Focus sulle esigenze dei clienti.
Vantaggio per il fornitore del software
Maggiore vantaggio competitivo.
Collaborazione e cooperazione.
Maggiore trasparenza.
Riduzione dei rischi.
Focus sul valore.
Assenza di modifiche non necessarie al backlog.
Supporto della flessibilità dello sviluppo Agile.
Sfide poste dalle user story
Come per qualsiasi progetto aziendale, ci sono delle sfide da affrontare. Il libro User Stories Applied for Agile Software di Mike Cohn identifica il problema principale nello sviluppo di software con questa semplice osservazione: "I requisiti software sono un problema di comunicazione." Il processo di sviluppo di user story è destinato a risolvere questa sfida, ma l'aumento della comunicazione può sembrare tedioso per alcune parti interessate interne. Sfide poste dalle user story
Tra le sfide aggiuntive troviamo le seguenti:
Garantire che la user story sia completa abbastanza da dimostrare il valore, ma abbastanza semplice da sviluppare in un'unica iterazione.
Concentrarsi su come costruire e includere dettagli tecnici non necessari in questa fase di sviluppo.
Le conversazioni e la collaborazione possono sembrare onerose in termini di tempo e scoraggiare.
Le user story aiutano a far passare le organizzazioni di sviluppo software da un approccio incentrato sui requisiti a un approccio collaborativo e incentrato sull'utente. Sono semplici, trasparenti e dirette e rappresentano le aspettative del cliente. Questa tattica incoraggia le conversazioni tra le parti interessate interne e i clienti, con un prodotto più competitivo che è prezioso per le persone più importanti della tua azienda: gli utenti.
Migliora la visibilità delle user story con Smartsheet per lo sviluppo di software
Potenzia il rendimento dei tuoi dipendenti con una piattaforma flessibile progettata per soddisfare le esigenze del tuo team e capace di adattarsi alle condizioni mutevoli del lavoro. La piattaforma Smartsheet semplifica la pianificazione, l'acquisizione, la gestione e la creazione di report sul lavoro da qualsiasi luogo, aiutando il tuo team a essere più efficace e ottenere di più. Crea report sulle metriche chiave e ottieni visibilità in tempo reale sul lavoro mentre accade con report di riepilogo, pannelli di controllo e flussi di lavoro automatizzati creati per mantenere il tuo team connesso e informato. Quando i team hanno chiarezza sul lavoro da svolgere, possono ottenere maggiori risultati in meno tempo. Prova Smartsheet gratuitamente, oggi.