Differenza tra Product Backlog, Sprint Backlog e Product Increment

Differenza tra Product Backlog, Sprint Backlog e Product Increment

Framework Scrum

Scrum viene identificato come un esempio di modello agile, attualmente il più usato tra le grandi società informatiche. Come spiegato in un altro articolo su SCRUM, la metodologia Scrum è un esempio di modello agile che può essere usato per gestire e controllare lo sviluppo di prodotti software complessi. Scrum definisce un set di attività che consentono ai team di offrire più valore al cliente, in meno tempo. Queste attività consentono al cliente di esaminare, guidare ed influire sul lavoro dei team durante l’intera fase di sviluppo. Come vedremo in seguito, questo approccio non tenta di definire tutti i requisiti e le caratteristiche del prodotto all’inizio del progetto ma, dopo ogni iterazione (chiamata sprint), incrementa e perfeziona ciò che è stato creato in precedenza.
Essendo agile, Scrum si basa strettamente sui valori citati nel Manifesto Agile: è importante notare come, per ottenere i risultati sperati, i team di sviluppo debbano riconoscere ed apprezzare questi valori e principi, che costituiscono il fondamento di tutti i processi agili.

Framework Scrum

 

Il cofondatore di Scrum Ken Schwaber, introdusse nella metodologia un processo fondamentale, il processo di controllo, basato su tre rami fondamentali:

  1. Trasparenza: ogni aspetto del processo che influenza il risultato deve essere visibile e conosciuto da ciascun membro coinvolto nel progetto. Gli aspetti significativi, soprattutto, devono essere visibili ai responsabili del lavoro. La trasparenza richiede che tutti quegli aspetti siano definiti da uno standard comune, in modo tale che i membri condividano una comune comprensione di ciò che deve essere fatto. Ad esempio: un linguaggio comune di riferimento al processo deve essere condiviso da tutti i partecipanti al progetto.
  2. Ispezione: tutti gli aspetti del processo devono essere controllati con elevata frequenza affinché gli scostamenti indesiderati possano essere rilevati con facilità e tempestività. Inoltre, i clienti devono ispezionare frequentemente le funzionalità implementate e il progresso verso l’obiettivo fissato in modo da rilevare le variazioni non richieste. I controlli non devono però essere così frequenti da superare la soglia di tolleranza e rappresentare un’interruzione al lavoro: sono più utili quando eseguiti raramente ma in modo preciso ed approfondito.
  3. Adattamento: se chi ispeziona verifica che uno o più aspetti del processo sono al di fuori dei limiti accettabili e che il prodotto finale non potrà sicuramente essere approvato, bisogna regolare il processo e riportarlo dentro al range stabilito. Questo adattamento deve essere portato a termine il più rapidamente possibile, per ridurre al minimo l’uscita dal range.

Solitamente, il processo di controllo è gestito dagli sviluppatori con molta esperienza e maggiormente informati.

Ruoli, meeting e artefatti in Scrum

Il modello Scrum è costruito su tre principali componenti: ruoli, meeting e artefatti.

Ruoli

Ci sono tre ruoli distinti riconoscibili all’interno del processo di sviluppo: il proprietario del prodotto, il team e lo Scrum Master.
Il proprietario del prodotto (Product Owner) è il responsabile dell’ottenimento del finanziamento iniziale e di quelli in corso d’opera, creando e definendo i requisiti globali, l’indice ROI (Return On Investment) che si vuole realizzare e rilasciando una prima stesura del piano del progetto.
Il compito più importante del Product Owner è di massimizzare il valore del prodotto e il lavoro svolto dal team. Ha la responsabilità esclusiva di gestire il Product Backlog.

Il proprietario del prodotto è solitamente un manager che conosce ciò che deve essere costruito per realizzare il progetto e come il processo di sviluppo dovrebbe progredire. Il Product Owner è quindi una persona, non un comitato. Può però rappresentare un desiderio di un comitato nel Product Backlog, ma chiunque voglia cambiare la priorità di un elemento deve convincere il Product Owner.

Affinché il ruolo Product Owner abbia successo, all’interno dell’organizzazione tutti devono rispettare le sue decisioni. A nessuno è permesso dire al Team di lavorare con un diverso ordine di priorità e in maniera differente da quanto disposto dal proprietario del prodotto, e i Team non sono autorizzati ad ascoltare chi sostiene il contrario.
Il team è il responsabile dell’implementazione delle funzionalità descritte dai requisiti espressi.
I team sono autogestiti, auto-organizzati (il ruolo di leader non è fisso ma cambia a seconda delle necessità espresse in ogni iterazione) e interfunzionali al fine di massimizzare la performance loro e degli altri team.

Solitamente, il team è composto da 5-10 membri che lavorano sul progetto a tempo pieno: i singoli membri hanno diverse competenze specialistiche e aree di focus. Tutti i membri del team sono responsabili sia del successo che del fallimento della realizzazione dei sottoprogetti o, in casi estremi, dell’intero progetto.
I team non contengono sotto-team che si dedicano a particolari campi, come analisi o business.

Lo Scrum Master è il ruolo assunto tradizionalmente dal manager del progetto di un team leader. È responsabile di garantire che i valori, le prassi e le regole di Scrum vengano promulgate e, soprattutto, applicate. Lo Scrum Master è inoltre responsabile di eliminare qualsiasi impedimento posto agli sviluppatori durante il processo di sviluppo.

Lo Scrum Master lavora sia per il Product Owner, che per il team di sviluppo. Esso opera per il Product Owner in diversi modi:

  • Trova tecniche per la gestione efficace del progetto
  • Comunica con chiarezza gli obiettivi e la visione al team di sviluppo
  • Aiuta la pianificazione a lungo termine del prodotto
  • Presiede i meeting se richiesto dal Product Owner

Lo Scrum Master lavora anche per il team:

  • Insegna e guida il team per creare prodotti di alto valore
  • Elimina qualsiasi ostacolo al progresso
  • Aiuta a capire e mettere in atto Scrum nel processo di sviluppo
  • Aiuta nell’aumento di produttività

Meeting

Il secondo componente identificabile nel modello Scrum è il meeting.
Ci sono molti meeting in questo modello: il Daily Scrum Meeting (TDSM), il Daily Scrum of Scrums Meeting (TDSSM), lo Sprint Planning Meeting (TSPM) e lo Sprint Review Meeting (TSRM).

Il Daily Scrum Meeting è un meeting tenuto ogni giorno tra lo Scrum Master (che lo dirige come “chair”) e i team. Ha una durata di 15 minuti, nella quale i team espongono cosa hanno terminato dal meeting precedente, quali parti saranno realizzate prima del prossimo meeting e quali ostacoli hanno riscontrato. Questo meeting facilita molto la comunicazione, identifica e rimuove gli impedimenti riscontrati, evidenzia e promuove le rapide prese di decisione e migliora la trasparenza (come ramo del processo di controllo descritto in precedenza). Bisogna dire, però, che il Daily Scrum Meeting non serve a risolvere i problemi riscontrati dai team bensì invoglia i team a fare affidamento sugli altri e sullo Scrum Master affinchè il lavoro possa procedere nel modo più conveniente e senza intralci.

Il Daily Scrum of Scrums Meeting è un altro breve meeting giornaliero che segue la stessa forma del Daily Scrum Meeting. L’unica ragione per la quale si tiene questo meeting è riuscire a sincronizzare il lavoro tra i vari team che si occupano del progetto, favorendo l’integrazione, la sovrapposizione e la comunicazione.

Lo Sprint Planning Meeting è un meeting che si tiene una volta al mese all’inizio di ogni sprint (ossia l’iterazione); lo Scrum Master, il proprietario del prodotto e il team si riuniscono per discutere su ciò che dovrà essere completato nello sprint seguente, che dura solitamente 30 giorni. Questo meeting si suddivide in due momenti chiave: nel primo, si modifica e si stila il backlog (Product Backlog): si tratta fondamentalmente di una lista contenente tutti i requisiti del progetto. In seguito, il team definisce formalmente gli obiettivi che si prefissa di raggiungere al termine dello sprint che sta per iniziare. Nel secondo momento chiave del meeting, i membri del team si occupano di suddividere il progetto in tante sottoparti minori (lo Sprint Backlog), affinché tutte queste sottoparti più semplici possano essere iniziate e finite nel singolo sprint che sta per iniziare.

Lo Sprint Review Meeting è, come il precedente, un meeting che si tiene mensilmente, ma alla fine dello sprint. Partecipano il proprietario del prodotto, il team e i clienti (stakeholder). Durante il meeting, i membri del team mostrano ai clienti e al proprietario del prodotto tutto ciò che è stato sviluppato durante lo sprint appena concluso. La differenza tra lo Sprint Review Meeting e un meeting tradizionale è l’informalità con la quale il team dimostra le funzionalità sviluppate, informalità che non crea al team alcun tipo di pressione e distrazione dal lavoro.

Artefatti: Product Backlog, Sprint Backlog e Product Increment

Il terzo ed ultimo componente del metodo Scrum è identificabile negli artefatti, o oggetti, e sono: il Product Backlog, lo Sprint Backlog e il Burndown Chart (anche chiamato Product Increment).

Il Product Backlog o, semplicemente, backlog, è una lista contenente i requisiti del progetto, ordinati in base alla loro priorità. La priorità viene definita in base alla user story relativa, alla complessità, all’importanza sul mercato, alla stima dell’ammontare di ore o giorni di lavoro che si pensa verranno impiegate per realizzare quel requisito (tutto ciò durante lo Sprint Planning Meeting). Sulla base di questa stima, viene definita la velocità del team e lo sforzo speso durante lo sprint seguente. Diversamente dai progetti tradizionali, il backlog è creato e gestito direttamente dal proprietario del prodotto.

Similarmente, lo Sprint Backlog è un sottoinsieme di requisiti del Product Backlog (di solito quelli con priorità più alta), che vengono scelti per essere sviluppati in un determinato sprint. Diversamente dal Product Backlog, questo backlog viene incrementato ogni giorno e può contenere fino ad un massimo di 300 requisiti da sviluppare. Inoltre, lo Sprint Backlog è interamente creato e gestito dai membri del team di sviluppo del progetto.

L’ultimo artefatto della metodologia Scrum è il burndown chart, anche conosciuto con il nome di Product Increment. Questo, è un grafico accessibile da tutti i membri che lavorano al progetto, e mostra lo sviluppo del lavoro nel tempo (nel grafico, il tempo è rappresentato sull’asse delle ascisse e il lavoro sull’asse delle ordinate). Ci sono tre tipi di burndown chart comunemente usati: lo sprint burndown chart (mostra il progresso dello sprint in corso), il release burndown chart (mostra il progresso della release) e il product burndown chart (mostra il progresso globale dell’intero progetto). L’obiettivo del burndown chart è di fornire informazioni in maniera chiara, immediata e facilmente comprensibile.

Differenza tra Product Backlog, Sprint Backlog e Product Increment

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *