Impara a scrivere storie utente migliori
Cosa sono le storie degli utenti?
Una user story è un segnaposto per una conversazione, una o poche frasi utilizzate dai team di sviluppo software Agile per descrivere funzionalità preziose su cui intendono lavorare.
La user story è un mezzo di comunicazione (e un fattore scatenante per ulteriore comunicazione).
Le storie degli utenti sono un mezzo per comunicare in modo sintetico le esigenze funzionali orientate all’utente di software. Sono un modo abbreviato e di alto livello per descrivere i requisiti software. Vengono utilizzati nel lavoro con software Agile e sono progettati per essere uno stimolo per una conversazione. Spesso rappresentano l'unica forma scritta dei requisiti.
Le storie degli utenti dovrebbero essere scritte da qualcuno con una “prospettiva dell’utente” e non una prospettiva tecnica. Dovrebbero descrivere la funzionalità e il valore che ci si aspetta che il team fornisca all'utente. Quando scriviamo una user story, stiamo sia acquisendo che condividendo conoscenza.
Requisiti e storie utente: qual è la differenza
I requisiti software sono più una gerarchia che un singolo concetto. I requisiti software iniziano con i risultati aziendali (o obiettivi aziendali), che possono essere suddivisi in funzionalità (a volte definite anche requisiti software aziendali, Epic o set di funzionalità, che possono essere considerate come ciò che deve essere fornito per fornire valore aziendale). Questi a loro volta possono essere suddivisi in User story più granulari (o requisiti utente funzionali). Infine le storie degli utenti possono essere suddivise in attività tecniche. Un buon insieme di requisiti software richiede TUTTI questi (eccetto le attività tecniche).
Altri
Requisiti non funzionali (NFR),
Per raggiungere i risultati aziendali dichiarati, è probabile che anche alcuni NFR siano importanti. Esistono dozzine di tipi di NFR, spesso indicati come le funzionalità di una soluzione software. Curiosamente il “NFR” che viene citato più spesso è la sicurezza, eppure le funzionalità di sicurezza sono generalmente funzionali. Gli NFR sono particolarmente difficili da dimensionare.
Criteri di accettazione
I criteri di accettazione sono una qualifica dettagliata della user story O NFR. Definiscono ciò che è accettabile e inaccettabile con dettagli più granulari rispetto a una tipica user story. La storia dell'utente è solitamente a livello di oggetto mentre i criteri di accettazione spesso definiscono i limiti a livello di attributo.
Vincoli
Questi non sono sempre articolati come tali in un progetto software. A volte sono incorporati in modo errato all'interno di una storia utente. Possono essere considerati vincoli di progetto e spesso determinano come il software può essere consegnato, non cosa viene consegnato.
Le storie degli utenti contano
Nessun progetto software sostanziale verrà consegnato nei tempi e nel budget se omette di produrre una serie di requisiti utente funzionali o storie di utenti. E questi dovrebbero essere di alta qualità (ne parleremo più avanti). Inoltre ogni parola della user story è importante.
Creare storie di alta qualità
Le meraviglie della lingua inglese ci offrono molti modi per esprimere la stessa cosa. Questa flessibilità porta al potenziale differenze di comprensione. Quando due lettori di una user story possono raggiungere una diversa comprensione del significato delle parole, si verifica un malinteso. E l'incomprensione potrebbe portare a a difetto del software.
Quanto dovrebbero essere lunghi?
Più corto è generalmente migliore. Abbiamo visto storie composte da appena due parole e quanto da una pagina di testo. Generalmente, più breve è meglio, ma fai attenzione a non perdere funzionalità critiche. Consigliamo 5-50 parole a seconda della complessità (escluso il affinché dichiarazione).
Chi scrive le storie degli utenti
Idealmente l'autore delle storie degli utenti è un proprietario del prodotto che ha una vasta esperienza nel ruolo di cliente o utente finale. A volte questo non è pratico e l'autore è un rappresentante dell'utente finale, in genere un analista aziendale (BA). Il BA crea la prima edizione della storia, che viene successivamente discussa e perfezionata dal team. Una volta che c'è una comprensione comune di cosa significhi veramente. Può quindi procedere a essere lavorato. La sfida è raggiungere un’intesa chiara e comune rapidamente e con poche parole.
Storie utente di qualità superiore eviteranno bug.
Molti team software non apprezzano quanto sia importante lavorare partendo da requisiti di buona qualità o storie di utenti. Comunemente 20% o più di tutti i problemi di qualità con il software sono causati da problemi con i requisiti.
Inizia con il "Chi, Cosa e Perché”
L'esigenza funzionale e la giustificazione aziendale sono gli aspetti fondamentali delle buone storie degli utenti. Con questo intendiamo “Chi, deve fare Cosa e Perché”. Chi è l'utente (sistema umano o connesso), Che cosa sono i dati gestiti e spostati, e Perché è ciò che segue il "così che" in una user story. Concentrarsi su questi ed evitare il come (escludere le dichiarazioni di progettazione).
Migliori storie degli utenti ridurranno le rilavorazioni
Per qualsiasi team di sviluppo, entrare in uno sprint con una user story scadente può essere agile, ma certamente non è snello. Vale la pena dedicare del tempo a far sì che le storie dei tuoi utenti siano quanto più belle possibile e quanto più chiare possibile per ridurre al minimo le incomprensioni. Le incomprensioni porteranno a costose rielaborazioni.
Qual è la differenza tra storie utente e casi d'uso
Abbiamo già parlato molto delle storie degli utenti. UN caso d'uso è un elenco di azioni o passaggi di eventi che in genere definiscono le interazioni tra un ruolo (denominato attore) e il sistema. Storie degli utenti sono in genere un sottoinsieme di un caso d'uso. Una storia utente in genere descrive solo una delle interazioni che possono essere descritte in un caso d'uso.
Test automatizzati delle storie degli utenti
La qualità delle storie degli utenti è stata mal servita dall’automazione. Infatti, prima del rilascio di ScopeMaster®, non eravamo a conoscenza di strumenti che potessero aiutarti a migliorare la qualità delle tue storie utente. Attualmente sul mercato sono presenti alcuni prodotti che si avvicinano ad alcune delle funzionalità di ScopeMaster, ma nessuno si avvicina a offrire un'analisi automatizzata così completa e preziosa delle storie degli utenti per il QA, la stima e la generazione di test.
Nozioni di base funzionali vs criteri di accettazione
Ricorda che la descrizione principale delle funzionalità dell'utente precede i criteri di accettazione. I criteri di accettazione sono un'elaborazione e dipendono da un chiaro insieme funzionale di affermazioni dal punto di vista dell'utente.
Test dei requisiti in tempo reale e suggerimenti di miglioramento
ScopeMaster esegue analisi, test, correlazione e dimensionamento in tempo reale dal testo delle storie degli utenti. Il feedback fornito da ScopeMaster ti aiuterà a migliorare la formulazione che utilizzi. Otterrai requisiti più chiari, concisi, completi e coerenti. Concentrati prima su Chi E Che cosa. ScopeMaster genera ed esegue test statici e dinamici su ciascuna storia utente, che ti aiuteranno a trovare e avvisarti di potenziali problemi. Esegue un livello di controllo automatizzato dei requisiti che finora non è stato disponibile nell’industria del software.
ScopeMaster® non solo esamina e analizza il linguaggio di ciascuna storia utente, ma confronta anche ogni storia con tutte le altre all'interno di un set, rileva incoerenze, omissioni e duplicati. Questo ti aiuta a perfezionare le tue esigenze molto più velocemente. L'interfaccia intelligente di ScopeMaster identifica dinamicamente le storie mancanti e rende ancora più semplice aggiungerle.
Gestire infinite possibilità
ScopeMaster supera la vasta gamma di possibili espressioni dei requisiti utilizzando una forma di Intelligenza Artificiale nota come Elaborazione del Linguaggio Naturale. Ciò ti consente di esprimere le tue storie utente in termini specifici del tuo settore; lo strumento non richiede alcuna formazione preliminare.
Crea storie utente migliori più velocemente
ScopeMaster analizza le storie degli utenti (o i requisiti software) per individuare un linguaggio appropriato adatto ai requisiti software e che ti aiuterà a scrivere storie più chiare, concise, coerenti, complete e inequivocabili.
Rileva potenziali difetti
INVEST – è una lista di controllo comunemente utilizzata per la qualità agile delle user story.
- Indipendente *
- Negoziabile / Conciso *
- Prezioso
- Stimabile *
- Taglia *
- Testabile *
*ScopeMaster aiuta l'autore a trovare e risolvere questi problemi (oltre 50% di tutti i difetti dei requisiti).
La nostra lista di controllo preferita e più completa per scrivere storie migliori è questa:
- Inequivocabile / chiaro *
- Misurabile / Funzionale *
- Conciso *
- Orientato all'utente *
- Testabile *
- Coerente *
- Intero e completo *
- Unico *
- Progettazione gratuita *
- Tracciabile al valore aziendale
ScopeMaster aiuta in una certa misura con 9 su 10 di questi criteri di qualità e nel complesso ti aiuterà trova oltre 50% di potenziali difetti nei requisiti, precodificazione.
Nei nostri test su oltre 250.000 storie utente raccolte da oltre 100 fonti, abbiamo scoperto che ScopeMaster espone 0,3 -0,7 difetti per CFP (escluse le incoerenze, che esponiamo ma non possiamo calcolare), mentre il valore tipico osservato nel settore è poco meno di 1 difetto per FP (Capperi Jones). Eccoci qui, dati reali che dimostrano che ScopeMaster può aiutarti a scrivere storie utente migliori.
Utilizzando ScopeMaster in modo interattivo all'inizio del tuo progetto per migliorare le storie dei tuoi utenti, puoi porre il tuo lavoro software su basi di qualità più solide fin dall'inizio, prima che la progettazione e la codifica siano avviate. Puoi continuare a perfezionare le storie o durante tutto il processo di sviluppo, come parte del perfezionamento del backlog del prodotto. La cosa bella è che avrai evitato rielaborazioni iniziando con una base migliore per scrivere storie utente di qualità superiore.
Comunicare
Innanzitutto una user story è un mezzo di comunicazione. È necessario trasferire la conoscenza su alcuni o tutti i seguenti elementi: la necessità, il requisito, la funzionalità, il risultato, lo scopo del requisito. Se non riesce a fornire un intento chiaro, porterà a interpretazioni errate che a loro volta possono portare a bug.
Impara a scrivere storie utente che gli sviluppatori e i tester adoreranno
Lascia che ScopeMaster ti aiuti a scrivere storie di utenti che il tuo team troverà facile da costruire. Quelle storie saranno chiare, sufficienti, coerenti, complete, considerevoli, verificabili. Tutti possono diventare autori di fantastiche storie utente.
Alexander Cowan Storia utente perfezionata
Alexander propone i passaggi per ottenere una user story di buona qualità, proponendo quanto segue una user story “raffinata”..
"In qualità di responsabile delle risorse umane, desidero creare un quiz di screening in modo da essere sicuro di essere pronto a utilizzarlo quando colloquio i candidati per un posto di lavoro."
Lo abbiamo eseguito tramite ScopeMaster in isolamento e ha rilevato immediatamente l'intento funzionale primario e misurato le dimensioni come 4 punti funzione cosmica.
Un'altra fonte utile per il definizione di una storia utente.
Esempio di capra di montagna
Abbiamo anche analizzato l'insieme di 238 storie utente pubblicato da Mike Cohn
- Tempo impiegato
- 64 secondi
- Valutazione della qualità:
- 54% inequivocabile, dimensionato a 629 CFP
- 46% ambiguo
- 233 potenziali omissioni
- 28 potenziali duplicati
- Oltre 20 incongruenze
- Dimensionamento/Stima
- Stima della dimensione totale di 1161 CFP.
Focalizzata sulle attività dell'utente
Le storie degli utenti o i requisiti incentrati su ciò che l'utente ha bisogno che il sistema faccia per portare a termine un'attività saranno più utili di un elenco di funzionalità.
Arte o scienza
L'arte è soggettiva mentre la scienza è oggettiva, l'arte esprime conoscenza. L'applicazione della scienza in scenari del mondo reale è generalmente considerata ingegneria.
Quando scriviamo una user story, stiamo sia acquisendo che condividendo conoscenza.
Da un lato la user story è un'acquisizione di conoscenza da parte del cliente/utente/proprietario del prodotto e dall'altro è anche un'espressione di conoscenza che il team deve comprendere e su cui lavorare.
Comune sia alla scienza che all’ingegneria è la misurazione, mentre questa è quasi sempre assente nelle opere d’arte.