Agile Life

ottobre 2014 - Post

Product Backlog? Yes, but it can be more than one!

Il Product Backlog è la proiezione, ordinata e pesata, di quello che è il nostro Prodotto, o almeno di quanto, allo stato attuale, si conosce di esso.

In linea generale abbiamo un’associazione diretta tra Product BacklogProdotto e Agile Team, ovvero: per 1 Prodotto esiste 1 Product Backlog ed 1 Agile Team che ne prende in carico le attività. Si tratta, chiaramente, di uno scenario minimale che si complica notevolmente già solo ponendosi una semplice domanda: “Che cos’è per noi un Prodotto?”.

Facciamo un esempio molto semplice, tratto dall’ottimo libro Essential Scrum di Kenneth S. Rubin: se consideriamo Microsoft Office, possiamo etichettare come Prodotto l’intera Suite o una delle sue applicazione specifiche, per esempio Word:

product backlog office

Cos'è per noi il "Prodotto"?

Ebbene, la scelta di dove posizionarsi raramente è ben delineata dipendendo da una serie di elementi che afferiscono principalmente al Program Level (leggasi SAFe), in accordo con gli obiettivi strategici.

Ora, tralasciando la governance di questo aspetto, proviamo a vedere alcune strategie utili per gestire il nostro Product Backlog in base alla nostra definizione di “Prodotto” e a quanti Team sono associati ad esso. Chiaramente andiamo a scoprire anche come sfruttare adeguatamente VisualStudioOnline/TFS per accompagnare tali strategie.

Prima di procedere, utilizzando una stima della complessità dei progetti in linea con le T-Shirt Size, vediamo i possibili casi principali (sicuramente non esaustivi):

Size

Product Type

Team

S

Bassa Complessità

Uno/Generalista

M

Media Complessità

N/Generalisti

L

Alta Complessità

N/Generalisti e Specialisti

Size Case

Size S. In questo scenario possiamo adottare l’approccio più classico, in cui si ha un unico Product Backlog a cui afferisce un unico Agile Team. Come di consueto, il Product Backlog conterrà i Work Item più rilevanti e più dettagliati al Top.

size s

Size S

Guardando a VSO/TFS non è necessario fare particolari settaggi, essendo possibile utilizzare il Product Backlog e l’associazione dell’Agile Team al Team Project esattamente come viene creato scegliendo lo Scrum Process Template.

vso scrum process template

Scrum Process Template Items Tree

L’unica accortezza è quella di considerare le Feature (o Work Item a “grana grossa” se preferite) parte del Portfolio Backlog e le User Story/Bug/ecc… come elementi del (Product) Backlog legati alle Feature.

Size M. Questo scenario può essere suddiviso in due sub-scenari specifici:

  • M1: il nostro Prodotto è unico ed è associato a più Agile Team che lavorano sulle relative Feature;
  • M2: il nostro Prodotto è in realtà composto da più Prodotti specifici e ognuno di essi è associato uno specifico Product Backlog affidato ad un Agile Team;

size m1

Size M1

size m2

Size M2

Per quanto riguarda le relative configurazioni di VisualStudioOnline/TFS, sia per Size M1 che Size M2, vi rimando direttamente agli ottimi post di Gian Maria Ricci (Gestire Team Multipli con uno stesso backlog in un Team Project eConfiguration di un Team Project per più team con backlog multipli) in cui viene spiegato passo-passo come sfruttare le “Aree” di VSO/TFS per raggiungere la configurazione desiderata.

vso area configuration

VSO Area Configuration

Size L. E’ lo scenario più difficile, in cui abbiamo una serie di sotto Prodotti, ognuno dei quali può essere affidato a più di un Agile Team, sia generalista che specialista.

size l

Size L

Anche per quest’ultimo scenario, valgono i post di Gian Maria, che opportunamente combinati portano al risultato desiderato.

Prima di chiudere un breve cenno sullo Scaling, relativamente a SAFe. Il framework di Leffingwell, non contempla nessun Product Backlog, dal punto di vista letterale, bensì, ragionando in termini di Value Stream e ART, individua due Backlog differenti, posizionati in due livelli distinti:

  1. Program Backlog (Program Level): contiene tutto quanto necessario a rendere concreto l’Agile Release Train, in termini di iniziative e prodotti;
  2. Team Backlog (Team Level): è una segmentazione del relativo Program Backlog che contiene le attività di sviluppo associate allo specifico Agile Team.

program team backlog

SAFe Program e Team Backlog

Quanto proposto da SAFe rientra nel caso Size L, poiché il Program Backlog è un’entità complessa che può sicuramente essere composta da più Prodotti.

 

[FELICEPESCATORE.IT]

Scrum and TFS cookbook - pt.6,compendio: the Five Scrum Values

Ok, avevamo chiuso il precedente post dicendo che era l’ultimo della serie… ebbene non è così! Le nostre “ricette” sono preparate dalle persone, e le persone hanno bisogno di raggiungere il giusto affiatamento per ottenere il risultato sperato, o quanto meno per avvicinarsi ad esso.

D'altronde lo stesso manifesto Agile pone al primo posto, tra i propri valori, quello esplicitamente dedicato alle persone: “Gli individui e le interazioni più che i processi e gli strumenti” e Scrum, ovviamente, lo abbraccia pienamente (altrimenti non sarebbe Agile!), raffinandolo in 5 valori “derivati”: openness, courage, respect, focus e commitment.

 scrum 5 values

The 5 Scrum Values

Vediamoli questi valori in dettaglio, evidenziandoli per ogni componente dello Scrum Team (Scrum Master [SM], Product Owner [PO] e Development Team [DT]):

  • Focus. Lo SM è concentrato sulla rimozione degli impedimenti e sull’applicazione di Scrum all’interno del Team e nel contesto aziendale. Il PO è concentrato sull’ottenimento del massimo Valore per il prodotto in essere, organizzando opportunamente il Product Backlog. Il DT è focalizzato sullo sviluppo della soluzione in funzione della Definition of Done;
  • Coraggio (Courage). Lo SM deve avere coraggio per “proteggere” e “guidare” il Team, così come il PO per fidarsi delle attività in essere e dialogare con gli stakeholder. Il DT deve impegnarsi nella realizzazione dei Work Item, superando i propri limiti in un’ottica inspect-and-adapt;
  • Apertura (Openness). L’intero Team deve essere aperto ai cambiamenti, sia che provengano dall’interno che dall’esterno (stakeholder). In aggiunta, il DT deve guardare a nuove soluzioni, soprattutto tecniche, per ottimizzare la qualità di quanto realizzato;
  • Impegno (Commitment). Il DT sottoscrive il proprio impegno in ogni Sprint Planning, quando vengono decisi i Work Item da realizzare nella prossima iterazione. Lo SM ha un impegno costante nel far penetrare culturalmente Scrum nello specifico contesto. Il PO si impegna con gli stakeholder per ottenere costantemente (ad ogni Sprint) un incremento della soluzione disponibile, in ottica sempre di accrescimento del Valore complessivo;
  • Respect (Rispetto). Questo è il valore più difficile da conquistare, perché il rispetto si estende oltre i ruoli, toccando il personale. Il DT e lo SM devono rispettare le decisioni del PO, l’unico ad avere la parola finale su cosa realizzare. Dualmente il PO deve rispettare l’autonomia del DT sul come fare le cose e come raggiungere la DoD, così come deve rispettare lo SM nella propria attività di guida metodologica. Lo SM, dal proprio canto, deve essere un “leader servente” e non il techincal leader o il team leader vecchio stile command-and-control. Infine ogni singolo membro dello Scrum Team deve rispettare i propri colleghi nell’ottica della Prima Direttiva delle Retrospettive (Norman Kerth): “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Una cosa fondamentale è che i Valori appartengono a tutto il Team ed è sua responsabilità farli maturare ed applicare al proprio interno. Non esiste, insomma, un Value Scrum Master, ma la responsabilità è egualmente distribuita su tutti, sia per l’applicazione individuale che per quella complessiva.

Adesso è proprio tutto… 

 

[FELICEPESCATORE.IT]

Posted: 29 ott 2014 15:59 da felice.pescatore | con no comments
Inserito sotto: ,