Come definire regole aziendali complesse utilizzando le User Story?

Una definizione rapida e sporca di User Story :

"As a <role>, I want <goal/desire> so that <benefit>"

In questa definizione comunemente accettata c'è poco spazio per la definizione di regole di business, vincoli o input dell'utente.

Esempio fondamentale solo per illustrare:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

In questo stupido esempio, dove si potrebbero definire i campi necessari al momento della registrazione di un libro? Dovrebbe essere scritto ovunque? O le regole aziendali richieste devono essere passate come passaparola dal Product Owner?

I campi fanno parte della conversazione che dovrebbe essere tenuta. Possono essere scritti se ciò è utile ma si tratta di una chiamata di giudizio. Mantenere la documentazione aggiornata può essere una sfida, mentre il software funzionante potrebbe essere visto come documentazione in una certa misura.

User Story - Una promessa di avere una conversazione sarebbe un post di blog su questo.

Il tuo banale esempio ha un paio di punti che non so quanto bene lo noteresti. Cosa significa "registrare nuovi libri?" Che cos'è "Trova la loro disponibilità online?" Quelli sono dove inizia la conversazione e una volta che la storia è finita ci possono essere nuove storie poiché forse quelle registrazioni devono essere archiviate o i rapporti devono essere generati periodicamente.

Le risposte precedenti forniscono punti validi, in particolare per quanto riguarda la storia di un utente che ricorda di avere una conversazione . Altre cose da considerare:

1. Se la storia è troppo complessa, è probabilmente un'epopea . Puoi dividere le epiche in storie più piccole ora o una volta che hanno la priorità sul backlog del prodotto

2. I dettagli che implicano casi di test sono separati dalla storia stessa. [ Mike Cohn ]

   Puoi aggiungere sul retro della carta delle storie, prendere piccole note se sono veramente importanti o inserirle nel documento dei test di accettazione .

Come linea guida per valutare se le storie degli utenti sono buone, puoi seguire il suggerimento di Bill Wake :

• I ndependent (di altri racconti)
• N egotiable
• V aluable (per l'utente o il cliente)
• E stimolante (per una buona approssimazione)
• S mall (abbastanza per essere stimabile)
• T estable

Potresti leggere il capitolo 2 "Storie di scrittura" del libro User Stories Applied, di Mike Cohn.

In genere, su una vasta user story che comprende molte sfaccettature, cerco di ottenere l'esempio più generale della storia, e quindi per i dettagli creo storie utente per bambini che ne ereditano. Molti strumenti di gestione dei progetti Agile come RallyDev ti consentono di farlo facilmente e trovo che abbia senso.

La registrazione di nuovi libri è ampia, quindi forse ci sono altre 10 storie di utenti per bambini su come <role>si desidera che i libri vengano registrati.

Dettagli estremi di queste cose o dettagli bizzarri di frange che di solito definisco in una o più attività sotto quella user story. Le attività aiutano a definire il lavoro di sviluppo e progettazione che dovrebbe essere svolto (a livello generale) per soddisfare la storia dell'utente (ad es. Scrivere validator per assicurarsi che l'input nel campo della descrizione sia inferiore a 50 caratteri ...) EDIT: Volevo solo aggiungere che è probabilmente meglio tenere lontani i dettagli estremi dalle storie degli utenti perché probabilmente non è qualcosa di cui un utente si preoccuperà molto. Gli utenti vogliono spiegare il software in termini generali e dipendono dagli sviluppatori software per capire e nascondere i dettagli da loro.

Questo è il modo in cui affronto il problema, ma sono sicuro che ci sono molti modi diversi.

La risposta è semplice, incorporare le regole aziendali nei criteri di accettazione.

Esempio fondamentale solo per illustrare:

Come bibliotecario, voglio registrare nuovi libri, in modo che gli studenti possano trovare la loro disponibilità online

Sarò soddisfatto quando: * Posso registrare i seguenti campi: - ISDN - Autore - Dewey Decimal blah blah * Posso vedere la conferma che il libro è stato registrato dal sistema * Posso visualizzare il libro nel sistema

Come definire regole aziendali complesse utilizzando le User Story?

Non è a questo che servono le storie degli utenti. Non sono requisiti software che catturano tutti i dettagli o le regole aziendali necessarie per scrivere l'implementazione. Sono solo una descrizione di ciò che l'applicazione dovrebbe fare dal punto di vista dell'utente.

Ricorda ciò che è importante: creare il software adeguato. Usi tutto ciò che è necessario per farlo e le storie degli utenti sono solo per assicurarti di aver raccolto le funzionalità necessarie che l'applicazione dovrebbe avere in modo da poterne parlare, dare la priorità, stimarle, ecc. La parte mancante dell'utente classico la storia (come ... voglio ... così) riguarda la comunicazione tra coloro che sono coinvolti nella costruzione del software.

Avere i dettagli come criteri di accettazione, sottostorie, attività tecniche allegate alla storia dell'utente, in un documento di specifica o altro, va oltre ciò che la storia dell'utente ti aiuta. L'utente stoy è solo il "soggetto" della conversazione quando decide come costruire il software.

Nell'esempio fornito, ci sono molti dettagli sulla registrazione dei libri che gli sviluppatori non conoscono molto bene, come Dewey o altri sistemi di classificazione, codici ISBN, numeri di acquisizione, copie / titoli / autori duplicati, altre edizioni e così via. Per un nuovo sistema, tali dettagli devono essere forniti dal cliente (e un bibliotecario, di tutte le persone, si prenderà sicuramente cura di loro).

Per citare Steve O'Connell, "È terrificante contemplare quanta politica aziendale viene creata dagli sviluppatori che mancavano dei dettagli necessari nelle specifiche, quindi si sono inventati da soli".