Cosa fare delle storie utente che dipendono dalle integrazioni orizzontali?

Question

Cosa fare delle storie utente che dipendono dalle integrazioni orizzontali?

#1 da (1 voti)
#2 da (1 voti)

2

Come gestisci la storia di un utente quando dipende da integrazioni orizzontali in un'applicazione?

Un esempio potrebbe essere una user story come "Vorrei avere una guida audio nella schermata di avvio". Supponiamo che l'aiuto dell'audio dipenda dalla creazione di un lettore audio nella nostra applicazione che gestisca l'audio su più schermi e possa anche essere un componente di un'altra storia utente, ad esempio "Vorrei avere una guida audio nella schermata delle impostazioni". Credo che quello che sto ottenendo sia come gestire l'architettura nelle user story?

Quello che ho considerato finora:

hanno un'attività ripetuta comune in ogni storia
rompere architettonici e pezzi orizzontali nelle loro storie
semplicemente non scrivere
storie per questi problemi e invece tracciarli indipendentemente

project-management agile organization user-story

posta stevebot 12.02.2015 - 01:14

fonte

2 risposte

Leggi altre domande sui tag project-management agile organization user-story

Concetto di GUI per un editor grafico reattivo asincrono Quale dovrebbe essere il modo migliore per eseguire una lunga operazione in Java Spring?

score 1 · Answer 1

Una User story è in realtà un testo del tuo cliente. Dovresti dividere quella storia in preziosi backlog. Se è difficile per te scriverli, perché richiedono troppo tempo per essere valutati in modo ragionevole, devi considerare una suddivisione della storia. Ciò significa che parli con il tuo stakeholder e ricomponi la user story in storie di utenti più piccoli.

Il fatto è che la mischia è come la usi nella tua azienda. Il flusso di lavoro è quasi lo stesso, ma ci saranno molte aziende che affermano che una storia utente di 2 settimane divisa in dieci backlog da 1 giorno va bene e che altre aziende dicono che la storia di un utente è al massimo. 2 giorni e un arretrato non più di 1 giorno va bene.

Nel tuo caso, se la tua storia utente dipende da un componente che non esiste ancora, devi anche prima definire quel componente, non è vero? Quindi hai la tua altra storia utente.

score 1 · Answer 2

Quello che hai sembra quello che è noto come Epico. Questa è fondamentalmente una user story troppo grande per essere implementata, testata e accettata in un singolo sprint. Questo dovrebbe in genere essere il punto di partenza per tornare al cliente e cercare di ricavare più dettagli e specifiche su ciò che vogliono. Dovresti farlo come una parte normale del grooming degli arretrati, identificare storie troppo grandi o troppo ampie e capire come possono essere suddivise in blocchi più piccoli.