Relazione tra user story, funzionalità ed epica?

Come qualcuno che è ancora nuovo per l'agile, non sono sicuro di comprendere completamente la relazione o la differenza tra la storia dell'utente, la funzionalità e l'epopea.

Secondo questa domanda , una caratteristica è una raccolta di storie. Una delle risposte suggerisce che una caratteristica è in realtà un'epopea. Quindi le funzionalità e le epopee sono considerate la stessa cosa, ovvero una raccolta di storie utente correlate?

Il nostro project manager insiste sul fatto che esiste una struttura gerarchica:

Epico -> Funzionalità -> Storie utente

E che sostanzialmente tutte le storie utente devono rientrare in questa struttura. Pertanto, tutte le storie degli utenti devono rientrare in una funzione ombrello e tutte le funzioni devono rientrare in un'epopea.

Per me, sembra imbarazzante. Qualcuno può chiarire in che modo le storie utente, le funzionalità e le epopee sono correlate? Oppure c'è un articolo che delinea chiaramente le differenze?

Sono in realtà termini molto generici. Esistono molti modi per interpretarli, variando la letteratura e il modo in cui le persone li vedono. Prendi tutto ciò che dico con un enorme granello di sale.

Di solito, un Epic comprende una funzionalità molto globale e non ben definita nel tuo software. È molto ampio. Di solito viene suddiviso in una storia o funzionalità di un utente più piccolo quando si tenta di dargli un senso e adattarlo a una iterazione agile. Esempio :

Epica
: consenti al cliente di gestire il proprio account via Web

Feature e User Story sono funzionalità più specifiche, che puoi facilmente testare con i test di accettazione. Si raccomanda spesso che siano abbastanza granulari da adattarsi a una singola iterazione.

Le funzionalità di solito tendono a descrivere ciò che fa il tuo software:

Funzionalità
: modifica delle informazioni del cliente tramite il portale Web

Le storie degli utenti tendono ad esprimere ciò che l'utente vuole fare:

User story
In qualità di impiegato di banca,
desidero poter modificare le informazioni sui clienti in
modo da poterle tenere aggiornate.

Non penso che ci sia davvero una gerarchia tra i due, ma puoi averne uno se vuoi o se si adatta al tuo modo di lavorare. Una user story può essere una giustificazione specifica per una funzione o un modo specifico per farlo. O può essere il contrario. Una funzione può essere un modo per realizzare una user story. Oppure possono denotare la stessa cosa. È possibile utilizzare entrambi: User story per definire ciò che porta valore aziendale e funzionalità per descrivere il vincolo del software.

User story : come cliente, voglio pagare con le carte di credito più popolari.
Funzionalità di supporto dell'API XML GOV-TAX-02 del governo.

C'è anche la questione dello scenario, che di solito è un modo in cui verrà eseguita una storia Feature / User. Di solito mappano in modo pulito a un test di accettazione specifico. Per esempio

Scenario : Prelievo di denaro
dato che ho 2000 $ sul mio conto bancario
Quando prelevo 100 $
Quindi ricevo 100 $ in contanti
e il mio saldo è di 1900 $

È così che definiamo quei termini in cui lavoro . Tali definizioni sono lungi dall'essere una definizione matematica o un termine standardizzato. È come la differenza tra un politico di destra o un politico di sinistra. Dipende da dove vivi. In Canada, ciò che è considerato ala destra può essere considerato di sinistra negli Stati Uniti. È molto variabile

Seriamente, non me ne preoccuperei troppo. L'importante è che tutti i membri del team siano d'accordo su una definizione in modo che tu possa capirti. Alcuni metodi come la mischia tendono a definirli in modo più formale, ma scegli ciò che funziona per te e lascia il resto. Dopotutto, non è agile su individui e interazioni su processi e strumenti e software funzionante su documentazione completa ?

Epico : una storia utente molto ampia che alla fine viene suddivisa in storie più piccole.

User story: una definizione di livello molto elevato di un requisito, contenente informazioni sufficienti per consentire agli sviluppatori di produrre una stima ragionevole dello sforzo per implementarlo.

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

Funzionalità : caratteristica distintiva o capacità di un'applicazione o libreria software (ad es. Prestazioni, portabilità o funzionalità).

http://en.wikipedia.org/wiki/Software_feature

Ti avverto di non applicare una gerarchia troppo rigida a questi termini. Abbiamo provato a farlo nel mio lavoro precedente. Due volte. Entrambi i tentativi erano diversi e entrambe le volte abbiamo scoperto di esserci limitati inutilmente. L'unica costante era la definizione di User Story . Dal punto di vista della pianificazione, una storia è l'elemento base di un progetto. I termini più grandi (epico, funzionalità, ecc.) Sono effettivamente solo tag . I tag sono un modo semplice per consentire a una storia di esistere come parte di più epiche e funzionalità multiple allo stesso tempo. Non vale la pena lo sforzo mentale per essere più severo di così.

I tag funzionano per Stack Exchange e possono funzionare anche per te.

Il modo in cui lavoriamo con Epics, Stories and Features è il seguente

All'inizio del ciclo del progetto, presentiamo Epics . Si tratta di funzionalità di alto livello, quasi incentrate sul marketing. Il tipo di cose che è possibile utilizzare in un riepilogo esecutivo, come

Il nostro nuovo sito Web consentirà ai clienti di sfogliare i prodotti, visualizzare la disponibilità e i prezzi, effettuare ordini e visualizzare la cronologia degli ordini passati

Questo porta a epiche come

• Sfoglia il catalogo dei prodotti
• Vedi disponibilità
• Visualizza i prezzi
• Invia ordine
• Visualizza cronologia ordini

Questi sono scritti come storie utente (ad es. Come cliente, voglio sfogliare il catalogo dei prodotti, in modo da poter prendere una decisione d'acquisto informata), ma servono solo come antipasto per dieci per ciò che sarà effettivamente sviluppato e rilasciato.

Queste epiche vengono quindi ulteriormente suddivise in User Story . Si tratta di percorsi utente end-to-end effettivi, di portata molto limitata e definiti in un modo che può essere stimato e pianificato in modo indipendente, sviluppato , testato e rilasciato in un ciclo di rilascio.

La User Story è l'unità di consegna. È la user story che è completa o non completa, diventa live o non diventa live.

Un'epica può comportare un gran numero di storie utente, non tutte saranno sviluppate o rilasciate contemporaneamente.

Ad esempio, l'epopea Sfoglia catalogo prodotti potrebbe essere suddivisa in

• Naviga nella gerarchia di categorie
• Cerca per parola chiave
• Filtra per attributi di prodotto (ad es. Fascia di prezzo, marca, colore, dimensioni, ecc.)

Ancora una volta, ognuno di questi verrebbe scritto nel formato, ad es. Come cliente, desidero navigare nella gerarchia di categorie, in modo da poter sfogliare i prodotti e analizzare il prodotto più adatto alle mie esigenze.

In generale, per la maggior parte dei nostri progetti, abbiamo decine di epiche e centinaia di storie.

Ora, mentre attraversiamo il ciclo di vita della storia, contrassegniamo queste storie con Feature s. Ad esempio, tutti gli articoli di ricerca, ricerca e stock e prezzi verranno contrassegnati, ad esempio, con "catalogo prodotti". Le storie degli ordini da effettuare con il pagamento con carta di credito possono essere contrassegnate con un'etichetta "carta di credito" e quelle relative al pagamento con PayPal saranno contrassegnate con un'etichetta "paypal".

Queste etichette servono a raggruppare storie che appartengono insieme, non perché sono diversi tipi di svolgere la stessa attività (ad es. Tutte le storie degli ordini dei luoghi) ma perché dovrebbero essere rilasciate insieme.

Ad esempio, la storia "Effettuare un ordine pagando con carta di credito" appartiene alla stessa epopea della storia "Effettuare un ordine pagando con PayPal", ma non è necessario che vengano rilasciati insieme.

Considerando che, la storia "effettuare un ordine pagando con carta di credito", la storia "elaborare un rimborso di ritorno su una carta di credito" e la storia "consentire ai clienti di gestire le loro carte di credito salvate sul loro conto" sembrano appartenere a vicenda . Sarebbero stati tutti taggati con l'etichetta caratteristica "carta di credito". cioè appartengono tutti alla funzione "Carta di credito". Non è molto utile rilasciare la possibilità di effettuare un ordine pagando con carta di credito, se non è possibile elaborare un rimborso di ritorno su PayPal o se non è possibile gestire le carte di credito salvate sul proprio conto

Nota : come regola generale, cioè. Questa è, alla fine, una decisione commerciale. Se il time-to-market è importante, potrebbe esserci un motivo legittimo per andare avanti con uno di questi e non con l'altro.

In questo modo Epics serve a scomporre in storie (correlate, ma separate) che possono essere sviluppate in modo indipendente, mentre Feature servono a raggruppare storie che dovrebbero essere rilasciate insieme.

Si potrebbe dire che Epics si decompone in User Story e User Stories si compongono in Features. Le storie che appartengono a una caratteristica sono di solito attraverso Epics. Pertanto Epics and Features sono ortogonali, non in una gerarchia rigorosa.

Nel nostro modo di lavorare, una volta che le Epic sono state suddivise in storie, perdono il loro scopo. Non stimiamo né pianifichiamo Epiche. Non monitoriamo i progressi su Epics. Non rilasciamo Epics. Stimiamo, pianifichiamo e tracciamo le storie degli utenti. E rilasciamo funzionalità.

Sono d'accordo come molte risposte sul fatto che non ci sono davvero risposte giuste dal momento che questi sono solo termini che possono essere variati a seconda del campo Agile su cui ti basi e puoi sicuramente creare il tuo campo fino a quando tutti nella tua squadra, compresi gli stakeholder esterni capire cosa significano. È solo un modo di organizzare le tue esigenze.

La risposta che mi piace viene dal campo di Mike Cohn ed è abbastanza semplice.

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• Epic è solo una grande storia (gerarchica)
• Il tema è solo un gruppo di storie (praticamente come tag)

In realtà evita il termine "caratteristica". Presumo che sia principalmente perché era un termine comune nel mondo tradizionale delle cascate. Molti campi Agili tendono a usare termini diversi per enfatizzare le differenze.

Quindi, nella definizione del tuo PM, Feature è da qualche parte nel mezzo della gerarchia di Epic-Story.

Ecco la mia info-grafica di questa definizione dal mio articolo InfoQ http://www.infoq.com/articles/visualize-big-picture-agile ;-)

Funzionalità ed epiche non sono la stessa cosa.

• Una caratteristica non è una User Story.
• An Epic è una User Story.
• Una User Story può essere un'epica.
• Una User Story può contenere molte funzionalità.
• Una caratteristica può soddisfare da 1 a molte storie utente.

Nelle fasi di pianificazione, le discussioni portano a User Story che sono tipicamente identificate come Epic perché lo sforzo di implementare soluzioni per loro è troppo grande per essere realizzato in pochi giorni. Le caratteristiche del prodotto sono identificate durante questa fase. Ma questo è solo un sottoprodotto della discussione. Le funzioni vengono quindi utilizzate per pianificare una road map del prodotto, che è una discussione separata.

Le Epic sono prese e discusse ulteriormente, dando vita a User Story per ogni Epic. Le funzionalità e le epiche vengono utilizzate per guidare le discussioni nelle sessioni di perfezionamento degli arretrati e pianificazione degli sprint . A quel punto, le User Story che escono da tali discussioni vengono perfezionate , assegnate le priorità e, in Sprint Planning , accettate negli sprint per l'implementazione.

È solo una scomposizione del problema. Sono solo storie, tranne che con dimensioni diverse.

Personalmente preferisco non etichettarne le dimensioni, ma se lo fai anche tu. Chiedi a PM quale sia la definizione nel tuo spazio di lavoro.

La nostra organizzazione ha oltre 2.000 sviluppatori, quindi la risposta a questa domanda è importante per una comunicazione fluida e chiara tra le centinaia di team Agile che abbiamo lavorato insieme sul nostro prodotto comune. Per un'organizzazione molto piccola, puoi avere una struttura molto semplice che non ha nemmeno bisogno di essere gerarchica (come altri hanno risposto). Tuttavia, per le grandi organizzazioni, c'è sicuramente bisogno di una gerarchia organizzata, scalata e coerente - e qui sta il problema nel tentativo di creare una gerarchia da qualcosa che non è strettamente gerarchica.

Per inciso, ci riferiamo a ciascuno di questi livelli disparati come "oggetti di lavoro". Alcune organizzazioni (tra cui alcuni degli intervistati sopra) si riferiscono a livelli disparati come Storie o Storie utente (e lo abbiamo anche fatto in passato), ma lo abbiamo trovato troppo ambiguo, quindi ora li chiamiamo genericamente come Articoli di lavoro.

Il meglio che abbiamo fatto "ufficialmente" finora è quello di seguire la struttura SAFe di Dean Leffingwell sui temi di investimento e le Business Epics che sono in cima (e in secondo luogo dall'alto) della gerarchia, quindi Funzionalità sotto quella, e infine Storie sotto Funzionalità. Secondo Agile, le attività sono sempre sotto Storie, quindi stiamo attenti a non riutilizzare quel termine più in alto. Abbiamo scelto di seguire SAFe per avere almeno ALCUNA coerenza tra tutti i nostri team.

Ma questo è ancora insufficiente per le nostre esigenze. Definiamo una caratteristica come un prodotto chiaramente utile per un consumatore del nostro prodotto software (ovvero elenciamo queste caratteristiche nei nostri annunci delle prossime uscite). E definiamo una storia come una quantità minore di portata e lavoro che può essere fornita in un singolo Sprint da un singolo team di sviluppatori Agile. Ora stiamo anche iniziando a seguire la definizione SAFe di tema di investimento e business epic a livello di portafoglio (e non al di sotto di questo livello). E stiamo iniziando a NON usare le nostre VECCHIE definizioni di "Tema" ed "Epico".

Ora stiamo lentamente evolvendo in questa direzione, ma le ruote del progresso si muovono lentamente. Stiamo ancora lottando su come dividere il lavoro in blocchi di dimensioni ridotte in modo da poter definire il lavoro e farlo in modo uniforme da più team. Per fare ciò, vediamo la necessità di una "caratteristica secondaria" che sia più piccola di una caratteristica ma più grande di una storia. Le sotto-funzioni possono essere utilizzate per blocchi di lavoro svolti su una caratteristica da OGNI team INDIVIDUALE, o pezzi di lavoro svolti da un team SINGOLO in momenti diversi (in Sprint diversi o anche in versioni diverse).

Abbiamo anche bisogno di più livelli gerarchici tra Feature e Business Epic, ma non abbiamo ancora risolto questo, oltre a chiamarli semplicemente "Temi" - che sappiamo non è il termine corretto, poiché è facilmente confuso con i temi di investimento SAFe. Per alcuni grandi progetti (rilasci) abbiamo fino a 5-8 diversi livelli gerarchici, ognuno suddiviso il lavoro in blocchi sempre più piccoli. Puoi pensare a questi temi come a "Gruppi di funzioni", ma non è nemmeno necessariamente il termine corretto.

Penso che sia importante provare a usare termini che offrono chiarezza piuttosto che ambiguità. Pertanto, chiunque si riferisca a una Storia indica l'unità di lavoro più piccola che può essere eseguita in un singolo Sprint (ad eccezione delle Attività sotto la Storia) e Sottotitolo indica l'unità di lavoro più piccola su una Funzione che può essere eseguita da un singolo squadra. Allo stesso modo, un gruppo di funzioni è un livello gerarchico sopra la funzione. Inoltre diventa un po 'confuso, quindi di solito li chiamiamo semplicemente Temi e consentiamo Temi come genitori e figli di altri Temi. Cerchiamo di limitare i livelli Feature, Sub-Feature e Story a un singolo livello ciascuno (le funzionalità non devono essere figli di altre funzionalità) ma non siamo ancora riusciti al 100% a limitare questo.

So che potremmo usare "Tag" per organizzare parte di questo, ma i tag non ci danno la struttura di suddivisione del lavoro organizzativo di cui abbiamo bisogno per classificare il lavoro tra tutti i nostri team. Per definizione, i tag sono ambigui (relazioni molti-a-molti), ma una gerarchia è strettamente uno-a-molti.

La linea di fondo è che questo è ancora un work-in-progress per noi, e stiamo ancora lottando con esso. Ma aderire alle definizioni SAFe di Tema, Epica, Funzionalità e Storia ci porta nella giusta direzione!

La gerarchia del Product Backlog dipende in gran parte dalle dimensioni del prodotto e dalla sua modularità (numero di aree di prodotto definite).

Per piccoli progetti: Epic> Story è più che sufficiente; e tu chiami la "caratteristica".
Grandi progetti potrebbero diventare simili a: Romanzo> Tema> Epico> Funzionalità> Storia

Il miglior esempio potrebbe essere il seguente:
Novel =
Tema MS Office = MS Word / MS Excel ...
Epica = Tabelle / Directory caratteri ...
Funzionalità = Tabella di base / Schema colori tabella / Operazioni con celle ...
Storie (per " Funzionalità di Tabelle di base in Epica "Tabelle" = Aggiungi tabella / Disegna tabella / Inserisci grezzo / Inserisci colonna ...

Ciò che credo sia utile da tenere a mente quando si definisce il proprio ridimensionamento per il backlog è:
1. Storia: a) sempre fattibile in uno sprint; b) non sempre testabile per gli utenti finali
2. Epica / caratteristica: a) non si adatta a una durata dello sprint e deve essere decomposta; b) dovrebbe sempre essere testabile per gli utenti finali; c) sempre spedibile, può essere monetizzato - ottenere il ROI calcolato per questo
3. Quando si considera aggiungi o meno Epic> sezione Feature o si attacca a Epic> Story: consiglierei di inserire Feature tra Epic e Story solo quando: Epic doesn ' per adattarsi anche a 1 versione, quindi è necessario definire un elemento shippable che si adatti a 1 durata della versione .

Spero sia utile.

Nella nostra organizzazione abbiamo i seguenti:

Tema = Usato per raggruppare una raccolta di storie

Epico = Descrive una grande user story (in verità un requisito) che deve essere suddivisa in user story

Caratteristiche = Fa quello che dice sulla scatola, descrive una caratteristica del prodotto richiesto

User story = Questo è il livello più basso di dettaglio da cui derivano le attività.