Perfezionamento delle storie degli utenti
Il perfezionamento delle storie degli utenti è il processo di miglioramento, suddivisione e chiarimento di ciascuna storia dell'utente. I dettagli e la chiarezza di ciascuna storia utente dovrebbero essere rivisitati. Il backlog grooming è un termine che generalmente si riferisce al processo di livello superiore che dà priorità alle storie degli utenti. Sia il perfezionamento (chiarimento) che la definizione delle priorità (priorità) sono passi importanti per raggiungere buoni requisiti di qualità. Il primo garantisce che l'utente ottenga ciò che desidera e il secondo si occupa della sequenza per soddisfare sia le esigenze aziendali che l'efficienza del team di sviluppo. In questo articolo ci concentreremo sul perfezionamento delle storie degli utenti, lasciando la definizione delle priorità in un articolo separato.
Scopo delle User Story
Lo scopo delle storie degli utenti è quello di comunicare, per garantire che le esigenze dell'utente siano espresse correttamente in un linguaggio che uno sviluppatore e un tester possano comprendere in modo completo e coerente. Le storie degli utenti devono esserlo orientato all'utente, semplice, chiaro, inequivocabile E coerente, con niente mancante. Perfezionando le tue storie, eliminerai molti difetti dei requisiti che spesso non vengono rilevati fino a molto tempo dopo l'inizio del lavoro di progettazione e sviluppo. Perfezionare le storie degli utenti con ScopeMaster è in genere 10-20 volte più veloce rispetto a farlo manualmente.
Storie utente o requisiti
Le storie degli utenti e i requisiti sono la stessa cosa? Alcuni puristi agili spiegheranno che le storie degli utenti sono promemoria di conversazioni e quindi non requisiti. Abbiamo osservato, tuttavia, che per la maggior parte delle squadre, il le storie degli utenti vengono trattate come requisiti, e quindi facciamo lo stesso. I requisiti o le storie degli utenti sono essenzialmente un'espressione delle capacità che gli utenti richiedono dal software, per garantire una comunicazione chiara e coerente al team. Tieni presente che le User story (o i requisiti) non includono attività tecniche o vincoli di progetto. Di seguito utilizzeremo i termini Requisiti E storia dell'utente intercambiabile.
I difetti nelle User Story sono inevitabili
Scrivere requisiti o storie utente è uguale a qualsiasi altro lavoro di conoscenza: commettiamo errori mentre procediamo. Anche se stiamo attenti, gli errori accadranno, sono inevitabili. Inoltre generalmente li scriviamo in inglese che è una lingua incredibilmente sottile dove ogni parola può essere compresa in modi diversi dai lettori. Quindi, anche se pensiamo di averli scritti bene, è molto probabile che i lettori raggiungeranno una comprensione leggermente diversa. Se due lettori della User Story riescono a raggiungere una comprensione diversa, allora hai un difetto. Un difetto in una user story o in un requisito porterà alla creazione del software sbagliato.
Costo dei difetti nelle storie utente o nei requisiti
Comprendere il costo della qualità è un argomento molto importante in quanto può aiutarci a capire perché la qualità dei requisiti è davvero importante. Un difetto nei requisiti che non viene risolto prima dello sviluppo porterà a un bug. Questo è un fatto inevitabile. Molti problemi relativi ai requisiti vengono individuati durante lo sviluppo. Ma non tutti. Consideriamo qual è l'impatto se non troviamo e correggiamo l'errore solo più tardi nel ciclo di vita dello sviluppo del software (SDLC). Se l'errore viene riscontrato durante lo sviluppo, potremmo dover interrompere lo sviluppo, verificare qual è il requisito corretto, quindi riprogettarlo e riscrivere il codice. Ciò richiede tempo e interromperà e ritarderà i progressi. A seconda della natura e della gravità del difetto nei requisiti, ciò può portare a importanti rielaborazioni (progettazione diversa, architettura diversa). Può ritardare i progetti e portare a significativi aumenti dei costi.
Consideriamo ora una situazione ancora più grave in cui un difetto in un requisito non viene notato fino a quando il codice non arriva alla produzione. Ciò può avere conseguenze ancora più gravi. Il software potrebbe fare la cosa sbagliata e causare danni agli utenti o all'azienda. Ciò può avere un impatto catastrofico.
Costo del ripristino da difetti nei requisiti
Se nella produzione viene riscontrato un difetto causato da scarsi requisiti, ed è grave, ci sono due categorie di costi: interni ed esterni.
Costi interni
- Il lavoro extra per modificare il software affinché funzioni correttamente
- Il lavoro extra per alterare i dati che sono stati gestiti in modo errato a causa dell'errore
- Il costo opportunità di deviare il personale per correggere questo difetto rispetto a svolgere altro lavoro utile
Costi esterni
- Costo consequenziale per gli utenti o i beneficiari del software, causato dal bug
- Risarcimento agli utenti che hanno subito quel bug
- Lavoro aggiuntivo da parte di personale non specializzato nel software per gestire l'incidente/l'impatto sugli utenti fino a quando il bug non verrà risolto
- Danni alla reputazione di un'organizzazione
Nella maggior parte dei casi, i team di progetto software sottovalutano il costo di requisiti inadeguati. Se volete approfondire l'argomento vi consiglio questo ottimo libro “L’economia della qualità del software”
QA automatizzato dei requisiti
ScopeMaster porta il lavoro di garanzia della qualità dei requisiti a un nuovo livello. ScopeMaster aiuta ad accelerare il lavoro di miglioramento della qualità dei requisiti e di perfezionamento della storia dell'utente.
ScopeMaster automatizzerà la ricerca e accelererà la correzione di molti difetti dei requisiti per garantire che i requisiti o le storie degli utenti siano:
- Chiaro
- Conciso
- Coerente
- Completare
- Testabile
- Considerevole
- Unico
- Orientato all'utente
- Progettazione gratuita
L'unico attributo importante che ScopeMaster non può automatizzare è rilevare se hai effettivamente bisogno del requisito: è utile? Dovrai risolverlo da solo, ma ScopeMaster ti libererà così tanto tempo che avrai la capacità di considerare il valore reale di ogni esigenza.
Impara di più riguardo perfezionamento automatizzato del backlog
Quali sono i buoni requisiti?
Abbiamo stabilito che requisiti scadenti sono dannosi, costosi, dispendiosi e in alcuni casi persino pericolosi. Allora come possiamo scrivere buoni requisiti? Come facciamo a sapere se abbiamo buoni requisiti? Come possiamo individuare i problemi nei requisiti? Ci sono alcuni ingredienti universali per buoni requisiti che descriveremo, che ti aiuteranno:
Orientato all'utente
Tutti i requisiti devono essere espressi in termini di ciò di cui un utente ha bisogno. Possono successivamente essere suddivisi in compiti di sviluppatore, ma una versione dei requisiti deve prima essere espressa in relazione alle necessità dell'utente in modo da poter essere certi che ciò che viene sviluppato soddisferà le esigenze dell'utente.
Chiaro e inequivocabile
Un requisito non dovrebbe essere facilmente frainteso dai lettori. Questa è forse la dimensione più difficile da garantire. Ciò significa che un requisito dovrebbe descrivere una funzionalità chiara che un utente deve eseguire. Due lettori dello stesso requisito dovrebbero raggiungere la stessa comprensione generale di quali dati devono essere gestiti come parte del requisito.
Conciso
I requisiti dovrebbero essere concisi. Non è necessario che un requisito sia prolisso, né utilizzi un linguaggio fiorito ed elegante.
Coerente
Una serie di requisiti dovrebbe utilizzare termini coerenti per i tipi di utente, ad es amministratore. Una serie di requisiti dovrebbe inoltre utilizzare termini coerenti di tipi di dati (tipi di oggetto)
Completare
Un requisito dovrebbe essere completo di per sé (descrivere tutti i passaggi funzionali necessari per quella capacità dell'utente). Inoltre, dovrebbe essere completa una serie di requisiti che descrivano tutte le funzionalità necessarie per mantenere tutti i dati all'interno del sistema. Per questo, l’analisi CRUD è molto utile.
Considerevole
Se un requisito dell'utente non è funzionalmente dimensionabile (cioè misurabile in punti funzione COSMIC), allora è quasi certamente carente di qualità se uno degli altri aspetti in questo elenco. Per questo riteniamo che la capacità di dimensionamento in CFP sia un ottimo test di chiarezza e qualità dei requisiti. N.B. i compiti tecnici e i requisiti non funzionali non sono così consistenti. I compiti tecnici sono generalmente dimensionati in ore di personale. Il dimensionamento non funzionale è un problema irrisolto, anche se ci sono alcune raccomandazioni (in un articolo separato).
Testabile
I tester devono essere in grado di determinare come verificare che un requisito sia stato soddisfatto. Pertanto il requisito deve essere scritto in modo tale da poter essere testato. Uno dei modi migliori per garantire che tale requisito sia verificabile è garantire che descriva chiaramente l'intento funzionale. (Per questo consigliamo il dimensionamento COSMIC)
Unico
Non vogliamo che una serie di requisiti contenga contenuti duplicati o funzionalità duplicate. (Questo è forse uno dei problemi di qualità dei requisiti meno significativi.)
Senza design
Le storie degli utenti non dovrebbero contenere alcun dettaglio su come implementare una funzionalità. Una storia utente non è un segnaposto per i dettagli di progettazione. Puoi suddividere il lavoro in cui implementare le storie degli utenti compiti tecnici, ma queste non sono storie degli utenti.
Prezioso
Ogni user story deve fornire valore all’utente o allo stakeholder, altrimenti non dovrebbe essere costruita. Il valore dovrebbe essere espresso in termini che l'utente (non lo sviluppatore) riconoscerà.
Questo è il nostro elenco consigliato di 10 attributi di buone storie utente o requisiti software. Si applica in tutte le situazioni. Alcuni esperti di requisiti sosterranno giustamente che non si spinge abbastanza lontano. È vero, ci sono alcune situazioni in cui i requisiti dovrebbero soddisfare standard ancora più elevati di quelli che abbiamo descritto qui. Ciò che abbiamo descritto è un insieme di attributi che dovrebbero applicarsi ovunque indipendentemente dal tipo di software che stai sviluppando/assemblando/distribuendo.
Attenzione agli INVESTIMENTI!
INVEST è un termine coniato dai primi agilisti per fornire una sorta di lista di controllo alle storie degli utenti. Sta per:
- Io” ndipendente (da tutti gli altri)
- “N” negoziabile (non un contratto specifico per le funzionalità)
- "Prezioso
- “E” stimabile (con buona approssimazione)
- Centro commerciale “S” (in modo da adattarsi a un’iterazione)
- “T” stabile (in linea di principio, anche se non esiste ancora un test per questo)
Ci piacciono le liste di controllo, ma riteniamo che ci siano troppe carenze nell'elenco INVEST per essere universalmente affidabile per valutare la qualità dei requisiti e sconsigliarne l'uso.
Non riesce a garantire che le storie siano orientate all'utente
Se il software non fa qualcosa di utile per un utente, non è utile. Se le nostre storie non sono orientate all’utente, allora sono semplici compiti lavorativi. E questo è ciò che finiscono per diventare così tante storie di utenti, compiti non espressioni di funzionalità o capacità riconoscibili dall'utente. In breve la tua espressione di Fatto probabilmente sarà povero.
Non riesce a garantire la coerenza
Se segui solo queste linee guida è probabile che ti ritroverai con requisiti che confondono i nomi utente/persona e hanno molti termini diversi per i tipi di oggetto.
Non riesce a garantire Sizeable
Facendo riferimento a Estimabile e non dimensionabile, questo approccio non riesce a garantire che ciascuna storia utente abbia una dimensione (funzionale). La dimensione funzionale non è solo preziosa per la gestione del progetto, ma è un buon test della qualità dei requisiti. Un requisito considerevole è quello di buona qualità.
Non riesce a garantire l'assenza di progettazione
Affidarsi solo a INVEST farà sì che le tue storie utente diventino confuse con le attività (e "storie utente tecniche"), questo allontanerà il lavoro dall'utente e avrà valore per lui.
Utilizzando ScopeMaster
Entro un'ora dal primo utilizzo di ScopeMaster potrai individuare e correggere i difetti dei requisiti più velocemente che mai. A seconda della qualità dei requisiti originali, potresti trovare e correggere fino a 200 difetti al giorno. Riesci a pensare a qualsiasi altra attività che sarebbe così produttiva nel trovare e correggere i difetti?
Segui questi passi:
- Importa le storie dei tuoi utenti (tramite un file CSV).
- Fai clic su "Analizza tutto" (potresti avere tempo per prendere un caffè).
- Esplora i risultati dell'analisi di ScopeMaster
- Inizia con quelli ambigui e riformulali per renderli chiare storie utente funzionali e orientate all'utente
- Utilizza il dizionario dei dati generato automaticamente e il modello dei casi d'uso per garantire una denominazione utente coerente
- Utilizzare l'analisi CRUD per garantire una denominazione coerente degli oggetti
- Esaminare il feedback sulla qualità fornito da ScopeMaster per migliorarli ulteriormente.
- Utilizzare l'analisi CRUD per garantire che l'insieme di requisiti sia completo
