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

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

Scrum and TFS cookbook - pt.5, Review and Retrospective

Per completare il nostro Sprint ci attendono due appuntamenti (cerimonie) fondamentali: lo Sprint Review e lo Sprint Retrospective.

sprint review meeting

Sprint Review and Sprint Retrospective meeting

Lo Sprint Review è dedicato alla presentazione del lavoro svolto, o meglio, dell’attuale stato del prodotto, comprendente tutto quanto sviluppato finora, integrato e testato. Ad esso partecipano praticamente tutti: gli stakeholder (interni ed esterni), lo Scrum Team al completo, uditori, ecc… Scrum prevede di effettuare lo Sprint Review alla fine di ogni sprint ma, in realtà, è sempre più frequente l’utilizzo del concetto di Minimum Viable Product (mvp), ovvero l’insieme minimo di funzionalità che rappresentano un incremento significativo dal punto di vista del cliente. Se applicato (cosa di frequente soprattutto quando lo sviluppo del prodotto coinvolge più Team) la cosa si traduce nell’avere uno Sprint Review interno minimale e uno Sprint Review più consistente ogni N-Sprint.

Durante lo Sprint Review vengono evidenziati eventuali problemi di sviluppo che si sono verificati e come evitarli in futuro. Tra essi, uno dei più frequenti, è il comportamento da adottare rispetto a User Story completate solo parzialmente.

Personalmente, suggerisco al Team di applicare due semplici regole:

    1. Una User Story non completata (o meglio, che non ha raggiunto lo stato di “Done”) non contribuisce al calcolo della Velocity;
    2. L’intera User Story, compresi i Task completati e non, vengono traslati nel nuovo Sprint.

Un approccio alternativo al punto 2 è quello di “splittare” la User Story in UserStoryA e UserStoryB, la prima comprende i Task completati e la seconda quelli non completati. In questo modo la UserStoryA contribuisce anche alla Velocity dello Sprint attuale, mentre il resto va nello Sprint successivo.  Questo approccio ha lo svantaggio di dover ri-estimare anche la complessità delle due nuove User Story e, in generale, non è del tutto compliance con l’essenza di Scrum.

Il primo supporto a questa fase da parte di TFS/VisualStudioOnline è chiaramente legato alla Continuous Integration (Pt.4, Sprint by Sprint) che consente di ottenere una soluzione completa e testata delle nuove funzionalità realizzate in modo automatizzato.  Lo strumento ALM di Microsoft ci viene incontro anche nell’attività di riallocare una User Story con tutti i relativi task in modo semplice e veloce: basta selezionare la User Story specifica e cambiare la sua “assegnazione”.

tfs example 22

User Story Iteration Assignment

Se si desidera spostare solo i task non competi, la procedura è un po’ più complessa: TFS/VisualStudioOnline, in modo automatizzato, permette lo “share” di una User Story tra più Sprint (Iterazioni), quindi non è necessario effettuare la ri-stima per due User Story differenti. Vediamo come fare: prima di tutto bisogna creare una query che selezioni i task “undone”.

tfs example 23

 Done / unDone Task query

Dopodiché selezionate il risultato ottenuto (sia la User Story che i Task), cliccate con il tasto destro sulla selezione e scegliete “Move to Iteration”.

tfs example 24

Move to Iteration

Una volta confermato il tutto avrete la User Story presente sia nell’iterazione corrente, con i relativi Task in Done state, e nell’iterazione successiva (o quella che avete indicato) con i Task non-in-Done-State.

tfs example 25

Shared User Story: Sprint Attuale

tfs example 25

Shared User Story split: Sprint Successivo

Essendo la User Story in “share”, risulterà ancora aperta alla fine dello Sprint corrente e, automaticamente, non correrà al calcolo della Velocity.

A valle delle operazioni di “aggiustamento”, lo Sprint Review si conclude con una serie di domande molto simili a quelle poste durate il Daily Scrum, di preparazione al prossimo Sprint Planning (Pt.3, go to the Sprint!):

  • What did you like the most ?
  • What did you not like?
  • What would you like to improve?

Una volta terminata lo Sprint Review, lo Scrum Team (e solo esso) si riunisce per 2-3 ore per effettuare la Scrum Retrospective. Questo meeting è caratterizzato da una serie di Activity che consento di ispezionare l’applicazione di Scrum stesso e il comportamento del Team come tale, al fine di migliorare l’aspetto metodologico del lavoro. Spesso, come Activity, si utilizzano dei Retrospective Game come lo Starfish che consentono di raccogliere in modo chiaro e coinvolgente i vari aspetti che caratterizzano il Team.

starfish retrospective

Starfish game

Da questo punto di vista, TFS/VisualStudioOnline non offre un grande supporto avendo, come detto, nella versione 2013 eliminato lo “Sprint Work Item”. L’opzione potrebbe essere quella di creare, a questo punto, un Work Item generico nella cui descrizione si inseriscono gli obiettivi (agenda) della retrospettiva e si allegano le foto dei vari artefatti realizzati.

tfs example 26

Retrospective Work Item

Si tratta di un Work Item utile per aver traccia di quanto discusso nella retrospettiva, legandolo in modo diretto allo Sprint.

Siamo giunti alla fine del nostro “cookbook”, un viaggio lungo 5 post in cui abbiamo visto alcune soluzioni pratiche che consentono a TFS/VisualStudioOnline di supportare in modo diretto l’utilizzo di Scrum all’interno della propria organizzazione.

Sperando che il tutto vi abbia incuriosito e possa servirvi come start-point per le vostre esigenze, chiudo ricordandovi che sia TFS/VisualStudioOnline che Scrum vanno sempre calati nello specifico contesto di esercizio e che solo un loro utilizzo serio e disciplinato porta ad vero valore per le proprie attività.