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.

Gestire le dipendenze funzionali

Ok, abbiamo deciso di utilizzare DAD, SAFe, Scrum o la metodologia/framework Agile che più ci ha convinto e abbiamo creato il Program Backlog grazie all’intenso lavoro del Product Owner in accordo con il Team.

A questo punto partiamo con la prima iterazione di sviluppo e dopo alcune ore di lavoro (e alcuni task completati) ci accorgiamo che per completare il task attuale abbiamo bisogno che il nostro collega completi il suo. In perfetta ottica di knowledge sharing, parliamo con lui e scopriamo che anche il suo task è bloccato, in attesa che un terzo completi un ulteriore task di base.

user stories dependency

User Story Dependency

Siamo in stallo e stiamo sprecando tempo!

La situazione descritta è sicuramente capitata a tutti, nessuno escluso, e le cause possono essere segmentate in tre gruppi principali:

  • End-User driven, la causa è da ricercarsi nelle Feature richieste dai key-stakeholder. Immaginiamo che il nostro cliente voglia un sistema di e-commerce: non posso completare la feature “carrello” finché non creo anche la UI che mi permette di visualizzare e selezionare i prodotti;
  • Requirements decomposition, in questo caso la dipendenza è iniettata dal modo in cui un requisito di alto livello è splittato in più requisiti più semplici (approccio Top-down);
  • Technology driven, questo ultimo gruppo raccoglie le dipendente di tipo tecnologico, ovvero dettato da vincoli Architetturali, di Piattaforma, di Integrazione, ecc.. Tornando all’esempio precedente: non posso testare la funzionalità di acquisto finché non completo il data layer.

Le situazioni a cui si può andare incontro, come si può ben intuire, sono molteplici e di complessità differente, e quindi è necessario, in base al contesto, avere un approccio strutturato che consenta di abbattere tali situazioni.

I principali attori a cui è affidato il governo di tali situazioni sono: il Product Owner e l’Architect Owner. Il primo ha il massimo peso nel caso di condizioni di stallo End-User driven, il secondo nel caso di situazioni Technology drive. Il caso intermedio (Requirements decomposition) vede entrambi protagonisti, teoricamente, alla pari.

Ma come è possibile risolvere le dipendenze ed evidenziarne l’esistenza? Ebbene, la letteratura consiglia alcune possibili strategie:

  • Ri-priorizzare uno o più Work Item: in questo caso il Product Owner può decidere di riorganizzare la priorità di uno o più Work Item in modo da abbattere il rischio di stallo, bilanciando l’approccio Value-Driven con quello Risk-Driven. Molto lavoro, in questo caso, deve essere fatto dal Product Owner nei riguardi dei key-stakeholder per spiegare l’eventuale ritardo di feature ritenute prioritarie, a favore di un’ottimizzazione del tempo e dei costi di progetto;
  • Utilizza Mock o Stub: questo approccio è quello, probabilmente, più tecnico. Infatti i vari moduli vengono isolati e per ogni dipendenza viene creato un Mock che ne simula il comportamento. Per lo scopo possono essere utilizzate apposite librerie come, ad esempio, Microsoft Fakes Framework. Lo svantaggio è che non è possibile rilasciare quanto sviluppato perché comunque incompleto e non funzionante nel complesso;
  • Rivedere i requisiti relativi: in tal caso si opta per una segmentazione dei requisiti di una feature. Se una feature non può essere completata in una sua parte per colpa delle dipendenze (ad esempio non posso completare l’acquisto on-line con carta di credito ma solo tramite paypal), si rimuove temporaneamente l’elemento bloccante. In tal modo è possibile completare correttamente l’iterazione, ottenendo un prodotto finito, ma con alcune funzionalità rimandate (è chiaramente da valutare il Cost of Delay).

Qualunque sia la strategia applicata, resta indispensabile evidenziare le dipendenze, sia per procedere correttamente nello sviluppo, sia per le future attività di manutenzione. Come sempre, l’ideale è quello di scegliere un approccio il più semplice possibile: se il Team lavora a stretto contatto e nello stesso open-space è possibile tranquillamente utilizzare apposite Board fisiche con una specifica organizzazione dei task (Physical dependency map). Se si applica una politica di gestione tramite uno strumento digitale ALM, come TFS, possiamo sfruttarne le specifiche funzionalità. Restando sullo strumento Microsoft, il modo più immediato è quello di utilizzare la funzionalità di “linking” sui vari Work Item.

workitems link vsonline

Linking TFS/VS Online

Prima di concludere è doveroso aprire una parentesi su un aspetto volutamente trascurato fin ora: quanto descritto vale per un Program Backlog associato ad un singolo Team (in pratica un Team Backlog) ma può essere opportunamente esteso al lavoro congiunto di più Team. In tal caso abbiamo un Product Owner per ogni Team (coordinato da un Chief Product Owner) e possiamo avere uno o più Architect Owner (anche qui coordinati da un Chief Product Owner), che creano una sorta di “Regia” per la gestione delle dipendenza. In tal caso, inoltre, gli strumenti digitali di gestione ALM diventano un MUST, essendo la fisicità un mero ricordo.