Quando è necessario definire "Epics" nel processo "Agile"?

Quando raccogli i requisiti, di solito intervisti le persone, leggi e valuti i documenti di lavoro o tecnici, o sembri ciò che il software concorrente già fornisce o manca. Avrai molte idee, su molti livelli diversi di astrazioni. Se tra queste idee e input trovi affermazioni problematiche chiare, brevi e precise, non c'è bisogno di gonfiarle artificialmente in una "epopea". Usi un "epico" se non riesci ad abbattere immediatamente l'idea per un requisito a un sotto-problema più piccolo, e usi un "user-story" quando il tuo input può essere immediatamente scritto sotto forma di una "piccola user story" . E questo è tutto.

Questo è in gran parte indipendente dall'essere in un punto nel tempo in cui nessun software è scritto finora (quella che tu chiami "fase di scoperta"), o un momento nel quale hai già un prodotto funzionante e puoi descrivere qualsiasi nuovo requisito in forma di una modifica al software esistente (che dovrebbe essere il caso del 99% in agile). In effetti, quando si ha un prodotto funzionante di una certa dimensione, sarà sicuramente più semplice descrivere in dettaglio le diverse esigenze facendo riferimento al prodotto esistente e scrivendo una piccola storia utente che descrive il requisito sotto forma di una richiesta di modifica. Tuttavia, anche se il prodotto ha già molte funzionalità, si aspetta che gli utenti escano nuove idee in qualsiasi momento che richiedano un "epico" come forma appropriata di descrizione.

Si noti inoltre che il tipico "ciclo di vita di un'epica" è che sarà suddiviso in cima alle storie utente che possono essere sviluppate individualmente (e non viceversa), perché un'epica è in genere troppo grande per essere sviluppata in uno sprint. Potrebbero esserci casi in cui molte "user story" individuali e dettagliate ispirano un "epico", perché si ottiene un "quadro più ampio" da una raccolta di idee - ma non ha senso gettare via i relativi utenti, perché ne avrai bisogno per la pianificazione dettagliata dello sprint in un secondo momento.

Risposta breve: epics può sempre essere definito mentre il prodotto è vivo

Risposta lunga: dipende un po 'da come si usano le epiche e si sviluppa la roadmap del prodotto. Ho visto fondamentalmente 2 modi di utilizzare finora.

1. Epiche come "grandi storie di utenti"
2. Epiche come livello organizzativo sopra le storie degli utenti

Le Epic come "grandi storie di utenti" sono quelle che vengono usate principalmente quando le persone parlano di epopea. Ogni volta che ottieni nuovi requisiti e sono troppo complessi o non abbastanza concisi, puoi metterli in un epico e nel backlog per iniziare a lavorare. Durante le sessioni di perfezionamento si approfondiscono i requisiti per le user story piacevolmente implementabili e alla fine l'epica svanisce dal backlog, solo diciamo 12 storie utente che sono state create da essa. Succede tutto il tempo durante un prodotto è vivo. Ogni nuova, grande richiesta di funzionalità porterà a una nuova epopea.

Le Epiche come livello organizzativo sopra le storie degli utenti è ciò che ho visto spesso nei luoghi in cui l'agile incontra i classici mondi aziendali. È quindi solo uno strato di astrazione nelle storie degli utenti. Un po 'come le categorie che vengono spesso definite all'inizio dello sviluppo di un prodotto (ad esempio durante la fase di scoperta). Ad esempio "nuovo cliente", "stampa", ecc. Potrebbero esserci nuove categorie (= epiche) che verranno in futuro, ma solo se cambi la roadmap del prodotto per includere qualcosa di completamente nuovo in futuro.

Se puoi scegliere il tuo modo di lavorare, vai al # 1. Ho incluso # 2 qui come esempio su come l'epica è usata molto nella pratica, non come opzione raccomandabile.

Direi che l'epopea dovrebbe venire prima delle storie (supponendo che tu abbia degli obiettivi semestrali). L'idea dell'epica secondo me è di tracciare progetti più grandi. In cascata il ciclo di sviluppo sarebbe spesso di mesi, i team più agili eseguono scali di 2 settimane. Non puoi fare qualcosa di estremamente significativo in 2 settimane, quindi come fai a tenere traccia di queste idee più grandi? Con epopea.

Nella mia squadra, le epiche sono solo un tag. È un'idea, niente di più. Prendiamo ad esempio l'implementazione di un nuovo servizio di gestione degli account, operazione che potrebbe richiedere diversi mesi per uno o due team di scrum per completare tutte le funzionalità richieste dal mercato. In tal caso creeremo un tag epico chiamato account-management-service e taggare tutte le nostre storie ad esso correlate. In realtà questo aiuta solo a organizzare le cose. Tenendo presente l'idea della grande immagine, puoi iniziare a scrivere queste storie di utenti più piccole che possono e devono essere completate in 2 settimane o meno.

In molti casi i film epici non sono necessari. Se ho già un'API REST funzionante e i consumatori ne chiedono solo un paio di nuovi endpoint per consegnare i dati in un formato più efficiente, ad esempio, non c'è molto bisogno di un'epica qui. Scriviamo una storia e si fa in uno sprint ed è uno sforzo relativamente indipendente. Se la tua squadra ha una visione in atto che richiederà mesi per essere implementata, sarebbe un buon momento per affondare le tue storie in "epopee" in modo da avere una maggiore visibilità sui progressi verso questi obiettivi più grandi, anche se non dovrebbero davvero avere effetto storia, pianificazione, o qualsiasi altra cosa nella tua giornata.

Altre organizzazioni potrebbero usarle in modo diverso, per me questo è l'uso più sensato per i poemi epici.