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

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

Una storia è una storia utente , quindi deve essere definita in termini che descrivono in che modo avvantaggia l'utente.

Se Agile e le storie stanno andando a lavorare per te, allora dovrebbero funzionare anche nelle fasi iniziali. Il primo punto elenco è una storia di un singolo utente (formulata però un po 'di tech-y), ma gli altri tre sono descrizioni di attività tecniche.

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

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

1. L'utente dovrebbe essere in grado di visualizzare una pagina con dati di esempio
2. L'utente dovrebbe essere in grado di visualizzare una pagina con dati di esempio interattivi
3. L'utente dovrebbe essere in grado di visualizzare una pagina con dati di esempio interattivi dal vivo

Ricorda che la maggior parte delle user story che sembrano troppo grandi per essere sviluppate in un singolo sprint (ho trovato che qualcosa di più grande di circa 8 story points, o giorni di sviluppo, era troppo grande) può probabilmente essere suddivisa in pezzi che sono ancora significativo per l'utente.

La storia / la funzione non deve essere commercializzabile, deve solo essere significativa per il proprietario del prodotto. Nel caso precedente, potresti inserire alcuni brevi pezzi dimostrativi per mostrare cosa ha cambiato e in che modo questa storia è ora done - ad esempio, per # 3, è possibile mostrare la pagina per due utenti diversi con dati pre-compilati nel database. Nella fase 2, tutti gli utenti vedrebbero gli stessi dati.

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

Sia che si chiami la storia dell'utente, o l'analisi, o la decomposizione, o la specifica, o la raccolta dei requisiti ... alla fine ci sono diverse cose che normalmente avranno qualche iterazione.

Devi ottenere dagli utenti ciò che vogliono. (Probabilmente conoscono qualcosa di quello che vogliono e vogliono cose che sono incoerenti ma non riescono ancora a vederlo.)

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

Devi presentarlo e cercare un accordo.

Alcune persone fanno i primi prototipi visivi senza alcuna logica commerciale o di altro tipo. Questa può essere una tecnica potente - fino a un certo punto perché coinvolge ancora una certa quantità di ondate di mano.

Alcuni faranno storyboard - e poi presenteranno e spiegheranno.

Alcuni scriveranno documenti rigorosi e attentamente analizzati.

Ogni tecnica ha i suoi vantaggi e svantaggi.

Circa l'unico consiglio che darei è: tuffarsi per programmare una soluzione troppo presto è di solito una brutta mossa. Capire COSA fare, per CHI, e PERCHÉ, prima di farlo generalmente porta a meno rilavorazioni e uno sviluppo più rapido.

Quando parli di "compiti" mi sembra una specie di suddivisione del lavoro, avendo capito quanto sopra, chi e perché. Non è possibile capire le attività BENE finché non si comprende la storia dell'utente, in un documento, approvato dal cliente come ambito del lavoro che si intende svolgere. Sapere cosa devi ottenere (l'output) ti consente di capire i compiti (i passaggi necessari per arrivarci).

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

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

Questa è probabilmente una delle parti più importanti di un progetto. Se non si soddisfano i requisiti aziendali, il sistema non sarà di alcuna utilità per gli utenti.