xebir logo mvp orizzontale psm1 small  cdac safe sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

La burocrazia dei requisiti diluita nella Pila

Il Product Backlogè molto spesso l’elemento centrale da cui si sviluppano le diverse attività di un team Agile, siano esse di envisioning, pianificazione o relative al lavoro giornaliero.

Si tratta, per quanti non ne avessero dimestichezza, di un elenco verticale delle attività da realizzare, ordinate secondo diversi criteri (il più utilizzato è genericamente per Valore) dall’alto verso il basso: una sorta di pila che contiene tutto quanto necessario realizzare per completare il prodotto.

Ma è davvero così semplice creare un Product Backlog, capire cosa inserirvi e gestirlo adeguatamente in modo che sia anche un “manufatto live” che sostituisca in tutto e per tutto la burocrazia dei requisiti? La risposta è chiaramente no, e le sperimentazioni sulle diverse forme che il Product Backlog può assumere sono continue e spesso fonti di nuove domande.

pbacklog extended

Si pensi ad esempio all’interpretazione del Product Backlog in chiave Disciplined Agile in cui lo stesso deve soddisfare la necessità di creare una “Soluzione Consumabile” e non “Software funzionate”: questo implica che in esso troveremo non solo le iniziative di sviluppo, ma anche tutte le attività aggiuntive (se continuiamo a considerare Core lo sviluppo) che sono necessarie per rendere “consumabile” quel prodotto da parte degli utenti finale. Un esempio per tutti: la creazione del manuale utente.

Inoltre, esiste sempre più la tendenza di non vincolarsi strettamente a forme canoniche per la descrizione delle attività, come ad esempio le User Story(funzionalità orientate all’utente), ma contemplare anche elementi che in qualche modo l’utente non può toccare in modo diretto se non nel complesso del prodotto in quanto sua componente fondamentale. Ad esempio: se si crea un nuovo prodotto da zero, i servizi trasversali come logging security come li esprimo nel backlog? Che priorità hanno? Li lego ad una storia utente, oppure li esplicito per abbracciare i principi di chiarezza e trasparenza insiti nel backlog stesso? Io, generalmente opto per quest’ultima soluzione, lavorando con il PO per trovare la forma corretta di comunicazione relativa con il cliente.

Se andiamo in ottica DevOps (Lean), il Product Backlog non dovrebbe essere più considerato solo espressione del team di sviluppo, ma si dovrebbe guardare il quadro complessivo e includere, quantomeno, le attività annesse al deploy delle funzionalità realizzate. Anche qui un esempio: il product backlog dovrebbe contenere l’attività di creazione degli script per il provisioning delle macchine necessarie all’erogazione dei servizi, fondamentali per supportare fin da subito le attività di testing così come quelle di consolidamento delle pipeline di rilascio.

Anche sulla questione prioritizzazione c’è molto da lavorare: l’ordinamento per Valore utente, per quanto il concetto di Valore non sia di per sé univoco, può diventare semplicistico, non tenendo in conto, ad esempio, la necessità di esplorare tecnicamente alcune caratteristiche che possono rappresentare un forte rischio per il successo dell’iniziativa stessa. In generale è sempre utile avere almeno un ordinamento che si basa sul dualismo Valore-Rischio (value-risk driven) in modo da bilanciare due obiettivi: avere nuovi elementi di cui discutere con l’utente e diminuire il rischio intrinseco di quanto si sta realizzando, aumentandone la confidenza e spostandosi a destra lungo il Cono di Incertezza.

cone of uncertainty

Nella concezione qui evidenziata, il Product Backlog diventa quindi un contenitore live che, rispettando gli specifici criteri di ordinamento, consente di avere costantemente una fotografia di tutto quanto necessario per portare a termine l’iniziativa, evidenziando al contempo le specifiche ownership dei work center (DevOps/Lean) e le possibili criticità, in modo da intervenire prontamente per risolvere.

È sempre interessante sottolineare come dietro uno strumento apparentemente semplice, si celi una “cultura dell’utilizzo” che può essere coltivata solo in seno al team specifico e all’organizzazione di appartenenza, non dimenticando anche le caratteristiche proprie del prodotto che rappresenta.

Stay tuned J