mvp orizzontale  psm1 small  cdap  sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

  • Categoria: ALM
  • Scritto da Felice Pescatore
  • Visite: 1807

Scrum and TFS cookbook - pt.2, Scrum + TFS, let’s start

Dopo l'introduzione realizzata con il primo post della serie, siamo pronti a tuffarci nel lato operativo, creando un nuovo progetto e gestendo ingrediente fondamentale del nostro libro delle ricette: il Product Backlog. La sua governance spetta al Product Owner che sottopone costantemente i relativi Work Item al processo definito Product Backlog Grooming: scrittura, stima, rifinimento e priorizzazione.

product backlog grooming

Product Backlog Grooming

Come ben sanno coloro che usano Scrum, tale framework non contempla direttamente il Product Backlog Grooming, occupandosi esclusivamente della realizzazione dei relativi Work Item. Qui entriamo, in punta di piedi, nel campo dell’Agile Scaling (@Scale) che si occupa di estendere i valori, i principi e le pratiche Agili oltre il “solo” contesto dello sviluppo, abbracciando i vari aspetti aziendali. Chi segue i post che periodicamente pubblichiamo avrà sicuramente letto di DAD e SAFe, ma, volendo restare su Scrum, il Grooming può essere effettuato sfruttando CIF (Continuous Improvement Framework), creato da Scrum.org sotto la supervisione dallo stesso Ken Schwaber e pensato proprio per rafforzare la competitività dell’azienda al fine di massimizzare il proprio ROI (return on investment).

cif framework

CIF Framework

Senza voler approfondire CIF e i relativi processi caratterizzanti, product development e continuous improvement, è importante evidenziare come il Product Backlog sia “condizionato”, praticamente, da tutte le funzioni aziendali: Product Management, Program Management e Development Management.

Ma TFS 2013 come ci aiuta in tutto ciò? Ebbene, diamo un’occhiata alla segmentazione proposta da Microsoft per l’Agile Portfolio, relativamente allo Scrum Process Template:

tfs scrum workitem

TFS 213, Scrum Process Template Work Item

TFS, di base, considera le attività di dev affidate a un solo Team (per vedere come avere più Team al lavoro sullo stesso Backlog, potete leggere l’ottimo articolo Gestire Team Multipli con uno stesso backlog in un Team Project di Gian Maria Ricci), identificando due diversi Backlog: il Program Backlog (feature based) e il Product Backlog (Work Item based). Nella sola versione on-premise è possibile anche definire il Portfolio Backlog(Initiatives based), utile per descrivere Epic che tipicamente sono utilizzate a livello Portfolio (Management aziendale) per le decisioni strategiche.

I tre diversi Backlog sono di proprietà/responsabilità di altrettante specifiche figure:

  • Portfolio Backlog, Portfolio Management;
  • Program Backlog, Product Management;
  • Product Backlog, Product Owner (che può essere coadiuvato da un Product Manager che cura gli aspetti di “esterni” del progetto, come quelli di business).

L'aspetto interessante è che tale suddivisione consente di avere due "viste" di quanto si sta realizzando: una orientata al business (Program Backlog) di alto livello da condividere con il cliente/stakeholder e una orientata alle attività di sviluppo (Product Backlog), orientata al Team di Dev.

Un attimo: dov’è finito lo Sprint Backlog? Tale Backlog viene implicitamente definito assegnando (sicuri?) un Work Item ad una specifica iterazione, sotto la supervisione, chiaramente, dello Scrum Master. L’assegnazione e la definizione dei relativi Task è, in perfetto stile Scrum, responsabilità del Team.

Le Feature sono tipicamente espresse in modo generico (“il sistema deve disporre dell’autenticazione a 2-fasi”), i Work Item sono prevalentemente costituiti dalle User Story (“Essendo un Utente voglio utilizzare il cellulare per ricevere il codice di autenticazione”) pesate in Story Point o Ideal Day, mentre i Task sono un’unità esplicita di lavoro (“realizzare la funzionalità di invio dell’SMS con codice di verifica”) espressa in ore e auto-assegnata da un singolo membro del Team.

Discorso a parte per le Epic che, come lo stesso Portfolio Backlog, non verranno trattate essendo afferenti ad un dominio di discussione diverso.

Andiamo ora a vedere come creare un nuovo progetto in VisualStudioOnline (se usate un’istallazione proprietaria di TFS la creazione del progetto avviene da Visual Studio), e creare un nuovo Product Backlog.

 

Creazione di un nuovo progetto (Recent pojects & teams -> new)

tfs example 1

Create new project

Cliccate su “new” e inserite le informazioni richieste, facendo attenzione a selezionare il corretto Process Template. A questo punto, VisualStudioOnline crea per noi una serie di elementi specifici per il nuovo progetto:

    • Un specifica Home Page;
    • Uno specifico Team;
    • Una serie di Iterazioni già attive relative alla prima release del nuovo sistema;
    • e … molto altro di cui parleremo in seguito.

tfs example 2

New Home Page

tfs example 3

New Team

tfs example 4

Iterations

Impostare il timing relativo alla Release e agli Sprint

Anche qui bisogna dire che, sebbene Scrum non preveda esplicitamente l’artefatto “Release”, è ormai pratica consolidata raggruppare una serie di Sprint sotto tale cappello. Questo per consentire una migliore gestione delle attività, soprattutto in ottica dei rilasci in produzione e della creazione di PSI (Potentially Shippable Increments) da mostrare agli stakeholder. Attenzione: TFS non setta automaticamente i tempi della Release in conformità con quelli settati per gli Sprint compresi in essa. Quindi dovete impostarli entrambi manualmente (prima o poi lo farà J)! Nell’inserimento, la soluzione Microsoft tiene comunque conto dell’intervallo scelto per lo Sprint precedente (es: 2 settimane) e vi suggerisce le date per i successivi. 

tfs example 5 tfs example 6

Sprint and Release timing 

A questo punto avremo un Backlogs Tree simile al seguente: 

tfs example 7

Backlogs Tree

Aggiungere le Feature e le User Story. Adottiamo un approccio top-down lineare

Aggiungiamo una feature (Program Backlog)

tfs example 8

Aggiunta Feature

Aggiungiamo le User Story (Product Backlog) avendo cura di settare la corretta relazione Padre-Figlio con la Feature inserita precedentemente

tfs example 9

Aggiunta User Story

Alla fine si otterrà un risultato simile al seguente:

tfs example 10

Product Backlog Work Item

 

Ora facciamo un attimo il punto della situazione: abbiamo creato il progetto, settato il timing, popolato il Program Backlog e il Product Backlog, cosa ci resta? La domanda è retorica perché la verità è che siamo solo all’inizio!

Nonostante il passo successivo possa sembrare ovvio, ovvero la creazione del primo Sprint/Iteration Backlog con la scelta delle User Story, settando il campo “Iteration” per ogni singola User Story, e la definizione dei Task relativi, manca un tassello fondamentale e irrinunciabile per fare ciò: il Team!

tfs example 11

User Story Iteration Setting

Se è vero che il Product Backlog è definito/gestito dal Product Owner (il Portfolio Backlog viene creato e manutenuto dai livelli aziendali più alti), come ripetuto più volte fino alla noia, la definizione dello Sprint/Iteration Backlog è appannaggio del Team… quindi, non barate! E non cadete nella trappola del pattern “command-and-control”, dove il “manager” definisce e a assegna i compiti.

Come popolare lo Sprint/Iteration Backlog, scegliendo opportunamente le User Story e creare i Task relativi è l’argomento del prossimo post, insieme alla definizione del Team stesso all’interno di TFS e delle relative viste.