Come si redigono le storie utente come sviluppatore?

Sto scrivendo un sistema in cui sia io che il proprietario del sistema siamo sviluppatori, e attualmente siamo l'unica fonte di "richieste" o requisiti per il sistema, che vorrei catturare nelle storie degli utenti legate alle funzionalità {1}. La mia priorità urgente ora è catturare un arretrato gestibile. Come devo fare per acquisire il livello di specifiche tecniche con cui sono abituato a lavorare nelle storie degli utenti, che non dovrebbero essere troppo tecniche.

{1} Sto valutando il servizio di gestione dei progetti agile TargetProcess e ogni storia utente deve essere collegata a una funzione principale. Il sistema sembra adatto, quindi questo piccolo vincolo è qualcosa con cui preferirei lavorare piuttosto che aggirare.

Il tipico modello di storia è molto facile da visualizzare:

As a [ROLE] I need to [WHAT] so that/because [WHY].

La cosa interessante è che l'importanza dei componenti è invertita.

PERCHÉ è più importante di CHE COSA e questo è più importante di RUOLO

Esempio usando questa domanda

Come sviluppatore di software ho bisogno di imparare a scrivere User Story in modo da poter popolare il backlog con bozze per avviare discussioni sulle funzionalità e ottenere punti assegnati a loro.

Nulla di più è complicare l'intento e l'implementazione delle User Story.

Strumenti aggiuntivi (l'integrazione è la migliore)

Gli strumenti possono essere utilizzati per acquisire informazioni di dettaglio aggiuntive sulle storie che vengono acquisite quando vengono discusse per assegnare punti / stima, ma tali dettagli non dovrebbero far parte della storia stessa. Qualcosa di semplice come un Wiki con 1 pagina per storia su cui inserire dettagli / trascrizioni delle discussioni è una soluzione abbastanza buona. Il foglio di calcolo Excel è una soluzione terribile.

Concentrati su cosa e perché ed evita come è quando si scrivono le storie degli utenti.

Quello che stai affrontando è in realtà un ottimo esercizio per tutti gli sviluppatori. Essere in grado di esprimere il requisito in termini semplici e commerciali è un'abilità importante.

Dovresti concentrarti su requisiti generali come "devi essere in grado di effettuare una singola selezione da un elenco a discesa di oggetti in modo che l'utente possa abilitare l'azione Foo" invece di specificare utilizzando una casella combinata o una casella di riepilogo o qualsiasi altra cosa che inneschi una routine specifica .

Un altro modo di affrontarlo è far finta che la base / framework di codice sottostante sia una scatola nera quasi completa. Ogni volta che ti ritrovi a dire "usa l'oggetto XYZ", puoi autocontrollarti chiedendoti se lo sapresti in un sistema a scatola nera.

Aggiornamento:
IMO, va bene inserire i dettagli in un caso d'uso che indica il livello di dettaglio richiesto per le informazioni. Ad esempio, con un sistema di iscrizione è giusto specificare
: cognome; campo obbligatorio
- nome; campo obbligatorio
- ID account; il sistema non ha generato input necessari
- segno zodiacale; campo opzionale - (suggerimento) fornire una ricerca dall'inserimento della data di nascita?
- eccetera....

La chiave è che non si sta specificando il modo tecnico per tali informazioni. Se ti ritrovi a dire "usa una classe String / array di caratteri / o campo varchar" per il cognome, allora sai che stai specificando troppo.

Se sei multilingue, usa due diverse lingue come cartina di tornasole. Ad esempio, le stringhe in C sono generalmente array di caratteri (acter) mentre C ++, Java e C # (ok, e quasi tutti gli altri ...) hanno un vero oggetto String. Se scopri che la tua specifica è stata invalidata usando una di quelle lingue, saprai che hai specificato troppo.

Vale la pena notare che sto usando specificamente il termine Use Case rispetto a User Story , sebbene la variante che finisco per usare sia un ibrido di entrambi. Il mio obiettivo di un caso d'uso è fornire una panoramica di ciò che sta succedendo (una User Story nel senso più stretto), ma poi lavorare attraverso gli attori, i sistemi e le funzionalità generali richieste. Il mio approccio è più vicino a quello che Fowler sta suggerendo in quell'articolo di Wikipedia in contrapposizione all'approccio di Cockburn.

Quindi avrò un singolo caso d'uso (o giù di lì) per lo scenario di iscrizione o l'elemento di lavoro. Se è davvero complesso, lo dividerei in multipli, ma non è un grosso problema. Il caso d'uso può quindi essere suddiviso in singole attività, se necessario. Ciò che viene gettato in una mischia particolare dipende da molte variabili, ma non c'è nulla all'interno di questo approccio che ti impedisce di avere un componente dimostrabile alla fine della mischia.