Può una storia di un utente avere una storia di un bambino?

Penso che tu stia pensando troppo a questo.

Qual è lo scopo finale? Stai cercando di fornire un risultato di qualità per l'azienda o stai cercando di seguire una metodologia per la lettera?

Ora, in un mondo sano, la risposta sarebbe ovvia e vorrei semplicemente sostenere che specifichi le tue esigenze in qualunque modo descriva il problema in modo chiaro e inequivocabile. Quindi, le sotto-storie vanno bene. Quando ero uno sviluppatore, non avrei avuto alcun problema a comprendere le tue intenzioni e a fornirle.

In un mondo meno sano, puoi avere sviluppatori passivo-aggressivi in cerca di scappatoie da sfruttare in modo che il sistema di tracciamento dei difetti mostri più difetti attribuibili all'analisi rispetto agli sviluppatori; o venditori esterni che guadagnano di più con il denaro consegnando abilmente esattamente ciò che si specifica, nonostante non sia ciò che si desidera e poi facendo pagare una fortuna per colmare il divario. Se vivi in questo mondo, devi essere assolutamente sicuro che le tue specifiche seguano qualsiasi metodologia che il team di sviluppo si aspetta di ricevere.

Quindi la risposta giusta assoluta dipende da due cose, il tuo contesto politico e la metodologia concordata. In caso di dubbi, trascorri mezza giornata a fare una pochi storie utente annidate e presentale al team di sviluppo per la revisione. Dovrebbero essere in grado di farti sapere dove ti trovi in meno di mezz'ora.

Ok, ecco la cosa su Agile che nessuno dei venditori che vende certificati per due giorni ti dirà:

Ciò che potrebbe funzionare per il mio team potrebbe non funzionare per il tuo. L'intero punto di Agile Software Development è, attraverso la sperimentazione, capire cosa funziona per il tuo team.

Quindi, esegui un esperimento nel modo più economico possibile. Fai una storia in questo modo. Una volta terminato, parla con il tuo team di ciò che è andato bene, di ciò che è andato male e se l'esperimento deve continuare o meno.

Personalmente non vedo una ragione per cui non puoi avere una sottotrama, ma potrebbe causare un mal di testa perché le storie potrebbero non essere abbastanza indipendenti da essere consegnate separatamente. Con questo in mente, vai a provarlo, quindi torna indietro e condividi i risultati come risposta qui.

Lo scenario non sembra una relazione genitore / figlio, ma una semplice dipendenza. La seconda storia non può essere completata fino a quando il primo è completato. Infatti, come scritto non è nemmeno dipendente. Puoi certamente completare una storia di "vedere l'intera storia medica" senza avere il modulo APE (a meno che il modulo APE sia "l'intera storia medica").

Forse un modo migliore per vedere questo è di invertire la relazione. Mi sembra che tu abbia un'epopea, che può essere espressa in questo modo:

Epic: come medico, voglio vedere l'intera storia medica in un paziente caso, per ottenere una rapida panoramica dei dati medici (vedi allegato)

Quindi interromperesti quell'epica in più storie indipendenti:

• Storia: come medico, ho bisogno di uno strumento che mi permetta di visualizzare ogni parte della storia medica
• Storia: come medico, voglio che il visualizzatore di anamnesi includa X
• Storia: come medico, voglio che il visualizzatore di anamnesi includa Y
• Storia: come medico, voglio che il visualizzatore di anamnesi includa il modulo APE
• Storia: ...

Come parte della pianificazione di rilascio e sprint, puoi ordinare le storie in base alle dipendenze. Forse puoi scrivere al visualizzatore senza avere nulla da vedere, e quindi puoi aggiungere cose allo spettatore. Oppure, puoi scrivere i singoli pezzi della storia prima di affrontare lo spettatore. È il tuo team, permetti loro di decidere il modo migliore per gestire le dipendenze.

Succede sempre in modo agile. In effetti, si potrebbe sostenere che questo è il caso normale. Le storie non possono esistere nel vuoto. Non puoi scrivere una storia per stampare un rapporto finché non hai completato una storia che crea un rapporto. Non è possibile creare un report finché non si crea un database per conservare un report. E così via.

Quindi, prima pensa alla grande immagine "Ho bisogno di vedere tutta la storia medica", e poi suddividila in pezzi di dimensioni ridotte. "Ho bisogno della storia medica per includere l'APE", e così via. È perfettamente naturale che queste storie abbiano dipendenza l'una dall'altra e non è possibile cambiarle. Parte dell'obiettivo di scrivere le storie è rendere visibili queste dipendenze.

Questo è un requisito non funzionale. La seconda user story sta esprimendo un requisito funzionale. Sono due requisiti separati anche se in pratica sono correlati. Per un esempio più chiaro:

• (funzionale) L'utente può richiedere X.
• (non funzionale) Sistema può gestire 1.000 richieste al minuto.

Puoi esprimere questa storia di un utente se è così che vuoi fare le cose (primo risultato su google per i consigli su come farlo: link ).