Differenza tra Epic e User story nella metodologia Agile

Prima di definire la differenza tra Epic e User story è necessario introdurre alcuni concetti circa i prodotti di lavoro in un progetto Agile.

I prodotti di lavoro in una metodologia Agile tipicamente ricadono in una delle 3 categorie:

1. Prodotti di lavoro Business-oriented che descrivono cosa deve essere realizzato (per esempio specifiche dei requisiti) e come usarlo (per esempio documentazione utente).
2. Prodotti di lavoro di sviluppo che descrivono come il sistema è costruito (per esempio diagrammi entità – relazioni delle basi dati), ciò che effettivamente implementa il sistema (per esempio il codice) o che valuta singoli pezzi di codice (per esempio unit test automatizzati).
3. Prodotti di lavoro del test che descrivono come il sistema è testato (per esempio strategia di test e piano di test), ciò che effettivamente testa il sistema (per esempio test manuali e automatizzati) o che presenta i risultati del test.

In un tipico progetto Agile, è pratica comune evitare di produrre una gran mole di documentazione. Invece, ci si concentra di più sull’avere un software funzionante, insieme con test automatizzati che dimostrino la conformità con i requisiti. Questo invito a ridurre la documentazione si applica solo alla documentazione che non porta valore per il cliente. In un progetto Agile di successo, si deve bilanciare tra l’aumento dell’efficienza ottenuto riducendo la documentazione e la necessità di fornire una documentazione sufficiente per supportare il business, il test, lo sviluppo e le attività di manutenzione. Il Team deve decidere durante la pianificazione della release quale documentazione è richiesta ed a quale livello.

Tipici prodotti di lavoro orientati al business nei progetti Agile includono le user stories e i criteri di accettazione. Le user stories sono il formato Agile delle specifiche dei requisiti e devono spiegare come il sistema si deve comportare rispetto ad una singola caratteristica o funzione. Una user story deve definire una funzione sufficientemente piccola da essere completata in una singola iterazione. Insiemi più grandi di funzioni collegate o un insieme di sotto-funzioni che realizzano un singola funzione complessa, possono essere riferite come epics o in italiano: le epiche. Le epics possono includere user stories per diversi Team di sviluppo. Per esempio, una user story può descrivere quello che è richiesto a livello delle API (middleware) mentre un’altra story descrive quello che serve a livello di GUI (applicazione). Questi insiemi possono essere sviluppati in una serie di sprints. Ogni epic e le sue user stories devono essere associate a criteri di accettazione.

Un tipico prodotto di lavoro per lo sviluppatore nei progetti Agile è il codice. Gli sviluppatori Agile spesso creano anche unit test automatizzati. Questi test possono essere creati dopo lo sviluppo del codice. In alcuni casi, tuttavia, gli sviluppatori creano i test in modo incrementale, prima che sia scritta ciascuna porzione di codice, per fornire un modo per verificare, una volta che la porzione di codice sia scritta, se funziona come previsto. Mentre questo approccio è indicato come test first o sviluppo basato su test, in realtà i test sono più una forma di specifiche di progetto di basso livello eseguibili piuttosto che test.

Tipici prodotti di lavoro per i tester nei progetti Agile includono i test automatizzati, così come i documenti quali i piani di test, cataloghi dei rischi di qualità, test manuali, report dei difetti e logs dei risultati dei test. I documenti vengono acquisiti in modo più leggero possibile, il che spesso è anche vero per questi documenti nei cicli di vita tradizionali. I tester produrranno anche metriche dei test dai report sui difetti e sui risultati dei test e di nuovo si pone l’enfasi su un approccio leggero.