Ridatemi il Tachimetro!

Dopo aver partecipato allo splendido evento che risponde al nome di Better Software 2014, conclusosi ieri, eccoci a parlare nuovamente insieme di ALM e VisualStudioOnline.

Uno degli elementi che è emerso durante la 2gg di Firenze, è la necessità di ridurre il gap comunicazionale tra il management (Program e Portfolio) e gli assett operativi aziendali. In quest’ottica, è evidente che parlare, per esempio, ad un CEO o un CFO di Story Point, Sprint, Review, ecc.. ecc.. serve solo a confondere le idee e non ci aiuta ad avere un’organizzazione più dinamica, in grado di cogliere le opportunità emergenti e di soddisfare le aspettative degli stakeholder.

Il Management (Portfolio in particolare) si aspetta di avere delle metriche e di verificare se le nuove Iniziative messe in campo ne stando condizionando il trend in modo positivo. Fortunatamente, gli strumenti di BI che ci consentono di fare ciò sono decisamente maturi, ma spesso alla loro potenza si associa una complessità non irrilevante, sia di set-up, sia di gestione e sia di fruizione.

Se si ha bisogno di un quadro minimale, VisualStudioOnline/TFS ci viene incontro per un’analisi diretta dei dati contenuti nel Repository di progetto grazie alla funzionalità Chart, direttamente gestibile tramite la Web App generale dell’ambiente e attivabile da Work->Queries.

vso chart 1

VSO Query/Chart

Vediamo ora come utilizzare questa interessante funzionalità per mostrare l’evoluzione del progetto e l’andamento del lavoro al nostro management, in maniera più vicina alle loro esigenze.

Prima di tutto creiamo una nuova query di esempio, selezionando, in questo caso, tutti i work item presenti, indipendentemente dal tipo e dallo stato:

vso chart 2 simple chart query

Simple Chart Query

Salvata la nostra query (attenzione a selezionare il folder “Shared Queries”, altrimenti non sarà possibile effettuare il pin sulla home), passiamo alla funzionalità di definizione dei diagrammi (“chart”) e selezioniamo “New Chart”:

vso chart 3

New Chart

Sulla sinistra possiamo scegliere la tipologia di diagramma che vogliamo realizzare (Torta, Istogramma, Pivot, ecc..) mentre nell’area evidenziata in verde settiamo i parametri di riferimento per la generazione dello stesso:

vso chart 4

Scelta del tipo di Chart e settaggio delle informazioni

Una volta raggiunto il risultate desiderato, salvate il tutto.

A questo punto non ci resta che legare il diagramma alla home della nostro Team Project: attiviate il menu del diagramma che volete “pinnare” e scegliete “Pin to Homepage”

vso chart 5

Pin-to-Homepage

Se tutto è andato per il verso giusto, vi ritroverete una home page più “comunicativa” con il vostro cruscotto informativo bello in vista:

vso chart 6

VSO Home with Chart

Come visto, si tratta di uno strumento, entry level, semplice da attivare ed utilizzare, ma di estremo impatto comunicativo. Quando avrete bisogno, e vi assicuro che la domanda è proprio “quando” e non “se”, di uno strumento più raffinato in grado di fare analisi da più fonti e incrociare i dati per creare metriche di dettaglio, potrete pensare di dare uno sguardo a Power BI, nominato di recente da Forrester “Leader in Agile Business Intelligence”.

Chiudo con un OT, ringraziando gli organizzatori di Better Software per l’accoglienza e l’ottima qualità della manifestazione e, segnalandovi, le slide del mio intervento (http://www.slideshare.net/felicepescatore/agilescale-portfolio-level) se volete approfondire gli aspetti legati alla Gestione Olistica aziendale.

Quel vecchio avido di SQL Server

Oggi ho incontrato un problema abbastanza fastidioso configurando un build controller in TFS. L’errore era generato dall’impossibilità di attivare un servizio WCF nell’AT per mancanza di memoria RAM libera. Questo porta ad una regola generale da applicare se avete un TFS a singola istanza, dove SQL Server e AT condividono la stessa macchina.

Se seguite i dimensionamenti di MSDN, la configurazione singola macchina, con 4 GB di RAM ed un disco 10k è sufficiente per gruppi fino a 500 utenti. Se la vostra soluzione è virtualizzata, avete anche il vantaggio di poter dare più RAM e più CPU con poco sforzo e quindi la soluzione singola macchina, è comoda perché vi occupa solamente una licenza di Windows Server ed è di facile manutenzione.

La regola di base che dovete tenere in mente è che SQL Server tende a consumare tutta la memoria disponibile, lasciando poche risorse al resto. In questo caso l’occupazione di memoria di SQL era arrivata a 3 GB lasciando praticamente nulla disponibile al resto dei servizi. La regola doro quindi è quella di limitare l’uso di RAM di SQL Server, in modo da bilanciare l’uso delle risorse ed evitare questi problemi.

In questo specifico caso purtroppo era mancata la checklist, dato che come sempre avevo parlato di questo problema all’amministratore, ma poi con tutte le cose da fare entrambi ci siamo dimenticati fisicamente di farla, per cui purtroppo, come volevasi dimostrare, senza limitazione SQL Server ha occupato cosi tante risorse da compromettere il funzionamento degli altri servizi.

Ricordate sempre di monitorare le risorse usate dai vari componenti di TFS, cosi da prevenire errori di questo tipo.

Happy TFS.

Gian Maria.

2  

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… 

Quando faccio git push quali branch sto pushando?

Lavorando in command line in Git si potrebbe erroneamente pensare che facendo un

git push

Si effettui il push della sola branch che è in checkout, ma questo non è vero, dato che il reale comando per effettuare il push di una branch è

git push remotename branchname

Quindi se state nella branch XYZ ed avete un  unico remote chiamato origin dovete fare

git push origin XYZ

Il comportamento adottato da git se non specificate ne il remote ne la branch è determinato dalla impostazione push.default e come possiamo leggere dalla documentazione le possibilità sono.

nothing – do not push anything.

matching – push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default.

upstream – push the current branch to its upstream branch.

tracking – deprecated synonym for upstream.

current – push the current branch to a branch of the same name.

Il default è matching, per cui facendo un git push state effettuando il push di tutte le vostre branch. Questa opzione probabilmente non è il miglior default che si possa avere, per questo in Git 2.0 il default verrà modificato in “Simple”, un ulteriore nuovo possibile valore per push.default:

simple – in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch’s name is different from the local one. When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners. This mode has become the default in Git 2.0.

Fate quindi attenzione al modo che avete selezionato per evitare sorprese.

Gian Maria.

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

Completato il nostro Sprint ci aspettano 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 Continous 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à.

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.

Le novità dell’aggiornamento di Visual Studio Online del 4 settembre

Il lavoro incessante del team di sviluppo di Visual Studio Online non si ferma neanche d’estate e, puntuali come sempre, allo scadere delle tre settimane ecco disponibili le novità portate a termine nel corso del 70esimo sprint.

È uno sprint che presenta parecchie interessanti novità che aiuteranno senza dubbio quelli che utilizzano VSO quotidianamente per i propri progetti di produzione.

Vediamo rapidamente di cosa si tratta, riservandoci di approfondire le funzioni più interessanti in un prossimo post.

  1. Gestione delle query sui Work Item
  • Un nuovo comando consente di inviare direttamente un email con le informazioni sul Work Item;
  • Dopo aver aperto il dettaglio di un Work Item che fa parte di una query, oltre ai pulsanti per navigare sul Work Item precedente o successivo, è ora disponibile un nuovo comando per tornare alla lista. Il comando è attivabile anche con lo shortcut da tastiera ALT+Q e replica il comportamento già garantito dal tasto back del browser. In tutte e tre modalità (comando della toolbar, shortcut e tasto back) il ritorno alla lista avviene con l’elemento corrente (quello di cui stavamo esaminando il dettaglio) che viene automaticamente selezionato;
  • La modalità full screen, che massimizzando lo spazio a disposizione per l’elemento selezionato risulta particolarmente utile ad esempio durante i meeting Scrum, è ora disponibile sia sulle query che su tutti i tipi di Work Item;
  • Nel menu contestuale attivabile sui risultati di una query è ora disponibile un nuovo comando che apre il Work Item in un tab separato. Il nuovo tab ha qualche piccolo difetto di gioventù, ad esempio dalla toolbar manca il comando per attivare la modalità full screen che è però attivabile cambiando “a mano” il querystring.
  1. Ricerca rapida nei controlli ad albero
  • Lavorando con VSO capita spesso, anzi direi sempre, di dover impostare o modificare l’area o l’iterazione a cui un particolare Work Item fa riferimento. Come sapete ciò è possibile per mezzo di un comando ad albero che si apre a tendina e ci consente di navigare nella gerarchia delle iterazioni (o delle aree) fino a selezionare quella desiderata. Fin tanto che “giochiamo” con un progetto di prova tutto funziona a meraviglia. Quando però ci cimentiamo con un progetto “reale”, in cui ad esempio il numero di release e di sprint può diventare notevole, utilizzare il controllo non era propriamente agevole. Da oggi è possibile cominciare semplicemente a scrivere nel campo Iteration (o in quello Area) per veder apparire una lista sottostante che presenta gli elementi filtrati in base al testo inserito. Se il valore che vogliamo impostare è univoco e quindi sufficiente premere Invio per selezionarlo. Se ad esempio vogliamo mettere un Work Item nello sprint 70 è sufficiente scrivere 70 e premere Invio (supponendo che non ci siano due iterazioni che contengo il testo 70 nella propria descrizione) con un bel risparmio di tempo.
  1. Nuovi grafici di tendenza
  • Sono disponibili due nuovi intervalli di tempo per i grafici sui Work Item che mostrano i risultati relativi rispettivamente alle ultime 12 settimane e all’ultimo anno. Per i nuovi due intervalli i dati non sono ovviamente mostrati su base giornaliera ma sono invece raggruppati per settimana nel primo caso o per mese nel secondo.
  1. Più elementi nella Kanban board
  • Il limite di 20 elementi visualizzabili nella prima e nell’ultima colonna della Kanban board è stato sostituito con un limite di 999 che è decisamente adeguato anche per progetti più grandi e duraturi. Il valore può essere al solito impostato nella schermata di personalizzazione delle colonne.
  1. Evidenza di tutte le Test Suite a cui un Test Case appartiene
  • Man mano che il progetto cresce è molto probabile che uno stesso Test Case finisca per far parte di più Test Suite. In tal caso prima di apportarvi delle modifiche è bene verificare e ponderare gli eventuali effetti collaterali sulle diverse Test Suite. Una nuova opzione sul pannello dei filtri consente ora di visualizzare immediatamente tutte le Test Suite a cui il Test Case selezionato appartiene.
  1. Preview 2 delle API WIT
    Sulla base dei tanti feedback ricevuti dopo il rilascio della Preview 1, il team di VSO ha rilasciato una nuova preview che include:
  • Modalità più semplice di creazione e modifica dei Work Item;
  • Esecuzione più facile di comandi ad-hoc che utilizzano il Work Item Query Language;
  • Accesso alla lista delle aree e delle iterazioni;
  • Nuove API per elencare i tipi di Work Item e Link, le Categorie e i Campi;
  • Oggetti di ritorno JSON meno prolissi.

È comunque possibile configurare quale versione delle API si intende utilizzare per mantenere compatibilità con integrazioni già realizzate.

  1. Supporto per Hubot
  • Le Team Room di Visual Studio Online possono ora essere collegate alla chat open source Hubot. L’integrazione consente di migliorare la produttività semplificando ad esempio la creazione di Work Item, la pianificazione di una Build o la visualizzazione del proprio lavoro recente direttamente dalla Team Room.

Happy coding!

Scrum and TFS cookbook – pt.3, go to the Sprint!

Dopo la creazione del Program Backlog e del Product Backlog, illustrate nel post precedente, siamo pronti a settare TFS/VisualStudioOnline per accompagnare il nostro Sprint: tuffiamoci nello Sprint Planning!

sprint plagging

Sprint Planning: let’s start!

Cos’è lo Sprint Planning? Si tratta della cerimonia Scrum a cui è demandata lo start-up di un nuovo Sprint, sotto il cappello di uno “Sprint Goal” che definisce l’obiettivo d’insieme dell’iterazione stessa. Il goal guida la scelta delle User Story (PBI) che andranno a formare lo Sprint Backlog e che devono trovarsi al top dello stack che rappresenta il Product Backlog, cosa che le assegna un’alta priorità relativa.

Il numero di User Story da “inserire” nello Sprint hanno una relazione diretta con la Velocity raggiunta nello Sprint precedente dal Team, ottenuta sommando gli Story Point completati in funzione delle User Story completate. Nel caso in cui l’ultimo Sprint è stato interessato da eventi esterni che hanno inficiato il valore della Velocity, è possibile utilizzare una media storica come valore di riferimento.

Ma come stimiamo gli Story Point associati ad una User Story? Come sempre, esistono diverse tecniche, ma vi suggerisco il Planning Poker basato sulla sequenza di Fibonacci “corretta” che, inoltre, contribuisce alla discussione sulla singola User Story al fine di condividerne il significato ed il dominio.

planning-poker-fullfan

Le carte per il Planning Poker

L’attività di stima si svolge nel seguente modo:

ogni membro del Team ha un proprio deck di carte con sopra la sequenza di Fibonacci “corretta” (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinito, 0,5, ?). Lo Scrum Master legge ad alta voce la User Story e chiede ad ogni membro del Team di stimare la relativa complessità scegliendo una carta dal mazzo e posizionandola con il dorso verso l’alto su una scrivania di supporto. Sempre su indicazione dello SM, tutti i membri del Team girano contemporaneamente le carte: a questo punto chi ha indicato il valore più basso e chi ha indicato quello più alto dispongono di 3minuti per motivare la scelta. L’operazione si ripete finché il Team non raggiunge un’opinione comune sulla complessità della User Story. Nel caso in cui il valore scelto sia di 40, 100, infinito, è opportuno che la User Story venga messa da parte ed analizzata con dovizia per essere divisa in User Story più semplici.

Stimata la complessità della User Story, si passa alla definizione dei Task relativi che rappresentano l’unità minimale di lavoro stimata in ore. Il consiglio è quello di non effettuare una “stima verticale” (prima tutte le User Story e poi tutti i Task), ma seguire un approccio “orizzontale”: prendo una User Story dal Product Backlog, la stimo, definisco/stimo i relativi Task, passo alla successiva User Story. Questo per favorire una comprensione più di dettaglio della User Story corrente e di conseguenza del progetto, cosa che può essere sfruttata già nelle stime immediatamente successive.

La cosa migliore è quella di effettuare tutta la fase relativa allo Sprint Planning usando un approccio diretto, ovvero tramite flip-board, post-it, deck-card, ecc, e solo successivamente riportare il tutto su TFS/VisualStudioOnline. Questo per essere assolutamente in grado di adattare la cerimonia alle proprie esigenze e non essere vincolati ai constraints dello strumento.

Detto ciò, passiamo a TFS. Purtroppo l’ultima versione, compreso VisualStudioOnline, non dispone di “un’Area Sprint” o di uno “Sprint Work Item” per raccogliere lo “Sprint Goal” (congiuntamente ad alcuni altri elementi di Scrum), e, in attesa che vengano introdotti specifici elementi, possiamo associare lo Sprint Goal al nome dell’Iterazione, contando sul fatto che esso è tipicamente caratterizzato da una descrizione sintetica.

 tfs example 11

Sprint Goal

In alternativa è possibile, solo per TFS, creare un apposito Work Item o importare quello specifico esistente nella versione 2010.

tfs example 12

Sprint Work Item TFS 2010

Fatto ciò, l’attività da fare è quella di associare i Work Item (User Story) dello Sprint Backlog appena definito allo Sprint corretto definito in TFS, selezionando ed impostando l’Iterazione (Iteration) di assegnazione.

tfs example 13

Assegnazione Iterazione

Un’ulteriore utile aggiunta da fare è l’inserimento del “Peso” (Effort, ovvero Story Point) e del “Valore” (Business Value) per ogni User Story, valorizzando la sezione “Details” con quanto emerso durante il Planning Poker. Ciò sarà utile per gli strumenti di analisi.

tfs example 14

Effort e Priorità

Non ci resta ora che assegnare la Priorità, in accordo con lo Sprint Backlog ed il Product Backlog: questa azione è “implicita” nel senso che si ottiene spostando con il mouse i Work Item nell’ordine (alias priorità) desiderato. Completati tutti i settaggi, selezionando lo specifico Sprint, TFS vi presenterà un summary simile a quello seguente:

tfs example 15

Sprint summary

Una puntualizzazione: le uniche User Story ad essere state stimate sono quelle selezionate per lo Sprint in starting, mentre la stima di quelle rimanenti all’interno del Product Backlog è differita ai successivi Sprint Planning. Si tratta di una precisa scelta, legata alla teoria delle code (per approfondimenti, The Principles of Product Development Flow: Second Generation Lean Product Development – D. Reinertsen) in cui si dimostra l’inutilità di stimare completamente gli elementi di uno stack (alias Product Backlog), poiché la relativa conoscenza aumentare durante il progetto, alcuni di essi verranno eliminati ed altri introdotti.

Ciò rende praticamente inutile la funzionalità di “Forecast” (previsione) attivabile nella visualizzazione dei PBI perché richiede l’assegnazione dei pesi a tutti i Work Item, cosa in netta contraddizione con quanto appena detto.

tfs example 16

TFS Forecast

In sintesi: ignorate tale funzionalità, fa scena ma non serve a nulla.

Quello che invece bisogna settare è la Capacity (capacità) del Team sullo Sprint, selezionando chi lavorerà sul progetto, in quale sub-area e per quante ore al giorno. In tal modo si indicano le ore totali che il Team dedicherà allo Sprint, suddivise, se ha senso, per area.

tfs example 17

 Sprint “Capacity”

Questo dato risulta utile per avere costantemente una stima di capacità/carico di lavoro, che però diventa evidente solo con l’ultimo degli step che descriviamo oggi: l’inserimento dei Task relativi alle User Story incluse nello Sprint.

Selezioniamo “Board” e passiamo alla relativa visualizzazione:

tfs example 18

Sprint Board View

Clicchiamo sul segno “+” adiacente la User Story e creiamo un nuovo Task, compilando i relativi dettagli:

tfs example 19

Nuovo Task

Salviamo e, a questo punto, ci troveremo difronte a una Board contenente il nuovo Task con riportare le relative ore.

tfs example 20

Sprint Board

Ovviamente i Task da creare sono quelli definiti nello Sprint Planning.

La nostra finestra di stima della capacità del Team (alla destra dei Work Item nella visualizzazione Backlog dello Sprint) somiglierà alla figura seguente:

tfs example 21

Work

Si conclude così la fase di “pre-settaggio” dello Sprint sulla base di quanto emerso durante lo Sprint Planning. Da sottolineare l’uso del termine “pre-settaggio” scelto per evidenziare che l’ambiente di lavoro relativo ad un Sprint è in continua evoluzione e questa è solo una fotografia del suo stato nella fase iniziale.

Non ci resta che tuffarci nello Sprint vero e proprio, chiaramente nel prossimo post ;-)

Alcuni approfondimenti:

Licenza Stakeholder

Come annunciato tempo fa da Brian Harry è ora disponibile la Licenza di tipo Stakeholder per VSO. La cosa importante di questa licenza è che è completamente gratuita e permette di gestire gran parte dei Work Item senza quindi costi aggiuntivi.

Vi invito a leggere la news relativa: http://www.visualstudio.com/en-us/news/2014-aug-27-vso

Gian Maria.

Comments Off  

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 l’Agile Portfolio. Il nostro “libro delle ricette” contempla due soluzioni operative, in funzione del fatto che:

  1. esista un solo Team di sviluppo (single-Development Team);
  2. esistano più Team di sviluppo (multiple-Development Team, descritto in uno specifico post successivamente).

In entrambi i casi, però, l’elemento centrale è il Product Backlog, la cui proprietà 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 (Continous 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 (come detto vedremo in un apposito post della serie come “aggirare” questa limitazione), 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);

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.