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.

0  

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.

Associare il proprio Microsoft Account con l’account aziendale per condividere i benefici dell’abbonamento MSDN su Visual Studio Online

In un precedente post avevo parlato del funzionamento del piano Basic gratuito di Visual Studio Online e della possibilità di superare il numero di 5 utenti a patto che gli eccedenti siano in possesso di un abbonamento MSDN.

Con l’attuale possibilità di utilizzare Visual Studio Online sia con il proprio Microsoft Account che con l’account aziendale, per qualcuno si potrebbe porre il problema di riuscire a condividere i benefici dell’abbonamento su entrambi gli account, potendo quindi partecipare sia a progetti aziendali che extra-aziendali senza essere in entrambi i casi contati come utenti Basic.

Fortunatamente il problema è facilmente risolvibile associando i due account dalla propria sottoscrizione MSDN.

Apriamo quindi il nostro browser preferito e navighiamo su http://msdn.microsoft.com accedendo se necessario con il nostro Microsoft Account. Selezioniamo quindi in alto a destra il link Abbonamenti MSDN.

Nella sezione Visual Studio Online selezioniamo il link Collegamento all’account aziendale.

Nel dialog box Link to your Organizational Account impostiamo il nostro Account aziendale e clicchiamo sul pulsante Collega.

I due account risultano ora collegati (collegamento che è sempre possibile modificare o rimuovere utilizzando i link opportuni) ed è quindi possibile utilizzare i privilegi della propria sottoscrizione MSDN su entrambi.

Happy coding!

Scrum and TFS: cookbook

Nel corso di questi mesi abbiamo parlato dell’ALM in chiave Agile, evidenziando framework, approcci, best practice, strumenti e attività pratiche.

Inauguriamo, ora, una serie di post che hanno l’obiettivo di fornire una “soluzione tipo” per utilizzare Scrum e TFS (Team Foundation Server / Visual Studio Online) per la gestione di un progetto di media complessità. Prima di iniziare è, però, utile fare una precisazione: non si tratta di una soluzione “chiavi in mano” ma di un case-study che si può analizzare e che va adattato al proprio contesto. Inoltre la scelta di Scrum e TFS è dettata dalla volontà di abbracciare il framework Agile più diffuso e il miglior software di supporto all’ALM attualmente disponibile (fonte Gartner’s Magic Quadrant).

scrum tfs market adoptions 2013

Scrum e TFS, ALM leader

Inoltre, anche se potrebbe sembrare ripetitivo, accenneremo ai fondamenti di entrambi, evitando al lettore di “saltare” sul web per cercare informazioni base relative.

Allora… cominciamo!!

 

Pt.1, ALM: Scrum + TFS ed oltre

La complessità del software ha raggiunto nell’ultimo decennio un livello tale da considerare oggi la sua produzione una delle attività più onerose e difficili da realizzare.

Riferendosi al framework Cynefin [post relativo], un sistema è definito “complesso” quando non può essere modellato secondo un approccio lineare (matematicamente secondo equazioni lineari) perché il funzionamento olistico è più della somma del funzionamento delle singole parti, dipendendo anche dalla sua evoluzione/storia.

Questo ragionamento si applica all’intero ciclo di vita del prodotto, richiedendo la definizione di una strategia complessiva e di tattiche specifiche che si applicano alle varie fasi di gestione della vita di un software, dalla progettazione allo sviluppo, fino ad arrivare alla sua dismissione: Application Lifecycle Management, appunto.

Volendo riportare una buona definizione di cos’è l’ALM (ne esistono diverse, con focus differenziato sui vari aspetti), possiamo affidarci a Wikipedia:

“Application Lifecycle Management (ALM) is a continuous processof managing the life of an application through governance, development and maintenance. ALM is themarriage of business management to software engineering made possible by tools that facilitate andi ntegrate requirements management, architecture, coding, testing, tracking, and release management.”

Ma qual è il “core” dell’ALM? Soddisfare le esigenze del cliente (stakeholder), fornendo gli strumenti e le pratiche utili a catturare i feedback e a riorganizzare le attività in funzione della loro priorità. E qui il connubio con l’Agile è assolutamente evidente e “naturale”.

alm process

Application Lifecycle Management

In particolare, tra le diverse metodologie e i diversi framework Agile adottati, Scrum si è imposto nell’ultimo decennio come riferimento per un approccio moderno alla gestione dello sviluppo del software.

scrum process

Scrum Process

Il successo è dovuto ad un fattore principale: Scrum funziona ed è in grado di adattarsi a contesti fortemente eterogenei. Questo grazie al fatto che la metodologia creata da Ken Schwaber e Jeff Sutherland definisce una serie di ruoli, artefatti e momenti di riflessione/analisi, lasciando “libero” il Team di applicarli al proprio contesto. Attenzione: ciò non vuol dire che vige l’anarchia perché Scrum è difficile da implementare correttamente e va applicato nella sua interezza, altrimenti non si sta utilizzando Scrum! Quindi, niente “Scrum… but”! [si veda: Call it as you want, but don’t call it Scrum if it’s not!].
Possiamo descrivere, sinteticamente, l’applicazione dello Scrum process come segue:

Il {Product Owner (PO)}, dopo essersi confronta con gli stakeholder, definisce e priorizza le attività in quello che viene chiamato {Product Backlog}. A questo punto, lo {Scrum Master (SM)} riunisce il Team (compreso il PO) e, insieme ad esso, crea lo {Sprint Backlog} selezionando le attività da sviluppare nella successiva Iterazione {Sprint}. Prima di fare ciò, però, il Team ha definito il significato di “DONE”, ovvero quando una attività si può definire terminata (sviluppo, testing, documentazione, ecc..). Per ogni attività vengono definiti task unitari di lavoro, ne viene stimato il tempo di sviluppo in ore e, assolutamente fondamentale, i relativi criteri di accettazione.

Terminato lo {Sprint Planning}, lo Sprint (1sett. – 1mese) parte e i task individuati cominciano ad essere sviluppati. Giornalmente, prima di iniziare le attività, il Team tiene un meeting di 15minuti chiamato {Daily Scrum} in cui ci si confronta su cosa è stato fatto, cosa si farà nell’immediato e quali sono gli eventuali impedimenti.

Solo le attività che rispecchiano in pieno la definizione di “DONE” sono considerate terminate e, una volta raggiunta la fine dello Sprint, si procedete con uno {Sprint Review} in cui si mostra quanto realizzato al PO e agli stakeholder e uno {Sprint Retrospective} che consente al Team di analizzare la propria organizzazione al fine di migliorarla e migliorarsi.

La gestione di tutte le varie fasi può essere fatta senza l’ausilio di alcun supporto digitale, sfruttando, ad esempio, i classici post-it, ma ciò diventa poco pratico se si è in un contesto medio-grande con una struttura eventualmente delocalizzata in varie aree geografiche. Inoltre diventa difficile effettuare attività manuali di data-mining e associare le attività/task a quanto realmente sviluppato, per non parlare di tracciare agevolmente i feedback degli stakeholder e altre operazioni annesse.

Per questo, e non solo, uno strumento digitale di supporto all’ALM è sicuramente di estremo aiuto, soprattutto se flessibile ed integrato con le tecnologie di sviluppo stesse, esattamente come nel caso di TFS.

 

tfs-archi

Team Foundation Server ecosystems

Evitando di entrare negli aspetti di gestione del codice, della relativa integrazione con le piattaforme di sviluppo Microsoft (.Net in primis) e degli strumenti di Continuous Integration, due elementi rendono TFS particolarmente attraente e flessibile: l’indipendenza dalla metodologia di gestione adottata e la sua estendibilità. Il primo elemento si ottiene grazie ai Process Template, ovvero un “pacchetto” che definisce gli elementi caratterizzanti la metodologia scelta (es per Scrum: workitem, bug, impediment, ecc.) e le loro caratteristiche. E’ possibile definire un Process Template custom e continuare a utilizzare, in accordo con esso, tutti gli strumenti di TFS, senza dover modificare praticamente nulla nella piattaforma di supporto. L’altro punto di forza, come detto, è l’estendibilità, che consente di estendere TFS ed interrogarlo direttamente dai propri servizi/strumenti, sfruttando, ad esempio, le Team Foundation Server OData API.

Il nostro viaggio è solo all’inizio, nel prossimo post vedremo come creare un nuovo Scrum Project in TFS e gestire il Product Backlog, in accordo con l’esecuzione dello Sprint Planning.

Connettere il proprio account VSO al nuovo portale Azure

Il nuovo portale azure, http://portal.azure.com permette anche la gestione del proprio account di Visual Studio Online, ma fino al precedente deploy, era possibile gestire solamente i nuovi account creati dal nuovo portale. Da due aggiornamenti fa è invece possibile ora connettere i propri account esistenti, ma è necessario fare attenzione ad alcuni importanti fattori.

Connettere il proprio account è una operazione molto semplice.

Il primo passo è agganciare l’account VSO esistente al vostro account azure dal portale standard http://manage.windowsazure.com

image

Una volta connesso il proprio account VSO al proprio account di Azure, la situazione in cui vi trovate è probabilmente questa.

*) Il vostro account VSO non appare ancora nel nuovo portale Azure
*) Se accedete all’account VSO e navigate su un ulteriore account VSO creato in precedenza dal nuovo portale avrete un errore 401 di autenticazione e dovrete effettuare di nuovo un login (con stessa username e password).

Questo accade perché gli account utilizzati dal nuovo portale appartengono alla Directory di Azure, e quindi anche se il vostro account è lo stesso come nome utente e password in realtà sono viste da Azure come due identità differenti.

Prima di connettere l’account VSO al portale azure, VSO richiede un Live ID, una volta che il vostro account sarà connesso, VSO richiederà che l’account sia invece un account della directory di azure a cui si è connessi (Evidenziato dalla freccia nella figura precedente). Questo fa si che i due account, anche se con stesso nome utente e password siano distinti, ma usando purtroppo lo stesso cookie per visualstudio.com, vi causerà la necessità di fare logout e login se passate da un account connesso ad una directory (Directory account) ad uno non connesso che richiede LiveId.

Se osservate la figura precedente, la freccia indica appunto che l’account che sto collegando ad Azure verrà messo nella Default Directory. Per completare la connessione è necessario, sempre dal vecchio portaoe http://manage.windowsazure.com, aprire la sezione degli account di VSO, selezionare l’account collegato e nel tab di configurazione richiedere il collegamento Directory desiderata.

L’operazione non è infatti automatica, ma va richiesta in maniera esplicita e necessita di un certo quantitativo di tempo per essere effettuata (anche qualche ora). Una volta connesso il vostro account dovrebbe apparire come mostrato nella figura sotto.

image

A questo punto potete collegarvi al vostro account, e scoprirete che la vostra foto del profilo e le impostazioni sono cambiate, perché a tutti gli effetti ora state accedendo con l’account legato alla directory e non piu con il Live Id

Questa situazione è ora visibile dal nuovo update di agosto, entrando infatti nel mio account connesso con Azure mi trovo una welcome page in cui, oltre ad avere listati tutti gli account di cui sono proprietario e quelli a cui ho accesso, mi viene esplicitamente mostrata l’identità che è attualmente attiva.

image

Come potete vedere ora io sono connesso alla mia Default Directory, questo perché ho effettuato l’accesso al mio account VSO connesso ad Azure ed alla mia directory. Ora se tento di accedere ad un account VSO che non è connesso a nessuna directory avrò questo risultato.

image

Se leggete il messaggio mi viene detto che l’account Alkampfer@nablasoft.com associato alla Default Directory non è autorizzato ad accedere all’account. Questo perché l’account VSO a cui mi sto connettendo non è connesso a nessuna directory Azure, e quindi si attende un Live Id. A questo punto posso fare semplicemente Sign Out e connettermi con le stesse credenziali ed in questo caso la mia identità sarà quella del Live Id e potrò accedere all’account.

IMPORTANTE: Tutti i precedenti utenti che sono connessi con i propri Live Id ora non potranno più accedere al vostro account VSO fino a che non verranno aggiunti alla default Directory dell’account Azure a cui VSO è collegato.

L’operazione appena effettuata infatti è la base per poter gestire gli account di VSO al di fuori del Live Id. In questo modo si può sincronizzare la propria Active Directory aziendale con Azure, garantendo quindi la sincronia degli account e potendo finalmente gestire gli accessi a Visual Studio Online senza essere forzati ad utilizzare il Live Id.

Purtroppo l’uso degli stessi cookie tende a rendere il processo un pochino complesso, perchè chi come me accede ad account connessi e non connessi tende a dover fare spesso login e logout. Il consiglio migliore che posso dare è questo

1) Usare due browser, uno con cui si accedono agli account connessi ad Azure ed uno in cui si usano quelli non connessi

2) usare la navigazione in incognito per l’account che si usa di meno.

Per chi è interessato all’argomento VSO, continuate a seguire il nostro sito, perché li team di Get Latest Version sta pianificando una serie di articoli sull’argomento.

Gian Maria.

0  

Aggiornamento di VSO agosto 18

Non si fermano gli aggiornamenti di VSO, ed il 18 agosto abbiamo avuto un ulteriore aggiornamento. La funzionalità piu interessante è la possibilità di avere nella home page del progetto una “welcome page” che non è altro che il rendering del file Readme.Md presente nella radice del source control del progetto. Come sintassi è stata usata la GFM ovvero la sintassi Markdown con le aggiunte di GitHub, molto conosciuta nell’ambiente open source.

Nel test hub è stata introdotta la possibilità di effettuare il tagging dei test case, fino ad ora non permessa direttamente dal test hub.

Buon VSO.

Gian Maria.

0  

Welcome SAFe 3.0

Il 25 luglio scorso Dean Leffingwell ha ufficialmente annuncia il rilascio della versione 3.0 dello Scaled Agile Framework.

Le novità sono davvero tante e, praticamente, l’intera impostazione viene fortemente rivista, sia negli elementi che nell’infrastruttura stessa, il tutto in ottica di rendere disponibile alle organizzazioni uno strumento che consenta di focalizzarsi sul Value Delivery, migliorando il coordinamento delle attività annesse a Value Stream particolarmente ampi.

Da una veloce occhiata della Big Picture si nota propria la strutturale riorganizzazione della nuova versione rispetto alla precedente (2.5):

safe 3.0

SAFe 3.0

safe

SAFe 2.5

Si evidenzia subito come il Program Level ed il Team Level si stiano sempre più avvicinando, quasi a fondersi tra di loro, con l’esplicito obiettivo di disegnare un’organizzazione più orizzontale e più efficiente.

Dalla Big Picture 3.0 si nota, anche, un Portfolio Level molto più definito, che abbraccia una o più ART per le Epiche di Business e quelle Architetturali, e che evidenzia una maggiore attenzione a quegli aspetti decisionali strategici che influenzano in maniera diretta tutta l’attività di creazione dei Value Stream.

Volendo fare una panoramica delle innovazioni più rilevanti, troviamo inoltre:

  • Esplicito inserimento dell’approccio Kanban (Portfolio Kanban Systems) per la gestione degli elementi del Portfolio Backlog;
  • Un esplicito focus sulla figura del Lean Agile Leader, con evidenza delle criticità, delle responsabilità e delle competenze annesse;
  • Una diretta dipendenza tra le decisioni strategiche (portfolio Backlog e Value Stream) e il budget disponibile, che non si limita alla semplice contabilità ma viene esteso ad ogni aspetto, come, per esempio, l’innovazione. SAFe 3.0 definisce il Lean-Agile Budgeting come strumento annesso;
  • Enfasi sul ruolo di Coordinamento dei vari Agile Release Train avviati a livello Portfolio per il raggiungimento degli obiettivi di Valore programmati;
  • Particolare attenzione all’aspetto del Delivery (Program Level) con l’introduzione del Release Object e dell’approccio del Delivery on Demand;
  • Code Quality esteso esplicitamente alle pratiche più comuni: Test-First, Continuous Integration e, forse meno scontata, Agile Architetture.

Questo è solo un estratto di quanto presentato con il nuovo framework e di quanto vedremo in diversi post successivi.