L'utilizzo di user story per automatizzato, in programma, o la funzionalità reattiva

Question

Mi chiedevo che cosa il pensiero è per quanto riguarda utilizzando User Stories per descrivere automatizzato, in programma, o la funzionalità reattiva. Per esempio, che cosa fare quando si ha qualcosa di simile a un processo di evasione degli ordini che coinvolge tirando un ordine da una coda, la preparazione di un "modulo d'ordine fill", inviando il modulo a un centro di elaborazione degli ordini, quindi in attesa di un qualche tipo di conferma da il centro di elaborazione, come ad esempio "ordine compiuto", o "errore di evasione degli ordini: ragioni ...", ecc .. Tenete a mente che l'unico intervento utente durante l'intero processo sarebbe quando l'ordine è stato inserito. Si potrebbe sempre sostenere che il processo di realizzazione è qualcosa che può essere implicita da una storia inserimento degli ordini, o che si tratta di un dettaglio di implementazione, ma mi sembra che il processo di realizzazione è troppo grande per prendere semplicemente come implicita da una voce ordine user story o come un dettaglio di implementazione. Ci si sente come ci dovrebbe essere una descrizione del compimento stesso come una storia pure.

In particolare, gli aspetti che mi interessano di scrivere una storia utente per automatizzato, in programma, o la funzionalità reattiva è da cui prospettiva dovrebbero essere descritto? Dato che stiamo usando un formato storia come "Come [ruolo], voglio [funzionalità] in modo che [scopo]", qual è il ruolo in "Come [ruolo]" parte della storia, e qual è la scopo nel "in modo che [scopo]" parte della storia? La funzionalità è di solito abbastanza chiaro, ma il ruolo e lo scopo sembra un po 'parente. Per esempio, ho potuto utilizzare il sistema come il mio punto di riferimento e di scrivere qualcosa di simile "Mentre l'Ordine Fulfillment System / agente, voglio essere in grado di tirare un ordine dalla coda adempimento, preparare un modulo d'ordine di riempimento, e inviarlo a il centro di elaborazione degli ordini in modo che l'ordine può essere soddisfatta". Oppure, in alternativa, potrei guardare le cose dal punto di vista e di scrivere qualcosa di simile del business "In qualità di acquirente di ordine, voglio essere in grado di elaborare gli ordini che vengono immessi dai clienti in modo che possa soddisfare la mia responsabilità verso i miei clienti e dare loro ciò che vogliono"(o qualcosa del genere). Tuttavia, ho potuto anche scrivere questo dal punto di vista del cliente e dire qualcosa come "Come cliente, voglio la mia entrata per essere trasformati / adempiuto in modo che possa ricevere le cose che voglio".

mi rendo conto che non ci può essere una risposta definitiva da cui prospettiva è quello valido o uno più utile. Sono sicuro che sarà un sacco di "dipende" risposte. Tuttavia, sarei molto interessato a sentir parlare di ciò che altri hanno fatto in situazioni come queste, o se qualcuno sa di eventuali raccomandazioni, la guida o pratiche specificamente per questi tipi di scenari.

Answer 1

Potrebbe contribuire ad allontanarsi dal modello user story tradizionale e verso il formato delle parti interessate, rivolto Feature Injection (BDD nello spazio di analisi):

In order to <achieve a goal>
As <the stakeholder>
I want <someone to do something for me>.

È possibile lavorare chi lo stakeholder è di pensare a chi sarebbe disposto a pagare per la storia da consegnare. Per esempio, scatole CAPTCHA - quelle cose fastidiose utenti devono compilare - sono fatte per il beneficio di un moderatore, o per rendere il sito più attraente per guadagnare entrate, e non a beneficio degli utenti a tutti! In effetti, quando si pensa di maggior parte dei siti, applicazioni, ecc, che stanno quasi mai fatto per un utente. La maggior parte dei siti web sono circa introiti pubblicitari. La maggior parte delle applicazioni aziendali coinvolgono uno dei dati reparto entrare in modo che un altro reparto può usarlo, o in modo che il denaro può essere preso da parte dei clienti.

Quando si esegue questa operazione, diventa più evidente che ci potrebbe essere più di un utente coinvolto, e un utente potrebbe essere un altro sistema. Nel tuo caso Sto indovinando che un qualche tipo di testa di vendita è lo stakeholder principale per questa storia.

In order to make sales
As the Sales Head
I want customers to be notified of any errors with their order.

In order to make sales
As the Sales Head
I want customers' orders to be fulfilled within 24 hours.

Si può vedere da questo che gli obiettivi diventano abbastanza alto livello, quindi se avete un pezzo di software che svolge in questi obiettivi, è possibile suddividerle:

In order to fulfil customer's orders within 24 hours...

Ora ogni storia può essere fatta risalire alla visione del progetto, e si possono vedere tutti i sistemi di gioco. Così i vostri scenari automatizzati potrebbe leggere:

Given a valid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds successfully
Then the successful fulfillment should be logged
And the customer should be notified by email.

Given an invalid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds with an error
Then the error should be logged
And the customer should be notified of the problem by email.

Per esempio.

A proposito, se stai pensando di trasferirsi in questo formato ora, essere consapevoli del fatto che la trasparenza crea può causare il caos assoluto con persone che sono, per esempio, lo sviluppo perché hanno il bilancio, e non una vera e propria visione del progetto. Penso che questa sia una buona cosa. Altri trovano la politica meno comodo! Buona fortuna, qualunque cosa tu decida.