Creare e gestire il backlog di prodotto

Articolo
06/10/2015

Di Mitch Lacey. Titolare di Mitch Lacey & Associates, Inc, una società di consulenza specializzata nell'adozione e nell'ottimizzazione di framework di sviluppo di tipo Agile e Scrum.

Gennaio 2012

In questo articolo Mitch Lacey illustra l'importanza di un Backlog di 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 (TFS)

Contenuto dell'articolo:

Introduzione
Backlog di Prodotto
- Storie utente
- Stima
- Classificazione in ordine di priorità
Backlog di Prodotto: sempre in evoluzione
- Pulizia

Un Backlog di Prodotto è un elenco classificato in ordine di priorità di tutte le funzionalità necessarie per completare un progetto. In TFS il Backlog di Prodotto viene gestito con gli elementi di lavoro. La scelta dei tipi di elemento di lavoro sarà diversa, in base al modello di processo usato per creare il progetto team. Per altre informazioni sui modelli di processo e sui tipi di elemento di lavoro supportati, vedere Utilizzare elementi del progetto team, scegliere un modello di processo.

Un buon Backlog di Prodotto costituisce la base di tutti i team di sviluppo agile ben funzionanti e presenta le caratteristiche seguenti:

È classificato in ordine di priorità per garantire che il team compili le funzionalità più importanti per prime.
È stimato dal team per fornire al proprietario informazioni chiare e per consentirgli di rispondere a domande relative al completamento di determinate storie.
Include tutte le operazioni necessarie per completare il progetto.
È un documento in evoluzione, che cambia continuamente per riflettere la realtà del progetto.

Un buon Backlog di Prodotto non garantisce automaticamente un buon software. Tuttavia, spesso la mancanza di un buon Backlog di Prodotto è spesso causa di un software incompleto che non soddisfa i requisiti dei clienti e delle parti interessate.

La gestione del Backlog di Prodotto è un lavoro a tempo pieno. Alcune semplici tecniche consentono di trasformare un processo pesante e impegnativo in termini di tempo in un processo interattivo e iterativo che coinvolge in modo efficace membri del team, clienti e parti interessate. È quindi essenziale apprendere alcune tecniche collaudate che permettono di creare, classificare in ordine di priorità e gestire il Backlog di Prodotto.

Backlog di Prodotto

Un Backlog di Prodotto è un elenco classificato in ordine di priorità di tutte le funzionalità necessarie per completare un progetto, in continua evoluzione. In genere i Backlog di Prodotto includono le storie utente relative ai requisiti (requisiti), bug, attività di ricerca e miglioramenti di progettazione. Queste voci sono stimate in unità astratte che spesso vengono denominate punti storia.

Il Backlog di Prodotto include tutte le attività necessarie per il progetto ed evolve nel tempo. In quanto tale, non contiene solo le nuove funzionalità per un prodotto, ma anche correzioni di bug e ricerche, ovvero qualsiasi operazione a cui il team dedica tempo. Tutte le attività svolte dal team devono essere indicate nel Backlog di Prodotto, che funge da porta principale per il progetto. Se nel Backlog di Prodotto sono incluse tutte le attività, il proprietario del prodotto, il team e il management possono avere un quadro generale delle attività rimanenti e si riduce al minimo l'eventualità di sorprese dell'ultimo minuto.

All'inizio di qualsiasi progetto, è improbabile che sia disponibile un elenco di elementi del Backlog di Prodotto puliti, ben definiti, pronti per la stima e già classificati in ordine di priorità. È più probabile che si abbia una pila di schede di appunti relativi alle storie e un paio di specifiche funzionali. È compito del proprietario del prodotto organizzare e ordinare questi appunti in modo che il team possa iniziare a stimare il Backlog.

Storie utente

Il primo passaggio prevede la conversione di tutte le idee e gli appunti in storie utente, in cui vengono indicate le funzionalità desiderate dagli utenti finali (che cosa deve fare il software) senza i dettagli relativi all'implementazione (come creare il software in grado di soddisfare tali requisiti). Il titolo di ogni storia utente deve seguire il formato "In qualità di <utente>, desidero <funzionalità> in modo che <motivo>".

Esempio di cartolina con storia

Come il Backlog di Prodotto stesso, anche le storie utente evolveranno nel tempo. Nel corso del progetto, il team classificherà in ordine di priorità e stimerà le storie, vi aggiungerà informazioni dettagliate e le suddividerà in storie più piccole o le eliminerà in blocco. Quelle inserite negli sprint vengono implementate e distribuite ai clienti.

Per altre informazioni sulle storie utente, vedere Creare il backlog e Creare uno storyboard di idee tramite PowerPoint.

Dopo avere convertito le idee e gli appunti in storie utente, si passa alla fase di stima e di classificazione in ordine di priorità.

Stima

Per definizione, una stima è imprecisa, ma è possibile migliorare e arrivare a creare stime relativamente accurate con il tempo, la pratica e la partecipazione dell'intero team. Il primo passaggio consiste nel riunire il team per fornire le stime sugli elementi del Backlog di Prodotto. Il team stima ogni storia in base una dimensione relativa calcolata con un'unità di misura astratta, denominata punti storia.

Le stime sono essenziali per due motivi:

Consentono di determinare il momento in cui verranno svolte le attività.
Consentono al proprietario del prodotto di determinare la priorità di ogni elemento.

Le stime consentono al proprietario del prodotto e al team di valutare a grandi linee i costi relativi a una storia specifica, permettendo quindi al proprietario del prodotto di classificare le varie storie in ordine di priorità. Più elevata sarà la stima dell'elemento, maggiore sarà il costo per l'implementazione in termini di tempo e risorse. Di conseguenza, un elemento che si trovava nelle prime posizioni della lista dei desideri del proprietario del prodotto potrebbe subire un abbassamento di priorità se i costi sono molto elevati.

Per stimare le attività in termini di punti storia, i team possono usare Planning Poker, The Big Wall o altre tecniche disponibili. Per altre informazioni sulle tecniche di stima e sui punti storia, vedere Stima e Pulire e stimare il backlog.

Dopo avere stimato tutte le storie, il team può passare alla classificazione in ordine di priorità.

Classificazione in ordine di priorità

Le priorità vengono assegnate in base al valore aziendale e al rischio. Il proprietario del prodotto confronta ogni elemento del backlog con gli altri per determinarne la priorità relativa. A questo scopo, il proprietario del prodotto valuta le dimensioni di ogni elemento, il valore per l'azienda e i rischi associati. Gli elementi sono quindi elencati in ordine decrescente in base alla priorità. Gli elementi ad alta priorità sono posizionati in cima al Backlog di Prodotto, mentre quelli a bassa priorità si trovano verso la fine. Per lo sprint successivo, i team scelgono di lavorare sugli elementi ad altra priorità, così da completarli per primi.

Non tutti gli elementi del Backlog hanno le stesse dimensioni, quindi alcuni potranno essere completati in uno sprint, mentre altri saranno così grandi da non poter stabilire il tempo necessario per implementarli. È normale. Man mano che gli elementi vengono spostati nella parte alta del Backlog, verranno suddivisi in attività più piccole in modo da agevolare la valutazione del lavoro da svolgere per gli sprint successivi.

Come la stima, anche la classificazione in ordine di priorità iniziale del Backlog di Prodotto può risultare scoraggiante. È infatti difficile trovare un compromesso tra le richieste simultanee delle parti interessate, valutando al contempo prodotto finale, rischi e costi. Per fortuna, esistono diverse tecniche che consentono di semplificare questa attività, ad esempio le soluzioni di Innovation Games e la ponderazione relativa. Per informazioni su queste e altre tecniche, vedere Priorità e Pulire e stimare il backlog.

Indipendentemente dalla tecnica di classificazione in ordine di priorità scelta, è necessario assegnare un ordine alle attività per garantire che il team compili le funzionalità che conferiscono il maggior valore all'azienda, alle parti interessate e ai clienti. Se le attività non vengono classificate in base alla priorità, si rischia di consegnare storie utente con bassa priorità anziché quelle ad alta priorità e storie utente incomplete qualora si verifichino cambiamenti relativi a risorse e pianificazioni.

Per altre informazioni relative alla natura degli elementi del Backlog, vedere Creare il backlog e Utilizzare i backlog di portfolio.

Backlog di Prodotto: sempre in evoluzione

Ciò che ho illustrato finora è la creazione da zero di un Backlog di Prodotto stimato e classificato in ordine di priorità. Diversamente da un documento di requisiti, un Backlog di Prodotto non viene creato all'inizio di un progetto e quindi lasciato in un cassetto. Al contrario, il Backlog di Prodotto si evolve, espandendosi e contraendosi in base alla realtà del progetto. Alcuni elementi del Backlog diventeranno irrilevanti e dovranno essere rimossi. Ne verranno evidenziati altri che dovranno essere suddivisi in storie più piccole. Man mano che emergono altri requisiti, le nuove storie utente verranno aggiunte, stimate e classificate in ordine di priorità.

Il team e le parti interessate sono coinvolti nella creazione e nella gestione del Backlog di Prodotto, ma il proprietario del prodotto ne è il responsabile finale. Il proprietario del prodotto deve garantire che il Backlog sia pulito, classificato in ordine di priorità e aggiornato, in modo che sia i clienti che il team abbiano un quadro preciso del piano di lavoro per il rilascio del progetto. Anche quando il progetto è in piena attività, il proprietario del prodotto deve gestire numerose attività per assicurarsi che il Backlog di Prodotto sia sempre aggiornato:

Aggiungere e classificare in ordine di priorità le nuove storie
Chiedere al team di stimare le nuove storie e stimare di nuovo quelle precedenti, una volta che sono diventate più chiare
Riesaminare le storie utente successive con il team per suddividere gli elementi in base alle esigenze
Organizzare riunioni con i clienti e le parti interessate per riesaminare e aggiungere requisiti

Chiunque può aggiungere elementi al Backlog di Prodotto in qualsiasi momento, ma solo il proprietario del prodotto può classificarli in ordine di priorità. Il proprietario del prodotto è anche l'unico autorizzato ad assegnare una priorità a una storia. Quando viene aggiunta una storia, i membri del team e le parti interessate devono lasciare vuota la priorità anche se usano uno strumento che richiede l'immissione di quell'informazione.

Quando viene aggiunta una storia, il proprietario del prodotto effettua una valutazione preliminare della priorità in base alle informazioni disponibili su di essa. Esamina la storia con chi l'ha creata per ottenere informazioni e poter, a sua volta, rispondere alle domande che gli verranno poste dal team. A un momento prestabilito durante ogni sprint, il proprietario del prodotto esaminerà le nuove storie con il team e verrà fornita una stima, in modo da poterla classificare in ordine di priorità con precisione rispetto alle altre storie nel Backlog. Questo processo è noto come pulizia del Backlog.

Pulizia

La pulizia del Backlog, come indicato in precedenza, deve essere eseguita regolarmente.

In Scrum il team dovrebbe dedicare tra il 5% e il 15% del tempo di ogni sprint alle attività di pulizia. Il team deve avere una visione chiara delle attività successive e dei cambiamenti in corso, in modo da poter suddividere le storie di grandi dimensioni che salgono nella scala delle priorità, stimare le eventuali storie create ed eseguire attività di progettazione e pianificazione emergenti per le storie successive. A questo scopo, in occasione di ogni riunione di pianificazione dello sprint il proprietario del progetto e il team devono prevedere di accantonare il tempo necessario per la pulizia del Backlog. Per altre informazioni sulla pianificazione dello sprint, vedere Pianificazione dello sprint e Lavorare in sprint.

In uno sprint di due settimane, in genere organizzo questa riunione durante la seconda settimana. In questo modo, si permette al proprietario del progetto di instaurare conversazioni significative con i clienti e le parti interessate, ottenere informazioni relative alle modifiche dell'attività, chiarire aspetti relativi alle storie utente e definire le storie nuove o con priorità in aumento. Si tratta inoltre di un momento ideale per iniziare a prevedere gli sprint successivi. Si può tenere questa riunione quando si desidera. Ciò che è importante è prevedere il tempo sufficiente per completare le attività di pulizia nel corso dello sprint.

Durante una tipica riunione di pulizia, il proprietario del prodotto presenta le novità, le modifiche introdotte e il piano per gli sprint successivi. Oltre a stimare le nuove storie e suddividere quelle che devono essere completate a breve, durante questa riunione il team esamina l'architettura corrente del sistema e pianifica o progetta le funzionalità future. Nel corso del processo, le stime delle storie spesso cambiano, emergono nuove storie e le storie più grandi vengono suddivise in parti più piccole.

È più complesso di quanto può sembrare in apparenza. Per un risultato ottimale, il proprietario del prodotto deve essere preparato a rispondere alle domande. Potrebbero insorgere conflitti, se ad esempio il proprietario del prodotto ha pianificato l'esecuzione di una storia nello sprint successivo ma non è in grado di fornire le informazioni necessarie al team per effettuare una buona stima. Se questo avviene durante le riunioni di pianificazione dello sprint, lo ScrumMaster dovrà indicare al proprietario del progetto quali sono le informazioni che deve raccogliere dai clienti e dalle parti interessate.

Alla fine di ogni riunione di pulizia, il proprietario del prodotto deve pubblicare le modifiche per le parti interessate e i clienti, in modo che tutti possano vedere quali sono le novità, le attività successive e il piano di rilascio aggiornato.

Un buon Backlog di Prodotto consente di garantire che il software compilato contenga le funzionalità più importanti, come emerso dalle conversazioni con clienti e parti interessate e come definito nelle storie utente. Per creare e gestire un buon Backlog di Prodotto, è necessario rimanere attivamente coinvolti con i clienti e le parti interessate da un lato e con il team dall'altro, regolarmente e per ogni sprint.

La creazione di un buon Backlog non garantisce di per sé che lo sia anche il software, ma è molto probabile che se il Backlog non è gestito in modo appropriato, il software prodotto non faccia quanto ha richiesto il cliente. In altre parole, se il Backlog non viene aggiornato costantemente, quasi sempre il progetto avrà esito negativo.

Il ruolo di proprietario del prodotto implica un lavoro a tempo pieno e il Backlog rappresenta una delle responsabilità principali, di conseguenza, deve essere affrontato con la massima serietà. Se il Backlog viene costantemente aggiornato, il clienti riceveranno il prodotto che hanno chiesto.