Gli Artefatti e il Product Backlog (PDF)

**Gli Artefatti** Gli Artefatti di Scrum rappresentano il lavoro e il valore in diversi modi utili al fine di fornire trasparenza e opportunità di ispezione e adattamento. Gli artefatti definiti da Scrum sono progettati - nello specifico - per massimizzare la trasparenza delle informazioni chiave,...

**Gli Artefatti** Gli Artefatti di Scrum rappresentano il lavoro e il valore in diversi modi utili al fine di fornire trasparenza e opportunità di ispezione e adattamento. Gli artefatti definiti da Scrum sono progettati - nello specifico - per massimizzare la trasparenza delle informazioni chiave, di modo che ognuno abbia lo stesso livello di comprensione dell'artefatto. **Product Backlog** Il Product Backlog è un elenco ordinato di tutto ciò che potrebbe essere necessario al prodotto ed è l'unica fonte di requisiti per le modifiche da apportare al prodotto. Il Product Owner è il responsabile del Product Backlog, compreso il suo contenuto, la sua disponibilità e l'ordinamento dei suoi elementi. Ricordiamoci che il Product Backlog non è un elenco di cose da completare, ma piuttosto un elenco di tutte le funzionalità desiderate per il prodotto ed è da considerarsi mai completo. La sua prima stesura definisce solo i requisiti inizialmente conosciuti e meglio compresi. Il Product Backlog evolve così come il prodotto al quale si riferisce e l'ambiente stesso nel quale sarà utilizzato. Ricordatevi che deve essere sempre dinamico e cambia continuamente per identificare ciò che serve al prodotto per essere appropriato, competitivo e utile. Finché esiste un prodotto esiste anche il suo Product Backlog. Il Product Backlog elenca tutte le caratteristiche, le funzioni, i requisiti, le migliorie e le correzioni che costituiscono le modifiche da apportare al prodotto nelle future versioni. I suoi elementi hanno i seguenti attributi: descrizione, ordine, stima e valore. Il Product Backlog diventa un elenco più ampio ed esaustivo quando un prodotto acquisisce valore in seguito al suo utilizzo iniziale e non appena viene fornito feedback. I requisiti non smettono mai di cambiare e perciò il Product Backlog è un artefatto vivente. I cambiamenti nei requisiti di business, nelle condizioni di mercato o nell'ambito tecnologico possono causare cambiamenti all'interno del Product Backlog. Spesso capita che più Scrum Team lavorano insieme sullo stesso prodotto. Un singolo Product Backlog è usato per descrivere il lavoro da svolgere sul prodotto. Un attributo degli elementi del Product Backlog indica che sono pronti per essere lavorati. Il raffinamento del Product Backlog (Product Backlog refinement) è l'atto di aggiungere dettagli, stime e ordine agli elementi del Product Backlog. Questo è un processo continuo in cui il Product Owner e il Team di Sviluppo collaborano sui dettagli degli elementi del Product Backlog. Durante il raffinamento del Product Backlog, i suoi elementi sono riesaminati e rivisti. Lo Scrum Team decide come e quando il raffinamento è completato. Il raffinamento solitamente occupa non più del 10% della capacità del Team di Sviluppo. Tuttavia, gli elementi del Product Backlog possono essere aggiornati in qualsiasi momento dal Product Owner o a discrezione del Product Owner. Gli elementi ordinati più in alto sono più chiari e meglio dettagliati rispetto a quelli più in basso. Le stime sono più precise e si basano sulla maggiore chiarezza e maggior numero di dettagli; più basso è l'ordine di un elemento all'interno del Product Backlog e minore è il dettaglio. Gli elementi del Product Backlog che impegneranno il Team di Sviluppo durante lo Sprint sono rifiniti a tal punto che possano essere "Fatti" nel periodo massimo di uno Sprint. Durante lo Sprint Planning gli elementi del Product Backlog che possono essere "Fatti" dal Team di Sviluppo all\'interno di uno Sprint vengono dichiarati "Pronti" per un\'eventuale selezione. Gli elementi del Product Backlog solitamente acquisiscono questo livello di trasparenza attraverso le attività di raffinamento sopra descritte. Il Team di Sviluppo è responsabile di tutte le stime. Il Product Owner può̀ influenzare il Team di Sviluppo aiutando a capire e selezionare i compromessi ma, coloro che eseguiranno il lavoro sono gli stessi che effettueranno la stima finale. Monitorare l'avanzamento verso un Goal Il lavoro totale rimanente per raggiungere un obiettivo può essere calcolato in ogni momento. In occasione di ogni Sprint Review, il Product Owner tiene traccia del lavoro totale rimanente. Il Product Owner confronta questa quantità con il lavoro che era stato calcolato come rimanente durante le precedenti Sprint Review, al fine di valutare l\'avanzamento del lavoro correntemente stimato in rapporto alla scadenza desiderata per l\'obiettivo. Tale informazione è resa in maniera trasparente a tutti gli stakeholder. Vari indicatori di tendenza, come burndown o burnup, insieme ad altre pratiche proiettive sono stati già utilizzati per effettuare previsioni relative all\'avanzamento. Tali strumenti e tecniche si sono rivelati utili, senza però sostituirsi all\'importanza dell\'empirismo. In ambienti complessi, non è dato conoscere quello che accadrà in futuro, solo ciò che si è già verificato, può essere utilizzato per prendere decisioni in futuro. **Backlog Refinement/Grooming:** alla fine di uno Sprint, il team e il Product Owner si incontrano per assicurarsi che il backlog sia pronto per lo sprint successivo. Il team può rimuovere le User Story non pertinenti, crearne di nuove, rivalutare la priorità delle storie o suddividere le user story in task più piccoli. Lo scopo di questa riunione di \"preparazione\" è garantire che il backlog contenga solo elementi pertinenti e dettagliati e che soddisfino gli obiettivi del progetto. **Sprint Backlog** Lo Sprint Backlog è l\'insieme degli elementi del Product Backlog selezionati per lo Sprint, più un piano per fornire l\'Incremento del prodotto e per realizzare lo Sprint Goal. Lo Sprint Backlog è una previsione fatta dal Team di Sviluppo in relazione al lavoro necessario per rilasiciare le funzionalità che saranno presenti nel prossimo Incremento, basandosi sulla definizione di "Fatto". Lo Sprint Backlog rende visibile tutto il lavoro che il Team di Sviluppo identifica come necessario per raggiungere lo Sprint Goal. Lo Sprint Backlog è un piano con dettagli sufficienti affinché i cambiamenti in atto possano essere compresi nel Daily Scrum. Il Team di Sviluppo modifica lo Sprint Backlog durante tutto lo Sprint e lo Sprint Backlog emerge durante lo Sprint. Ciò si verifica quando il Team di Sviluppo opera attraverso il piano e viene a conoscenza di più dettagli sul lavoro necessario a raggiungere lo Sprint Goal. Se e quando vi risulterà necessario svolgere del nuovo lavoro, il Team di Sviluppo lo aggiunge allo Sprint Backlog. Quando del lavoro viene eseguito o completato, la stima relativa al lavoro rimanente viene aggiornata. Se alcuni elementi del piano non sono più ritenuti utili, sono rimossi. Solo il Team di Sviluppo può cambiare il suo Sprint Backlog nel corso di uno Sprint. Lo Sprint Backlog è l\'immagine prodotta in tempo reale e altamente visibile del lavoro che il Team di Sviluppo prevede di compiere durante lo Sprint; è di esclusiva appartenza del Team di Sviluppo. **Monitorare l'avanzamento dello Sprint** In qualsiasi momento durante uno Sprint, tutto il lavoro rimanente nello Sprint Backlog può essere sommato. Il Team di Sviluppo tiene traccia della quantità di lavoro rimanente quantomeno ad ogni Daily Scrum e proietta la probabilità di raggiungere lo Sprint Goal. Tenendo traccia del lavoro rimanente attraverso lo Sprint, il Team di Sviluppo è in grado di gestire il proprio avanzamento. **Incremento** L\'Incremento è la somma di tutti gli elementi del Product Backlog completati durante uno Sprint e durante tutti gli Sprint precedenti. Alla fine di uno Sprint, il nuovo Incremento deve risultare "Fatto", il che significa che deve essere utilizzabile e deve incontrare la definizione di "Fatto" data dallo Scrum Team. Deve essere utilizzabile indipendentemente dal fatto che il Product Owner decida di rilasciarlo realmente o meno. **Trasparenza degli Artefatti** Una delle regole che dovete assimilare subito è che Scrum è fondato sulla trasparenza. Le decisioni per ottimizzare il valore e controllare il rischio sono prese in base allo stato attuale percepito degli artefatti. Nella misura in cui la trasparenza sia completa, tali decisioni hanno una base solida. Nella misura in cui gli artefatti non siano completamente trasparenti, tali decisioni possono essere imperfette, il valore può diminuire e il rischio può aumentare. Lo Scrum Master deve lavorare con il Product Owner, con il Team di sviluppo e con le altre parti coinvolte per capire se gli artefatti siano completamente trasparenti. Ci sono pratiche per gestire situazioni in cui la trasparenza non sia completa; in tali situazioni lo Scrum Master deve aiutare gli altri ad applicare le pratiche più appropriate. Lo Scrum Master può rilevare che la trasparenza sia incompleta ispezionando gli artefatti, percependo i pattern, ascoltando attentamente ciò che viene detto e rilevando le differenze tra i risultati attesi e quelli attuali. Compito dello Scrum Master è quello di lavorare con il Team di Scrum e con l\'organizzazione per aumentare la trasparenza degli artefatti. Questo lavoro di solito comporta una fase di apprendimento, una di persuasione ed una di cambiamento. La trasparenza non si ottiene da un giorno all\'altro, ma piuttosto attraverso un percorso. **Definizione di "Fatto"** Quando un elemento del Product Backlog o un incremento è considerato "Fatto", è necessario che tutti abbiamo la stessa precisa comprensione si cosa si intenda per "Fatto". Sebbene il significato di "Fatto" possa variare da Team a Team, i membri dello stesso Team di Scrum devono avere una comprensione condivisa di ciò che si intenda per lavoro completo, al fine di assicurare che ci sia trasparenza. Questa è la "Definizione di Fatto" per il Team ed è utilizzata per valutare quando il lavoro è completo sull'incremento di prodotto. La stessa definizione guida il Team di sviluppo a capire quanti elementi del Product Backlog è possibile selezionare durante lo Sprint Planning Meeting. Lo scopo di ogni Sprint è di fornire incrementi di funzionalità potenzialmente rilasciabili che aderiscono alla definizione attuale di "Fatto" per il Team. I Team di sviluppo forniscono ad ogni Sprint un incremento di funzionalità del prodotto. Questo incremento è potenzialmente utilizzabile. Un Product Owner può scegliere se rilasciarlo immediatamente. Ogni incremento è additivo a tutti gli incrementi precedenti ed è testato, garantendo che tutti gli incrementi lavorano insieme. Via via che gli Scrum Team maturano, ci si attende che la loro Definizione di "Fatto" si espanda per includere criteri più stringenti finalizzati ad una qualità maggiore.