Quale dovrebbe essere fatto prima: utilizzare casi o storie di utenti?

I casi d'uso e le storie degli utenti sono entrambi strumenti per la raccolta e l'espressione dei requisiti.
Come hai già rilevato, un caso a uso singolo ha in genere un ambito più ampio rispetto a una singola storia utente perché tenta di descrivere completamente un'interazione dell'utente, inclusi errori e deviazioni dal percorso normale. Una User story può essere approssimativamente paragonata a un singolo flusso attraverso un caso d'uso.

Come per tutti gli strumenti, spetta a te utilizzare gli strumenti che ritieni necessari in una determinata situazione. Ciò significa che puoi utilizzare solo casi d'uso, solo storie utente o una combinazione di casi d'uso e storie utente come ritieni opportuno.

Sta diventando sempre più comune usare le storie degli utenti come unità di lavoro di ciò che può essere sviluppato e consegnato in un'unica iterazione / sprint.
Con questo in mente, non mi concentrerei troppo sulla raccolta dei requisiti come casi d'uso, a meno che i casi d'uso non si presentino naturalmente quando parliamo con gli stakeholder.

Nel mio caso, ho sempre riscontrato che il livello di dettagli necessari per i casi di utilizzo completo avvengono prima attraverso le mie storie di utenti. La prima domanda che pongo è "cosa devono essere in grado di fare le persone?". Una volta che ho gli scenari, è più facile iniziare a esaminare tutti i casi d'uso e le varianti del flusso per il sistema.

Detto questo, per un singolo sviluppatore che lavora da solo, non devi preoccuparti se si tratta di un caso d'uso o di una user story o di un appiccicoso sul muro che dice "non dimenticare di 'x' ". Ciò di cui hai bisogno è un processo che ti faccia riflettere su ciò che i tuoi utenti stanno cercando di ottenere e ti aiuta a tenere traccia delle diverse cose che devono essere in grado di fare. Tutto il resto dipende da te dal livello di dettaglio che devi scrivere per pianificare il tuo sviluppo.

Ad esempio, quando lavoro su un side side project, le mie attività di lavoro assomigliano a questo:

1. Accedi
2. Visualizza l'elenco di "foo"
3. Salva selezioni dall'elenco
4. ricerca

Onestamente, ognuno di questi non avrebbe altro su di esso che una stima. Perché? Perché li sto solo usando come promemoria di ciò di cui ho bisogno per essere in grado di fare l'utente e vedrò i dettagli quando arrivo a quella parte. Con una squadra di una sola persona, tutto può essere nella tua testa e va bene, perché non devi comunicarlo a nessun altro.

Ora ci sono avvertenze ...

Unico sviluppatore che lavora con altri specialisti

Hai bisogno di riportare i progressi in un'altra squadra? Hai dei tester che devono validare il tuo lavoro? Hai un management che vuole sapere cosa hai fatto? Hai un project manager che deve prevedere una sequenza temporale? Hai un proprietario del prodotto che sta determinando le funzionalità richieste?

Se queste persone fanno parte del tuo progetto, allora devi assicurarti che le tue attività lavorative abbiano abbastanza informazioni su di loro per consentire loro di svolgere il loro lavoro. Il PM probabilmente ha bisogno di un modo per vedere le dimensioni relative delle cose e progredire attraverso quel lavoro. I tuoi tester avranno bisogno di dettagli su come dovrebbero fluire le cose (casi d'uso) e potresti persino chiedere loro di aiutarti a scriverli. Il management potrebbe voler sapere su cosa sta lavorando, quindi avrai bisogno di una descrizione aziendale sufficiente per comprendere le funzionalità che fornirai.

Se hai risposto "sì" a tutte quelle domande, probabilmente hai bisogno di un backlog più rigidamente documentato poiché lo userai per comunicare con gli altri membri della tua squadra.

• Probabilmente avrai bisogno del concetto di "Epics" o "Funzionalità" che sarà la funzionalità di alto livello che puoi utilizzare per segnalare alla direzione o ai proprietari dei tuoi prodotti.
• Avrai annidato User Story all'interno di quelle Epic / Funzionalità definirà i blocchi più piccoli di funzionalità che saranno utilizzati per comunicare i progressi con il tuo project manager, definire il tuo lavoro attività all'interno di uno sprint e saranno utilizzate per comunicare l'attività obiettivo per il team di test.
• Avrai casi d'uso o casi di test definiti per le storie per acquisire le varie decisioni di flusso a basso livello che sono necessarie per assicurarti che tu, l'azienda e il team di test siano allineati e sappia cosa verrà accettato come ' corretto'.

Tutto questo può essere ignorato se sei tu a definire il lavoro, a gestire i progressi, a testare il software e a decidere se qualcosa è "corretto". Taglia lo sforzo extra e assicurati di fare ciò che è importante: creare software funzionante!

Se stai facendo un qualche tipo di agile, la risposta dogmatica è, Fai ciò che funziona per te.

Il processo dovrebbe far parte delle tue retrospettive. Dovresti parlare di colli di bottiglia, ridondanze, problemi di comunicazione, documenti che nessuno legge mai, ecc. E, questa è l'impostazione in cui i cambiamenti di processo dovrebbero essere concordati e idealmente messi in moto.

Nella mia esperienza, i Project Manager, gli Analisti e gli "uomini d'affari" sono addestrati per eseguire il processo "al di fuori". Raccolgono i requisiti, che sono spesso verbalmente dati dalle parti interessate nella forma della trama di un utente. Fanno domande per chiarire, così possono creare dettagliati documenti "use case", che il team di sviluppo cerca di tradurre in storie degli utenti su cui possono iterare ...

La mia raccomandazione, basata sulla mia esperienza personale: cerca di convincere il tuo team o analista o chiunque a inserire le storie degli utenti nel backlog, con dettagli minimi. Includere le informazioni prioritarie e descrivere il "problema" che la storia si propone di risolvere. Forse elenchiamo alcune soluzioni potenziali ... ma, al di là di questo, lascia che gli "use case" emergano mentre i tuoi sviluppatori eseguono iterate con QA e / o gli stakeholder sulle storie.

Registra i casi d'uso a cui sei atterrato nella documentazione man mano che la storia si risolve, in qualsiasi formato aiuti la gente a capire il sistema.

Le storie degli utenti e i casi d'uso non si escludono a vicenda e non c'è "dovrebbe" .

Sono solo strumenti che possono o non possono essere utili per migliorare il tuo processo fino ad un certo punto. Ci sono molti modi possibili, vorrei solo proporne uno con entrambi i casi d'uso e le storie usate insieme:

• Per il backlog e la pianificazione, prova le storie degli utenti come caratteristiche di alto livello dei segnaposto. (Ovviamente anche i casi di utilizzo a livello di obiettivi dell'utente possono essere d'aiuto).
• Per documentare i requisiti già implementati i casi d'uso funzionerebbero al meglio.

Dipende . Se lavori da solo, prova diversi approcci e prendi ciò che funziona meglio per te.

Disclaimer: ci sono molte metodologie su come scriverle. "User story" hanno una definizione molto comune mentre "Use cases" può avere significati molto diversi. Mi riferisco ai classici diagrammi UML, che sono molto comuni.

User story o Use cases

Nella mia esperienza, ci sono diversi set mentali su quale sia il modo migliore per capire. Quindi deciderei su ogni nuovo team di progetto, su come documentare i requisiti. Di solito una combinazione è comune, usando Use cases per la panoramica e user story per i dettagli.

• I casi d'uso , specialmente come diagrammi, sono più adatti per le persone che pensano visivamente
• Le storie degli utenti sono preferite dalle persone che pensano nelle discussioni che sono molto loquaci

(questo è basato sull'opinione, senza basi scientifiche)

Cosa fare prima?

Sulla scrittura dei requisiti per un progetto, vorrei iniziare su un livello molto astratto. Usando i casi d'uso, si dipingerebbe un diagramma (UML-) con gli obiettivi globali del progetto. Con le storie degli utenti, scrivi alcune "storie epiche" che descrivono i principali obiettivi.

Un secondo passo sarebbe entrare nei dettagli. In questo modo, dovresti cercare di mantenere un riferimento a una "storia epica" o a un obiettivo globale. Questo aiuta a strutturare molto i requisiti.

Lo guarderò in senso inverso: che cosa deve venire per ultimo?

L'ultimo passo è che tu (o qualcun altro) inserisci i requisiti nel tuo backlog. I requisiti devono essere tali che tu sappia come deve comportarsi il codice che scrivi e in modo che i tester possano verificare che il tuo codice si comporti come dovrebbe.

Questi requisiti possono essere ben registrati sotto forma di una user story ben definita. Quindi la user story può essere l'ultimo passo. Gli use case solitamente si trasformano in più di una user story, quindi devono venire prima della user story.

Ero solito pensare che Use Case fosse pensato per l'approccio a cascata, mentre le User Story venivano fornite con il processo Agile. Mi ci è voluto un po 'per capire che non sono esclusivi.

Dato che non dovrai condividerle, non riguarderà la comunicazione, tranne che con te stesso. Finché riesci a capire i tuoi appunti una settimana dopo, stai bene. Altrimenti, aggiungi più dettagli quando noti i requisiti.

Hai bisogno di un modo visivo e flessibile per seguire i tuoi progressi e stabilire le priorità? In tal caso, le User Story sarebbero utili, insieme alla scheda di avanzamento che troverai nella maggior parte delle metodologie agili (todo, done, sprint corrente).

Quando si tratta di requisiti puri, sapendo cosa deve essere risolto e come, suggerirei di iniziare con User Stories dato che sono facili da creare (una frase) o Use Case Diagram che elenca solo attori e high- azioni di livello.

Quando sono necessari dettagli, esegui il drill-down con più User Story. Quando si incontra un processo complesso (ramificazione, molti condizionali e prerequisiti), è possibile COLLEGARE la User Story a un caso d'uso, indipendentemente dal fatto che si utilizzi un diagramma o la versione del modello di testo. E ricorda che anche quelli possono essere creati con diversi livelli di dettagli. Il libro Requisiti software di Karl Wiegers & Joy Beatty raccomanda di mantenere solo il livello di dettaglio necessario per capire. Se qualcosa ti è completamente ovvio, non è necessario eseguire il drill down.

Quanto sopra è ciò che personalmente non ho avuto all'inizio: le User Story sono un punto di partenza, un "riassunto", ma ciascuna può essere completata da documenti aggiuntivi per definire ulteriormente cosa è necessario e necessario, inclusi casi d'uso dettagliati quando necessario .