Scrum and TFS cookbook – pt.4, Sprint by Sprint

In Scrum, il cuore pulsante e operativo delle attività di sviluppo è lo Sprint.

dailyscrum

A Sprint Activity: Daily Scrum

Si tratta di un intervallo time-boxed, tipicamente di 1-4 settimane (mediamente 2settimane), all’interno del quale il Team concretizza lo Sprint Goal definito durante lo “Sprint Planning” e realizza le User Story, o, più in generale, i Work item inseriti nello Sprint Backlog.

Lo Sprint raccoglie in se alcune delle cerimonie fondamentali di Scrum:

  • Daily Scrum: si tratta di uno stand-up meeting mattutino di una decina di minuti al massimo in cui tutti i membri del Team, a turno, illustrando cosa hanno realizzato (What have I done yesterday?), cosa si apprestano a fare (What will I do today?) e le eventuali difficoltà incontrante (What keeps me from doing my work?);
  • Sprint Review: si effettua alla chiusura dello Sprint. Il Product Owner mostra quanto realizzato agli stakeholder, al fine di validare in ultima analisi il tutto e raccogliere i feedback;
  • Sprint Retrospective: si effettua alla chiusura dello Sprint ed è dedicata al Team. Ha il compito fondamentale di ragionare sui processi adottati e sul loro miglioramento.

Le ultime due cerimonie saranno oggetto del prossimo post di questa serie, mentre il Daily Scrum è implicitamente associato a quanto diremo nel prosieguo. Sempre in relazione allo Sprint, esiste un elemento che è fondamentale introdurre prima di proseguire: Definition of Done (DoD). Esattamente come per lo Sprint Goal, il Team (nella sua interezza) definisce cosa si intende per “DONE”, ovvero quando è possibile considerare un Work Item finito. Tale definizione evolve durante lo sviluppo del prodotto e può avere una prima formalizzazione associata ai primi Product Backlog Grooming o al primo Sprint. In pratica, si definisce una short list di attività da effettuare per ogni elemento del Backlog o per un suo insieme:

  • [MUST] Superamento dei Test di Accettazione (Acceptance Criteria);
  • [MUST] Definizione, esecuzione e superamento dei Test di Unità;
  • Test Code Coverage superiore ad una certa %;
  • Documentazione funzionale;
  • ….

Tipicamente, per i Team che si sono imbarcati in Scrum da poco, è possibile limitarsi alle prime due attività, anche se si tratta di un’assunzione debole. Quello che invece è fondamentale evidenziare è che tanto più lunga è la lista delle attività annesse alla DoD, tanto più lungo sarà il tempo necessario per completare una User Story, incidendo, probabilmente, anche sulla sua complessità relativa (Story Point). In sintesi:

la Velocity è inversamente proporzionale alla complessità della DoD

La cosa interessante, più volte ripetuta, è che Scrum dice cosa fare ma non dice come farlo, lasciando la libertà al Team di auto organizzarsi e di scegliere le pratiche che più si ritengono opportune. In quest’ottica, per lo sviluppo vero e proprio, spesso i Team prendono “in prestito” le pratiche contemplate da eXtreme Programming (XP), il TDD e altro, in base alle proprie esigenze e alla propria maturità.

TFS/VisualStudioOnline dispone di una serie di strumenti trasversali che consentono di svolgere le attività intrinseche ad uno Sprint. In primis la Sprint Board, di cui abbiamo già parlato nel post precedente, che consente di gestire agevolmente tutte le attività di organizzazione dei Work Item e dei Task.

tfs example 20

Sprint Board

Il monitoraggio avviene attraverso una serie di strumenti visuali: lo Sprint Burndown Chart, il Release Burndown Chart, il Cumulative Flow, l’Histogram of Velocity, ecc. Ma, probabilmente, l’elemento più importante è la Dashboard, visionabile accedendo da Web e che presenta una sintesi dello stato del progetto, con Cruscotti e Tiles personalizzabili in grado di evidenziare aspetti specifici del progetto relativo. Per gli amanti dell’Agile si tratta di un vero e proprio Information Radiator Digitale in linea con la regola del 3+3: avere chiaro il quadro generale guardando la Board in 3secondi da 3metri.. forse qualche metro in meno :-).

sprintburndown workitems 

Sprint Burndown e Cumulative Flow

 

tfs web access

TFS Web Access / VSOnline Web App

Tali strumenti visuali sono fondamentali per comunicare rapidamente con persone (es: manager o stakeholder) poco interessati agli aspetti di dettagli dello sviluppo ma focalizzati sul quadro complessivo. Il supporto dell’ambiente di BigM non si limita però a ciò, abbracciando un set di funzionalità legate alla verifica della Qualità del Codice (Code Quality), anche se, per inciso, sono strumenti integrati più nell’IDE Visual Studio (Premium e Ultimate) che in TFS/VisualStudioOnline. Tra essi troviamo:

  • Code Clone Detection, per la ricerca di codice duplicato;
  • Code Metrics, per misurare la complessità e la manutenibilità del codice;
  • Code Profiler, per analizzare l’utilizzo della memoria da parte del codice ed individuare colli di bottiglia nelle performance;
  • Static Code Analysis, per effettuare un check del codice basato su standard di riferimento (es: best practice per lo sviluppo .NET: i nomi dei metodi devono iniziare con la Maiuscola);
  • Unit Testing / Coded UI Tests /Code Coverage, supporto allo Unit Test (MSTest, xUnit o altri);
  • Fakes Framework, per la generazione automatizzata di Mocks e Stubs;

Nonostante esistano strumenti ad-hoc per ognuna delle aree evidenziate, con funzionalità estreme, il grande vantaggio della soluzione Microsoft è la completa integrazione, consentendo così di produrre in modo efficiente codice di maggiore qualità rispettando i vincoli decisi con la DoD. In particolare, l’utilizzo delle batterie automatizzate per il Test e il settaggio dei Build Agent di TFS permettono di abbracciare in pieno la pratica della Continous Integration (CI) che prevede un’integrazione completa e testata di quanto sviluppato sulla main-line di sviluppo. Gli strumenti forniti consento di impostare opportune policy (per esempio: inibire il check-in se non si superano i test di unità presenti nella solution) in modo da automatizzare il tutto.

Sia le operazioni di Build che le attività di Testing sono gestibili tramite la Web App di TFS/VisualStudioOnline o direttamente da Visual Studio.

A proposito di main-line: dalla versione 2013, TFS/VisualStudioOnline supporta pienamente sia il source control centralizzato proprietario (TFVC) che il distribuito GIT, consentendo di applicare le politiche di gestione del codice sorgente che più si adattano al proprio contesto.

tfvc git

TFVC & GIT

Se si lavora in ottica Scrum e Continous Integration (se non praticate quest’ultima vi consiglio vivamente di “incamminarvi” su questa strada), si può adottare una strategia di branch “Sprint-to-Branch” in cui si crea un nuovo branch ad ogni nuovo Sprint, legandoli direttamente tra loro.

stretegia di branch

Branch Strategy: Sprint-to-Branch

Il prossimo post sarà dedicato allo Sprint Review e allo Sprint Retrospective, evidenziando come TFS/VisualStudioOnline sia di supporto alla loro esecuzione.

Comments are closed.