Compilazione e gestione del backlog del prodotto

Articolo
03/05/2013

Di Mitch Lacey.Proprietario, Mitch Lacey & Associates, Inc, un'azienda di consulenza che si specializza in adozioni e miglioramenti Agile e scrum.

Gennaio 2012

In questo articolo, Mitch Lacey illustra l'importanza di un backlog del prodotto, descrive cosa costituisce un buon backlog e fornisce alcune procedure consigliate per creare e gestire il backlog.

Si applica a

Application Lifecycle Management; Team Foundation Server

In questo articolo:

Introduzione
Backlog prodotto
- Storie utente
- Stima
- Priorità
Manutenzione backlog attiva
- Pulitura
Conclusione

Un backlog prodotto è un elenco ordinato per priorità di tutte le caratteristiche e le funzionalità necessarie a completare un progetto.Un buon backlog prodotto costituisce la base di tutti i team Agile ben funzionanti e presenta le caratteristiche seguenti:

Viene classificato in ordine di priorità per garantire che il team compili per prime le funzionalità più importanti.
È stimato dal team per fornire chiarezza al proprietario del prodotto e consentirgli di rispondere a domande come "quando saranno eseguite queste storie"?
Include tutto il lavoro necessario per completare il progetto.
È un documento dinamico che cambia continuamente e si evolve per riflettere le realtà corrente del progetto.

Un buon backlog prodotto non assicura automaticamente un buon software.Tuttavia, la mancanza di un buon backlog prodotto dà spesso come risultato un software incompleto che non soddisfa i requisiti dei clienti e delle parti interessate.

La gestione del backlog prodotto è un lavoro a tempo pieno.Le semplici tecniche consentono di modificare quello che può essere un processo dispersivo ed estremamente impegnativo in un processo interattivo e iterativo che efficacemente impegna i membri del team, i clienti e le parti interessate.È fondamentale, pertanto, apprendere tecniche affidabili per compilare, classificare in ordine di priorità e gestire il backlog del prodotto.

Backlog prodotto

Il backlog del prodotto è un elenco principale mutevole, con ordini di priorità, di tutte le caratteristiche e le funzionalità necessarie a completare il progetto.I backlog del prodotto includono in genere le storie utente di requisiti ad esempio.. requisiti), bug, attività di ricerca (punte) e i miglioramenti di progettazione.Questi elementi vengono stimati in unità astratte spesso chiamate punti della storia.

I backlog del prodotto includono tutto il lavoro che richiede il progetto e evolverà nel tempo.Analogamente, non contengono solo nuove funzionalità per un prodotto ma anche correzioni dei bug e ricerca (tutto ciò che impegna il tempo del team).Tutto il lavoro del team deve derivare dal backlog prodotto: si tratta della porta di accesso al progetto.Se il backlog del prodotto include tutto il lavoro, il proprietario del prodotto, il team e il management avranno un quadro migliore del lavoro rimanente, riducendo le sorprese dell'ultimo minuto.

All'inizio di ogni progetto, è improbabile che ci sia un elenco di elementi backlog prodotto ben definiti pronti per la stima e l'assegnazione delle priorità.Al contrario, è probabile avere uno stack delle carte di note della storia e forse una o due specifiche funzionali.Il proprietario del prodotto deve ottenere questo messaggio in ordine in modo che il team possa iniziare a stimare il backlog.

Storie utente

Il primo passaggio consiste nel convertire tutte le idee e le note in storie utente, che descrivono la funzionalità desiderata dall'utente finale, ovvero ciò che l'utente richiede al software, ma non i dettagli dell'implementazione, ovvero come creare il software che soddisfa tali richieste.Il titolo di ogni storia utente deve seguire il formato "In qualità di <utente>, desidero implementare la <funzionalità> in modo che <motivo>".

Esempio di cartolina con storia

Come il backlog del prodotto stesso, ogni storia utente si evolverà nel tempo.Nel corso del progetto, il team assegnerà priorità e valuterà queste storie, vi aggiungerà informazioni dettagliate, le suddividerà in storie più piccole o le eliminerà completamente.Quelle che vengono introdotte negli sprint vengono implementate e fornite ai clienti.

Per ulteriori informazioni sulle storie utente, fare riferimento a Creare o aggiungere al backlog prodotto e a Storyboard un elemento di backlog di utilizzare PowerPoint.

Dopo aver convertito tutte le idee e le note in storie utente, è il momento di eseguire la stima e l'assegnazione delle priorità.

Stima

Per definizione, la stima non è precisa.Tuttavia, è possibile che l'utente raggiunga livelli migliori nella creazione di stime relativamente accurate con il tempo e la pratica e la partecipazione dell'intero team. Il primo passaggio consiste nel raggruppare il team in modo da fornire stime sugli elementi di backlog prodotto.Per eseguire la stima, il team assegna a ciascuna storia una stima di dimensione relativa con un'unità di misura astratta, denominata punto della storia.

Le stime sono indispensabili per due motivi:

Consentono di rispondere alla domanda "Quando avremo finito?"
Consentono al proprietario del prodotto di determinare la priorità di ogni elemento.

Le stime forniscono al proprietario del prodotto e al team una conoscenza del costo di una determinata storia, che, a sua volta, consente al proprietario del prodotto di classificare in ordine di priorità le storie.Più grande è la stima dell'elemento, più costosa sarà l'implementazione in termini di tempo e risorse.Pertanto, un elemento che il proprietario del prodotto potrebbe considerare molto utile, potrebbe diventare meno prioritario se ha un costo elevato.

Il team può utilizzare le tecniche di planning poker, big wall o altre tecniche per valutare il lavoro in termini di punti della storia.Per ulteriori informazioni sulle tecniche di stima e una lezione rapida in punti della storia, vedere Stimare e Pulire e stimare il backlog.

Dopo che il team ha valutato tutte le storie, è il momento di assegnare le priorità.

Priorità

Tutti i backlog prodotto sono classificati in ordine di priorità in termini di valore aziendale e rischio.Il proprietario del prodotto confronta ogni elemento nel backlog rispetto agli altri per determinarne la priorità.A tale scopo, il proprietario del prodotto considera la dimensione di ciascun elemento, il relativo valore per l'azienda e tutti i rischi connessi.Gli elementi sono quindi elencati in ordine di priorità decrescente.Gli elementi con priorità alta vengono visualizzati in corrispondenza o nella parte superiore del backlog prodotto e gli elementi con priorità più bassa vengono visualizzati in corrispondenza o nella parte inferiore.I team scelgono il lavoro per lo sprint imminente tra gli elementi con priorità più elevata, in modo che gli elementi più importanti vengono completati prima.

Non tutti gli elementi nel backlog hanno la stessa dimensione.Alcune possono essere completate in uno sprint, mentre altre sono talmente estese che il team non sa esattamente cosa comportano e quando tempo sarà necessario per l'implementazione.Ciò è OK.Mano a mano che gli elementi si avvicinano alla parte superiore del backlog, il team li renderà più piccoli e più dettagliati in modo che tutti comprendano meglio il lavoro che indirizzeranno negli sprint successivi.

Così come con la stima, l'assegnazione di priorità del backlog prodotto iniziale può essere impegnativa.Come è possibile bilanciare in modo efficace le richieste in competizione delle parti interessate, tenendo allo stesso tempo in considerazione il prodotto finale, i rischi e i costi?Fortunatamente, esistono diverse tecniche che semplifica l'attività più semplice, inclusi i giochi di innovazione e il peso relativo.Per ulteriori informazioni su queste e altre tecniche vedere Pianificazione dello sprint e Pulire e stimare il backlog.

A prescindere dalla tecnica di classificazione di priorità utilizzata, è necessario ordinare il lavoro in modo da garantire che il team compili le funzionalità di maggior rilievo per l'azienda, le parti interessate e i clienti.Se non si classifica il lavoro in ordine di priorità, si aumenta il rischio di fornire storie utente con priorità inferiore anziché con priorità più alta, nonché storie utente incomplete quando vengono modificate risorse e pianificazioni.

(Per ulteriori informazioni sulla natura degli elementi di backlog, vedere Creare o aggiungere al backlog prodotto e Pianificazione Agile e iterazioni).

Manutenzione backlog attiva

Quanto descritto finora è incentrato su come creare un backlog del prodotto con stime e priorità.A differenza di un documento di requisiti, i backlog del prodotto non vengono creati all'inizio del progetto per essere poi abbandonati su uno scaffale.Al contrario, il backlog del prodotto si evolve, espandendosi e contraendosi con le realtà del progetto.Alcuni elementi di backlog del prodotto diventeranno irrilevanti e dovranno essere rimossi.Altre emergeranno in superficie e dovranno essere suddivise in storie più piccole.Le nuove storie utente verranno aggiunte, stimate e classificate in ordine di priorità man mano che emergono requisiti aggiuntivi.

Il team e le parti interessate sono coinvolti nella creazione e nella gestione del backlog del prodotto, ma il proprietario del prodotto ha la responsabilità finale.Il proprietario del prodotto deve assicurarsi che il backlog sia pulito, classificato in ordine di priorità e aggiornato in modo che sia i clienti che il team abbiano un'immagine chiara del piano di lavoro per la release del progetto.Anche quando il progetto è in completa oscillazione, i proprietari del prodotto hanno ancora molto lavoro da fare per mantenere il backlog prodotto in piedi:

Aggiunta e assegnazione della priorità alle nuove storie
Richiede al team di stimare nuove storie e di stimare nuovamente quelle precedenti poiché adesso le si conoscono meglio
Rivedendo le storie utente imminenti con il team per la suddivisione di elementi in base alle esigenze
Riunione con i clienti e le parti interessate per rivedere e aggiungere i requisiti

Chiunque può aggiungere gli elementi al backlog del prodotto in qualsiasi momento, ma solo il proprietario del prodotto può classificarli in ordine di priorità.Il proprietario del prodotto è l'unica persona che può assegnare una priorità a una storia.Tutti gli altri membri del team e le parti interessate, devono lasciare vuota la priorità quando aggiungono una storia, anche se stanno utilizzando uno strumento elettronico che richiede tali informazioni.

Quando viene aggiunta una storia, il proprietario del prodotto ne esegue una valutazione preliminare in base alle conoscenze personali.Discuterà quindi la storia con il suo creatore per comprenderla meglio e in modo da poter, a sua volta, rispondere alle domande poste dal team.In un momento predeterminato durante ogni sprint, il proprietario del prodotto incontra il team per discutere le nuove storie e stimarle insieme in modo da poter assegnare priorità più accuratamente in base alle altre storie nel backlog.Questo processo è noto come pulitura del backlog.

Pulitura

La pulitura del backlog prodotto, come indicato in precedenza, deve verificarsi regolarmente.

In scrum il team deve dedicare il 5-15% del tempo di ogni sprint in attività di pulitura.Il team deve comprendere ciò che viene dopo e ciò che si sta modificando in modo da poter dividere tutte le storie grandi che stanno crescendo di priorità, valutare le storie che sono state create e predisporre una progettazione e una pianificazione iniziali per le storie imminenti.Per assicurarsi che ciò accada, il proprietario del prodotto e il team devono, durante ogni riunione di pianificazione dello sprint, dedicare del tempo alla pulitura del backlog.Per ulteriori informazioni sulla pianificazione dello sprint, vedere Pianificazione dello sprint e Pianificare un'iterazione.

Nello sprint di due settimane, vorrei tenere questa riunione durante la seconda settimana.Il proprietario del prodotto ha così il tempo sufficiente per parlare approfonditamente con i clienti e le parti interessate, capire i cambiamenti nell'azienda e chiarire le storie utente e le storie nuove o che aumentano di priorità.È inoltre un momento logico durante lo sprint per iniziare a fare previsioni sui prossimi sprint.È possibile decidere quando tenere la riunione.È importante concedere il tempo sufficiente durante lo sprint per il completamento delle attività di pulitura.

Durante una tipica riunione di pulitura, il proprietario del prodotto presenta le novità, i cambiamenti e il piano per i prossimi sprint.Oltre a stimare le nuove storie e suddividere quelle che devono essere completate a breve, il team dedica del tempo nel corso di questa riunione per rivedere l'architettura corrente del sistema e pianificare o progettare le funzionalità successive.Durante questo processo, la stime della storia sono spesso cambiate e le nuove storie tendono a essere visualizzate poiché le storie più grandi sono suddivise in storie più piccole.

Questo processo sembra semplice, ma può rivelarsi difficile.Per semplificare il processo, il proprietario del prodotto deve essere preparato a rispondere a delle domande.Può verificarsi un conflitto se, ad esempio, il proprietario del prodotto sta pianificando l'esecuzione di una storia nello sprint successivo ma non può fornire la chiarezza necessaria per il team per fornire una buona stima.Se ciò accade durante le riunioni di pianificazione dello sprint, lo ScrumMaster dovrà dare istruzioni al proprietario del prodotto circa le informazioni di clienti e parti interessate che dovrà presentare al team.

Alla fine di ogni riunione di pulitura, il proprietario del prodotto deve pubblicare le modifiche alle parti interessate e ai clienti in modo da tutti possano vedere le novità e il piano di rilascio aggiornato.

Un buon backlog prodotto assicura che il software compilato dispone delle funzionalità più importanti come identificato nelle conversazioni con i clienti e le parti interessate e definito nelle storie utente.Per creare e gestire un buon backlog del prodotto, è necessario rimanere attivamente impegnati sia con il gruppo parti interessate/cliente sia con il team a intervalli regolari, ovvero a ogni sprint.

La compilazione di un buon backlog non garantisce un buon sistema, ma la mancanza di un buon backlog accerterà quasi alla fine di avere un sistema che non esegue le attività richieste dai clienti.In altre parole, non mantenere aggiornato il backlog causa quasi sempre un errore del progetto.

Quello del proprietario del prodotto è un lavoro a tempo pieno e la gestione del backlog è sua responsabilità.Prendere seriamente il ruolo.Mantenere il backlog del prodotto in buono stato. I clienti vi ringrazieranno.