Approfondimenti Agile PMI-ACP

Epica e SCRUM

“Preparazione Esame di Certificazione Agile PMI-ACP®”

  Modulo di Iscrizione

 Per consultare questi approfondimenti, devi essere almeno registrato al sito (Registrati se non lo sei già)

 

Cosa rappresentano i termini:  Epics, Theme e  User Story per la Metodologia Scrum ?

Definizione di Epica

L’Enciclopedia Treccani alla voce “Epica” riporta: “Narrazione poetica di gesta eroiche, spesso leggendarie. Si distinguono in 1) un’epica tradizionale (poemi omerici, Canzone dei Nibelunghi), che fa riferimento ai racconti elaborati dalla tradizione, e 2)un’epica riflessa, in cui l’elaborazione fantastica del racconto storico e la sua formazione in poema sono opera individuale (l’Eneide di Virgilio o la Gerusalemme liberata di T. Tasso).

Ampie e fondamentali sono l’epica egizia, mesopotamica (Epopea di Gilgamesh) e indiana (Mahabharata e Ramayana). I più antichi poemi epici rimastici sono l’Iliade e l’Odissea, attribuiti a Omero  al quale gli antichi attribuirono anche i poemi perduti del cd. ciclo epico, per la maggior parte scritti tra il 7° e il 6° sec. a.C.”

“Epica“, dal greco ‘épos’ ha diversi significati: parola, discorso, racconto, poesia, canto epico, etc. Questo genere letterario comprende composizioni del terzo millennio avanti Cristo, delle popolazioni mesopotamiche e indiane, opere greche (Iliade e Odissea)  e romane (Eneide), fino all’epoca medievale e rinascimentale. La loro caratteristica principale è che si tratta di componimenti molto vasti, in versi o in prosa, per esaltare le gesta di qualcuno. Se scritti in versi si possono chiamare anche poemi.

Cosa sono gli “Epics” di Scrum

A detta degli esperti, sul concetto di “Epics” nella metodologia Scrum c’è un po’ di confusione che si può chiarire soltanto spiegando anche il significato di: User Story, Epics e Themes.

Storia, Epica e Tema dovrebbero assumere lo stesso significato in una terminologia comune e condivisa.

Per definizione, con SCRUM, questi tre termini assumono il seguente significato:

User Story

Una “User Story” è ciò che desidera l’utente. Il più delle volte vengono  scritte in un formato convenzionale, ma non obbligatoriamente. L’importante è farsi comprendere. Una Story è una unità di lavoro concordata tra sviluppatori e stakeholder, nel nostro caso tra Product Owner e Team di Sviluppo. Per convenzione, una user story può essere così espressa: “Come utente, vorrei impostare le mie credenziali, così potrò accedere al sistema.”

Il formato tipico è: “As a , I want so that .”

Epic 

Un “Epic” per Scrum è una user story più grande. Non c’è una soglia magica dopo la quale una storia  diventa una “Epica”. Si tratta solo di una storia considerata più grande delle altre. Così “Epic” è solo un’etichetta che attribuiamo ad una storia ritenuta più grande. Quindi una storia grande a piacere se etichettata “Epica” lascia dello spazio a ulteriori approfondimenti, perché sospettiamo che abbia degli altri valori da esprimere e in prima battuta non siamo in grado di specificarli. Le “Epiche” sono simili ai “Temi” nel senso che possono rappresentare più Storie, ma  il più delle volte si tratta di una storia più grande delle altre o non ancora sviscerata del tutto.

Al contrario dei “Temi” una Epica comprende un unico workflow per un utente, perciò è più corretto assimilarla ad una grande storia. Una importante differenza tra Tema e Epica è che le storie di un’Epica possono essere realizzate in modo indipendente, anche se il valore di business non si ottiene finché non si completa l’intera Epica, anche se non avrebbe tanto senso rilasciare un’Epica con storie sottostanti ancora da realizzare. Invece, le storie che fanno parte di un tema sono correlate fra loro, anche se ognuna è indipendente  abbastanza per poter essere rilasciata separatamente, producendo il proprio valore di business.

Theme

Infine “Theme” è un insieme di “User Stories”. Una serie di storie hanno una affinità perché riguardano tutte lo stesso tema: finanza, piuttosto che produzione. Anche questo è semplicemente un modo per dividere le storie in categorie più o meno grandi. Si tratta di un gruppo di storie correlate. Spesso le storie contribuiscono allo stesso obiettivo. Per esempio si riferiscono tutte allo stesso cliente.

In Scrum, il team di sviluppo ha la responsabilità di stimare l’impegno di ogni user story. Se una richiesta  è vaga o troppo grande per essere realizzata in uno Sprint allora siamo di fronte ad un’EPICA. Un’Epica richiede, di solito, più di 12 ore, perciò non è realizzabile in un giorno, come sarebbe preferibile secondo la metodologia Agile-Scrum.

Se un team di sviluppo azzardasse la stima di un’Epica, il Product Owner potrebbe crearsi delle false attese, pur essendo  di fronte ad una semplice stima.  Tali stime possono essere utili per fare delle previsioni, ma non per pianificare il lavoro di uno Sprint. Sarebbe come andare al supermercato con una certa somma di denaro da spendere, senza un’idea di cosa comprare. Perciò, è preferibile suddividere un’Epica in tante piccole storie per poterle stimare con maggiore precisione.

Cosa è la Metodologia SCRUM

Scrum è una metodologia di sviluppo incrementale di un prodotto che utilizza una o più funzioni trasversali e un team auto-organizzato di circa sette persone. Scrum indica una struttura di ruoli, riunioni, regole e componenti. Il team di progetto è responsabile dell’adattamento dei processi di sviluppo del prodotto.

La metodologia Scrum prevede iterazioni di lunghezza fissa, dette SPRINT, di solito, da due settimane a  30 giorni, in modo che, ad ogni iterazione, il team possa consegnare un incremento finito di prodotto testato.

Lo scopo è dare il prima possibile dei risultati tangibili, sebbene parziali, permettendo al cliente/utente di esprimere le sue osservazioni e richiedere modifiche per tutto il ciclo di vita del progetto.

Il metodo tradizionale (waterfall), al contrario,  esige che prima siano raccolti ed accettati tutti i requisiti e poi si proceda in modo sequenziale: analisi, disegno, codifica, integrazione, test e rilascio in produzione.

Con il metodo Scrum  il team di progetto, di volta in volta, si impegna solo sul contenuto del prossimo SPRINT.

Il team SCRUM collabora con l’utente per coprire  insieme gli ulteriori dettagli dei requisiti del prodotto da realizzare, ideale per lo sviluppo di prodotti complessi, dove inizialmente l’utente ha difficoltà a fornire tutte le specifiche di prodotto.

L’adozione parziale di Scrum espone l’azienda e le persone a grossi rischi, dove le responsabilità sono ripartite tra i vari ruoli che di seguito vedremo.

Ruolo del Product Owner

Il Product Owner interagisce con il team di progetto in rappresentanza dell’utente. Il suo compito è delicato, perché da un lato deve proteggere il team di progetto e dall’altro deve portare i risultati soddisfacendo le aspettative degli utenti. Le sue responsabilità principali sono:

• Massimizzare il ROI dello sviluppo del prodotto.
• Avere e proteggere la visione del prodotto.
• Rivedere continuamente le priorità del “backlog”, aggiustando i piani a lungo termine.
• Risolvere eventuali conflitti sui requisiti del prodotto.
• Accettare o respingere le parti incrementali del prodotto rilasciate ad ogni Sprint.
• Decidere se e quando consegnare  il prodotto all’utente finale.
• Decidere se continuare lo sviluppo o interromperlo.
• Fare l’interesse degli stakeholder.
• Contribuire come membro del team.
• Svolge un ruolo di leadership.

Ruolo del Team di Sviluppo

Il team di sviluppo è composto di professionisti di ogni tipo, compreso esperti del settore, che assumono le seguenti responsabilità:

• Il gruppo si auto organizza e si auto gestisce senza ruoli assegnati dall’esterno.
• Negozia il suo impegno con il Product Owner, per ogni Sprint.
• È autonomo su come svolgere il proprio lavoro.
• È molto collaborativo.
• È più efficace se tutti i membri del team stanno nella stessa stanza, specie all’inizio.
• È più efficace se è composto di persone a tempo pieno sul lungo termine.
• È composto mediamente di 7 membri (+-2).
• Svolge un ruolo di leadership collettivo.

Ruolo dello Scrum Master

Lo Scrum Master è responsabile dell’applicazione dei processi.

• Facilita il processo Scrum.
• Aiuta il team a rimuovere ogni impedimento.
• Definisce un ambiente di lavoro che possa auto organizzarsi.
• Raccoglie informazioni empiriche per le previsioni.
• Protegge il team da interferenze e distrazioni esterne.
• Marca la tempificazione (timeboxing).
• Evidenzia i manufatti (template) che offre la metodologia Scrum.
• Promuove il miglioramento dei processi.
• Per definizione, NON ha nessuna autorità sul Team di Sviluppo.
• Svolge un ruolo di leadership.

Riunioni Tipiche della Metodologia Scrum

Sprint Planning Meeting

Product Owner e Team di Sviluppo si incontrano per negoziare quali argomenti il team cercherà di coprire durante il prossimo Sprint.

• Il Product Owner ha la responsabilità di indicare quali argomenti sono più importanti dal punto di vista del business.
• Il Team di Sviluppo  è responsabile di scegliere l’ammontare di lavoro che ritiene di poter implementare senza  accumulare ritardo.

In presenza di incertezze, essi devono lavorare insieme al meglio, apprendendo da esperienze precedenti.

Finché un team non ha imparato a stimare correttamente cosa inserire in uno Sprint, tenderà a ridurre gli argomenti sui quali impegnarsi. Se non si eliminano le vecchie abitudini, si rischia di finire in ritardo. Se i primi argomenti del backlog di Prodotto non sono stati ben rifiniti, bisogna dedicare del tempo a farlo  a inizio riunione.

A fine riunione,  il Team  deve essere in grado di produrre la lista dei task che ha accettato di lavorare durante lo Sprint. La riunione dura massimo 8 ore, per uno Sprint di 30 giorni. Come risultato della riunione, il Team si impegna ad eseguire alcuni argomenti, specificando  quali task eseguirà durante lo Sprint.

Daily Scrum

Ogni giorno alla stessa ora il Team di Sviluppo si  riunisce per 15 minuti. Ogni membro racconta agli altri: 1) cosa ha fatto il giorno prima,  2)  cosa farà oggi  e 3) quali ostacoli ha incontrato.

La riunione deve essere molto breve. Se ci sono argomenti da approfondire si possono discutere dagli interessati in un incontro successo. Il Team fa bene a tenere un Log di 1) elenco dei Task in lavorazione, 2) grafico degli Sprint realizzati (burndown chart) e 3) la lista degli ostacoli. Può essere utile che il Product Owner partecipi a queste brevi riunioni, però bisogna evitare che il Product Owner domini o condizioni la riunione. Il team  deve essere libero di esprimersi sulle reali stime per realizzare il lavoro atteso. Questa riunione serve a cancellare le vecchie abitudini di lavorare separatamente. Tutti i membri del Team devono sorvegliare per impedire di cascare nel vecchio approccio. Ad esempio, rivolgersi solo allo Scrum Master è indice che non si è compreso che bisogna auto governarsi con il resto del team.

Sprint Review Meeting

Alla fine di ogni Sprint, il Team mostra l’incremento di prodotto realizzato al Product Owner e a chi è interessato. La riunione deve essere una DEMO e non un report. Dopo la dimostrazione, il Product Owner  rivede gli impegni assunti  dal Team nella riunione di inizio Sprint e dichiara cosa considera fatto (done) e cosa considera  non ancora consegnabile. Gli argomenti non completati rientrano nel Product backlog con la priorità che gli assegna il  Product Owner.

Lo Scrum Master aiuta il Product Owner e gli Stakeholder interessati a convertire  il loro feedback nel nuovo Product Backlog.  Ad ogni fine Sprint questa riunione può scoprire ulteriori requisiti di prodotto, comportando la revisione delle priorità da parte del Product Owner.

Alla riunione, gli stakeholder esterni controllano il lavoro prodotto e chiariscono i loro requisiti. Con la demo il team evidenzia come funziona il prodotto appena realizzato, mentre gli stakeholder intuendo come effettivamente servirebbe, avanzano  o chiariscono i requisiti per l’iterazione successiva.

Sprint Retrospective Meeting

Ogni Sprint si conclude con una riunione retrospettiva, dove il Team riflette sul processo appena utilizzato, analizzando il proprio comportamento e intraprendono azioni di miglioramento per gli Sprint successivi.

Lo Scrum Master cerca alternative ai vecchi comportamenti. La riunione esige la fermezza di analizzare solo ciò che non ha funzionato bene (in termini di comportamento), senza scadere  in discussioni conflittuali.  Un comune ostacolo alla trasparenza è la presenza di manager che poi faranno l’appraisal dei membri del Team. Un altro ostacolo è la fretta con la quale si vuole chiudere la riunione. I sacri testi (Agile Retrospectives) dicono invece che una buona retrospezione prevede almeno: impostare la riunione, raccogliere i dati, generare la visione, decidere cosa fare e infine chiudere la retrospezione.

Un altro grosso ostacolo può essere il team distribuito, rispetto a quello che opera nella stessa stanza. Spesso si incontrano ostacoli organizzativi. Una volta rimosso l’ostacolo per il singolo Sprint, lo Scrum Master  deve operare per estendere quella soluzione all’intera organizzazione per i progetti futuri.

Lo Scrum Master deve utilizzare tutte le tecniche per facilitare le retrospezioni in modo da coltivare la cultura della collaborazione e continuare a far crescere la produttività dei team di sviluppo. Tutte queste riunioni vengono organizzate dallo Scrum Master, il quale, però, non ha nessun potere decisionale  rispetto al Team e al Product Owner.

Backlog Refinement Meeting

Molti argomenti inizialmente hanno bisogno di essere approfonditi  perché troppo vasti  e poco compresi. È opportuno dedicare un momento di riflessione per ogni Sprint per  consentire al Product Owner  di chiarire il senso di ciò che entrerà nella prossima riunione di pianificazione dello Sprint.

In questa riunione il team stima l’impegno richiesto per ogni argomento del Backlog e fornisce informazioni utili al Product Owner affinché possa stabilire le priorità anche in base all’impegno.

Gli argomenti più vaghi vengono spezzettati per chiarire i vari aspetti tecnici e di business.  A volte, un incaricato del Team insieme al Prodcut Owner e altri stakeholder razionalizzano gli argomenti, prima di coinvolgere l’intero Team di sviluppo.

Lo Scrum Master, in questi casi, promuove rigorosi criteri di accettazione del lavoro da considerare “FATTO”  compreso i test  ed il refactoring (una modifica all’interno di una struttura software per renderla più facile da comprendere  e meno costoso modificarla senza cambiare il suo comportamento. … è un modo ordinato per pulire del codice che riduce al minimo la possibilità di introdurre errori.)

Normalmente gli argomenti vengono esposti sotto forma di “User Story”. Le storie più grandi vengono chiamate “Epics”, come detto sopra. Ce la tendenza  a riprodurre le fasi dell’approccio waterfall, nonostante non dia alcun valore dal punto di vista del business. Invece, con Agile, bisognerebbe imparare a dividere le grandi storie (epics) in tante piccole “user stories” dove ognuna rappresenti un dispositivo o una funzione.

Poiché molti utenti non utilizzano tutte le funzioni di un prodotto, è bene concentrarsi sulle storie più importanti di un “epics”, secondo il principio della legge di Pareto (80/20).

Questa riunione non ha un nome preciso. Alcuni la chiamano anche “Backlog Grooming” oppure “Backlog Maintenance” o “Story Time”.

Maintenance backlog – Maintenance backlog is made up of work that needs to be completed for safety reasons and to avoid further asset breakdown (e.g. an oil change for your truck is scheduled for every 5000 miles). When the odometer reading hits 5000 miles and the work is due this task will sit in your maintenance backlog until it is complete. The longer it sits there, the more precarious it can become.

Componenti Scrum

Il lavoro di un Team Agile viene espresso con una serie di strumenti e documenti che aiutano a tenere tutto sotto controllo con il minimo sforzo:

Product Backlog

• Elenco ordinato per priorità di tutte le funzionalità desiderate.
• Visibile a tutti gli stakeholder.
• Qualsiasi stakeholder (compreso il Team) può aggiungere un argomento (Story).
• Continuamente  rimesso in priorità dal Prodcut Owner.
• I primi argomenti sono più dettagliati di quelli in fondo alla lista.
• Aggiornati durante la riunione di  “Backlog Refinement Meeting”.

Product Backlog Item (argomento – story)

• Descrizione di Cosa e non Come  si desidera una funzionalità.
• Scritta in forma di “User Story”.
• Può avere specifici criteri di accettazione.
• L’impegno viene stimato dal Team in giorni o ore lavorative.

Sprint Backlog

• Argomenti (Stories)  in esecuzioni negoziato tra Team e Product Owner durante la riunione di Pianificazione dello Sprint.
• Impegno fissato per ogni Sprint.
• I task di ogni story vengono identificati dal Team.
• Durante l’esecuzione il Team può scoprire la necessità di altri task per realizzare quanto promesso.
• Visibile all’intero Team.
• Referenziato durante il “Daily Scrum Meeting”.
  – Argomenti (Stories)  – Task non avviati – Task  in esecuzione  – Task completati.

Sprint Task

• Specifica come  realizzare ogni attività  di una story.
• Richiede un giorno di lavoro o meno.
• L’impegno ulteriore viene stimato giornalmente, in ore.
• Durante l’esecuzione una persona è responsabile del task.
• Possedute dall’intero Team; ci si aspetta la massima collaborazione.

Sprint Burndown Chart

• Le ore totali di impegno rimanente sui task  in uno Sprint.
• Riviste giornalmente, così  possono andare su e giù.
• Servono a facilitare l’auto-gestione del Team.
• Linee di tendenza aiutano ad incoraggiare la collaborazione.
• Confuso spesso con un report di management. Lo Scrum Master dovrebbe eliminare questo report se diventa un ostacolo all’auto gestione del Team.

Product / Release Burndown Chart

• Traccia l’impegno rimanente tra uno Sprint e il successivo.
• Può utilizzare unità relative come gli Story Points  sull’asse Y.

 Modulo di Iscrizione

Modulo di Comunicazione