Che tipo di storie degli utenti dovrebbero essere scritte nelle fasi iniziali di un progetto?

Quando si avvia un progetto, non si ha nulla --- nessuna interfaccia utente, nessun livello dati, niente in mezzo. Pertanto, una singola storia come "gli utenti dovrebbero essere in grado di visualizzare i loro foos" richiederà molto lavoro. Una volta che hai quella storia, uno come "gli utenti dovrebbero essere in grado di modificare i loro foos" è più realistico, ma quella prima storia coinvolgerà l'impostazione di un livello UI, un livello di logica di presentazione, un livello di logica di dominio e un livello di accesso ai dati.

Questo non si adatta al mio concetto di "compiti": per me, preferirei avere qualcosa di simile ai seguenti "compiti":

• Mostra dati fittizi per i foos di un utente in HTML, derivati ​​da oggetti JavaScript.
• Imposta un livello logico di presentazione e connetti gli oggetti JavaScript ad esso.
• Configurare un livello logico di dominio e connetterlo al livello logico di presentazione.
• Configurare un livello di accesso ai dati e collegare il livello logico del dominio ad esso.

Tutti questi rientrano nella singola "storia" sopra? In tal caso, mi sento come se le storie non fossero un quadro terribilmente utile nelle prime fasi di un progetto. In tal caso, va bene --- Voglio solo assicurarmi che non mi manchi qualcosa, dal momento che sto davvero cercando di imparare questa metodologia agile nel miglior modo possibile.

Questa è una buona domanda e probabilmente ci sono diverse buone risposte. La mia opinione è questa:

Una storia è una storia utente, quindi deve essere definita in termini che descrivono i vantaggi per l'utente.

Se Agile e le storie funzioneranno per te, dovrebbero funzionare anche nelle fasi iniziali. Il primo punto elenco è una storia per utente singolo (formulata un po 'di tecnologia però), ma le altre tre sono descrizioni di attività tecniche.

Nelle fasi iniziali di un progetto, quando non disponi di strutture adeguate per rendere lo sviluppo CRUD ( C reate, R ead, U pdate , D elete) rapido e semplice, le tue storie devono essere di dimensioni molto più piccole, incrementali pezzi.

Invece di "L'utente dovrebbe essere in grado di visualizzare il proprio foo" , qualcosa del genere:

1. L'utente dovrebbe essere in grado di vedere una pagina con dati di esempio
2. L'utente dovrebbe essere in grado di vedere una pagina con dati di esempio interattivi
3. L'utente dovrebbe essere in grado di vedere una pagina con dati di esempio interattivi in ​​tempo reale

Ricorda che la maggior parte delle storie degli utenti che sembrano troppo grandi per essere sviluppate in un singolo sprint (ho scoperto che qualcosa di più grande di circa 8 punti della storia, o giorni di sviluppo, era troppo grande) può probabilmente essere suddivisa in pezzi che sono ancora significativi per l'utente.

La storia / funzionalità non deve essere commercializzabile, deve solo essere significativa per il proprietario del prodotto. Nel caso sopra, potresti inserire alcuni brevi pezzi dimostrativi per mostrare cosa è cambiato e come è stata fatta quella storia - ad esempio, per il n. 3, potresti mostrare la pagina per due diversi utenti con dati precompilati nel database . Nella fase 2, tutti gli utenti vedrebbero gli stessi dati.

Quello che stai chiedendo è essenziale "come pensi allo spazio problematico" per dividerlo in pezzi sensibili, dai quali puoi fare un disegno.

Sia che tu lo chiami la storia dell'utente, o l'analisi, o la decomposizione, o le specifiche o la raccolta dei requisiti ... alla fine, si riduce a diverse cose che normalmente avranno qualche iterazione.

È necessario ottenere dalle teste degli utenti ciò che vogliono. (Probabilmente conoscono qualcosa di ciò che vogliono e vogliono cose che sono incoerenti ma che non riescono ancora a vedere.)

Devi catturarlo in qualche modo: hai davvero solo 2 scelte: parole o immagini. Entrambi hanno il potere, usali entrambi se puoi. Le parole sono in definitiva più potenti dal punto di vista di una disputa contrattuale in seguito.

È necessario presentare questo indietro e cercare un accordo.

Alcune persone realizzano prototipi visivi precoci senza business o altre logiche. Questa può essere una tecnica potente - fino a un certo punto perché comporta ancora una certa quantità di agitando la mano.

Alcuni tratteranno lo storyboard e poi presenteranno e spiegheranno.

Alcuni scriveranno documenti rigorosi e attentamente analizzati.

Ogni tecnica ha i suoi vantaggi e svantaggi.

L'unico consiglio che darei è: saltare al codice una soluzione troppo presto è di solito una mossa sbagliata. Comprendere COSA fare, per CHI e PERCHÉ, prima di farlo, generalmente porta a meno rielaborazioni e uno sviluppo più rapido.

Quando parli di "compiti", mi sembra una specie di interruzione del lavoro, avendo capito cosa, chi e perché. Non puoi capire benissimo le attività finché non hai compreso la storia dell'utente, in un documento, approvata dal cliente come ambito del lavoro che intendi svolgere. Sapere cosa devi raggiungere (l'output) ti consente di capire i compiti (i passaggi necessari per arrivarci).

Non lesinare sull'analisi e sulla documentazione del front-end.

Penso che ciò che ti manca sia che le storie degli utenti riguardano la descrizione di come l'utente si aspetta di utilizzare il sistema. Questo è un modo per determinare i requisiti aziendali . Non sono progettati per dirti direttamente cosa fare tecnicamente, che è quello che sembri desiderare.

Questa è senza dubbio una delle parti più importanti di un progetto. Se i requisiti aziendali non sono corretti, il sistema non sarà di alcuna utilità per gli utenti.