Come definire regole aziendali complesse utilizzando le User Story?

I campi fanno parte della conversazione che dovrebbe essere fatta. Possono essere annotati se ciò è utile, ma si tratta di una sentenza. Mantenere la documentazione aggiornata può essere difficile, mentre il software di lavoro potrebbe essere visto come documentazione in una certa misura.

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

Il tuo banale esempio ha un paio di punti che non so quanto tu possa notare. Che cosa significa "registrare nuovi libri?" Che cos'è "Trova la loro disponibilità online?" Questi sono i luoghi in cui inizia la conversazione e una volta che la storia è finita potrebbero esserci nuove storie, perché forse quelle registrazioni devono essere archiviate o i report devono essere generati periodicamente.

Le risposte precedenti forniscono punti validi, in particolare per quanto riguarda la user story che è un promemoria per avere una conversazione . Altre cose da considerare:

1. Se la trama è troppo complessa, probabilmente è epico . Puoi dividere le pozioni epiche in storie più piccole ora o dopo aver ottenuto la priorità sul product backlog

2. Details that imply test cases are separated from the story itself. [Mike Cohn]

   Puoi aggiungere sul retro della story card, fare piccole note se sono davvero importanti o metterle nel documento test di accettazione .

Come linea guida per valutare se le tue storie utente sono buone, puoi seguire Bill Suggerimento di Wake :

• I ndependent (of others stories)
• N egotiable
• V aluable (per l'utente o il cliente)
• E stimolabile (in buona approssimazione)
• S centro commerciale (abbastanza per essere stimato)
• T estable

Potresti leggere il Capitolo 2 "Scrivere storie " del libro User Stories Applied, di Mike Cohn.

Tipicamente su una vasta user story che ha molte sfaccettature cerco di ottenere l'esempio più generico della storia, e poi per specifiche creo storie di utenti secondari che ne ereditano. Molti strumenti di gestione del progetto Agile come RallyDev ti permettono di farlo facilmente e trovo che abbia senso.

La registrazione di nuovi libri è ampia, quindi forse ci sono altre 10 storie di utenti secondari su come <role> vorrebbe che i libri fossero registrati.

Dettagli estremi di queste cose o bizzarri dettagli marginali che di solito definisco in uno o più compiti sotto quella user story. Le attività aiutano a definire lo sviluppo e il lavoro di progettazione che dovrebbe essere fatto (a livello generale) per soddisfare tale user story (ad esempio, scrivere un validtor per garantire che l'input nel campo description sia inferiore a 50 caratteri ...) EDIT: Volevo solo aggiungere che è probabilmente meglio tenere i dettagli estremi fuori dalle storie degli utenti perché probabilmente non è qualcosa a cui un utente si preoccuperà molto. Gli utenti vogliono spiegare il software in termini generali e dipendono dagli sviluppatori di software per capire e nascondere i dettagli da loro.

Questo è proprio il modo in cui affronterò il problema, ma sono sicuro che ci sono un certo numero di modi diversi.

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

Esempio banale 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

How to define complex business rules using User Stories?

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: costruire il software appropriato. Usi tutto ciò che è necessario per farlo e le storie degli utenti sono solo così ti assicuri di aver raccolto le funzionalità necessarie che l'applicazione dovrebbe avere, così puoi parlarne, dare loro la priorità, stimarle, ecc. La parte mancante da parte 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, sotto-storie, compiti tecnici collegati alla storia dell'utente, in un documento di specifiche o altro, va oltre ciò che la storia 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 di cui gli sviluppatori non conoscono molto, come Dewey o altri sistemi di classificazione, codici ISBN, numeri di acquisizione, copie duplicate / titoli / autori, altre edizioni e così via. Per un nuovo sistema, tali dettagli devono essere forniti dal cliente (e un bibliotecario, di tutte le persone, certamente si prenderà cura di loro).

Per citare Steve O'Connell, "È terrificante pensare a quanta politica aziendale sia stata creata dagli sviluppatori che non avevano i dettagli necessari nelle specifiche, quindi si sono inventati da soli."