Nuovo Deploy per Visual Studio Online

Ieri è stato effettuato un nuovo deploy per Visual Studio Online. In questo deploy le modifiche maggiori sono fatte relativemente all gestione degli Organizational Account, ovvero potere usare i vostri account di Active Directory invece del LiveId per connettersi a VSO. In realtà questa funzionalità era già presente, ma disponibile solamente in fase di creazione di un nuovo account VSO, ora è invece possibile effettuare la richiesta ed agganciare un account VSO esistente ad un proprio Organizational Account.

Un’altra importante modifica è la possibilità di visualizzare i propri account VSO esistenti nel portale di Azure Preview (http://portal.azure.com). Fino ad ora infatti nella preview del portale era possibile solamente visualizzare i nuovi account creati dal nuovo portale, ora invece è possibile anche visualizzare i precedenti account VSO legati al proprio account.

Altre modifiche minori riguardano il licensing e specificatamente di includere tutta la parte di Test web-based per gli utenti con una Advanced License. E’ anche ora possibile cancellare il proprio account direttamente dall’interfaccia web, senza dover chiamare il support service.

Per quanto riguarda invece modifiche alle funzionalità disponibili nel sito, sono finalmente arrivati i grafici con trend, che permettono di avere una visualizzazione dell’andamento nel tempo di alcuni valori dei vostri work items.

Happy TFS.

0  

Back to Value, Agile Portfolio Management

Più volte abbiamo parlato del Portfolio (level), mostrando come gestire uno specifico Backlog con TFS2013 in modo da splittare le attività si più Team. Soffermiamoci ora sul Portfolio in se, rispondendo alla domanda “Come creo e gestisco efficacemente un Agile Portfolio?”.

Ebbene, la creazione e la gestione dell’Agile Portfolio per la produzione del software è un’attività complessa (cynefin – complex quadrand) quanto la creazione del software stesso. L’approccio Agile (e Lean) ha reso definitivamente chiaro che molta della complessità è legata alle interazioni che si creano tra le varie persone coinvolte nel processo di produzione, e ciò si riflette anche nella gestione del Portfolio di riferimento.

In generale, il punto di partenza per la definizione di un Agile Portfolio è la Vision strategica aziendale, che contempla fattori come: trend di mercato a medio e lungo termine, obsolescenza tecnologica, opportunità di business, morfologia del mercato, ecc…

Questi aspetti sono l’essenza di uno degli elementi portati dell’Agile Portfolio, il Portfolio Planning.

agile portfolio

La definizione del Portfolio Planning è la linfa costituente dei 4 pilastri (four pillar) dell’Agile Portfolio:

  • Value Management, definisce puntualmente cosa rappresenta il “Valore” nella Vision corrente, cosa che si concretizza nel Value Stream più volte richiamato in SAFe;
  • Work Management, sono le azioni di gestione messe in atto per portare a compimento le azioni di perseguimento del Value Stream, ad esempio l’Agile Release Train;
  • Capacity Management, condensa le azioni di gestione di tutto ciò che riguarda le risorse disponibili per il raggiungimento degli obiettivi, prima tra tutte le professionalità coinvolte, fondamentali negli ambiti di produzione complessi;
  • Financial Management, definisce gli espetti finanziari complessivi, legando le fasi al rispetto del budget e agli obiettivi di revenue che si vogliono perseguire.

Ognuno dei quattro pilastri ingloba, in misura differente e con approccio differente, le attività di Risk Management che, chiaramente, assumono un significato diverso in base al contesto di riferimento.

Infine, ma solo per descrizione non certo per importanza, troviamo il Portfolio Performance che trasforma la Vision in azioni concrete nell’ambito dello sviluppo e del posizionamento sul mercato. Un esempio: se la Vision è quella di “lanciare un treno” (ART launch) che abbatte costantemente il time-to-market, questo si traduce in una chiara impostazioni anche nelle attività di sviluppo che potrebbero, ad esempio, seguire una logica Lean.

E’ tutto? Assolutamente no! Abbiamo dimenticato uno degli aspetti più importanti e onnipresenti nel mondo Agile/Lean: il feedback che fluisce a tutti i livelli per riallineare costantemente il Portfolio con la situazione contingente o, dualmente, spingere affinché quest’ultima si avvicini maggiormente alla strategia inerente la Vision.

Be SAFe!

Come cambia il licensing di VSO / TFS

La notizia che Brian Harry ha dato sul suo blog è di quelle decisamente importanti. Sebbene le notizie sulle nuove funzionalità introdotte in TFS / VSO siano quelle più interessanti per i tecnici e per chi usa tutti i giorni gli strumenti, probabilmente le novità sul licensing sono quelle che in realtà impattano molto di più l’uso di un servizio.

Nel post sopra linkato si parla del livello di accesso per gli Stakeholder di VSO, ovvero tutte le persone che sono interessate al progetto che si sta realizzando. Questa richiesta è tipica di chiunque adotta TFS / VSO, di che tipo di licenza necessito per far si che i miei clienti e gli Stakeholder in generale siano in grado di accedere al mio TFS per segnalare bug / feedback / PBI etc?

Attualmente per TFS on-premise si ha la possibilità di usare un livello chiamato “limited” che permette ad un utente il solo diritto di inserire Work Item e visualizzare solamente quelli da lui inseriti. In VSO purtroppo questo livello, usato normalmente on-premise per permettere agli stakeholder di segnalare bug e richieste di modifiche, non era ancora presente. Questo fa si che per ogni persona che volete abilitare per visualizzare e gestire i Work Item dovete avere un utente di livello Basic, una spesa che chiaramente limita fortemente il numero di stakeholder coinvolti.

Oggi Brian Harry invece annuncia che sta per arrivare un cambiamento di licenza per VSO che permetterà agli stakeholder di accedere gratis a VSO con la possibilità di:

  • Full read/write/create on all work items
  • Create, run and save (to “My Queries”) work item queries
  • View project and team home pages
  • Access to the backlog, including add and update (but no ability to reprioritize the work)
  • Ability to receive work item alerts

Chiaramente questo livello di accesso non permetterà di gestire codice, build, test e tutte le attività che sono attinenti al team, per i quali valgono i costi attuali.

L’aspetto interessante, è che questo livello di cambiamento di licenza sarà poi esteso anche al TFS on-premises, rendendo l’offerta di TFS sempre più allettante.

Gian Maria.

0  

Back to Value, draw the canvas!

Dopo aver presentato il Product Canvas ed avere mostrato, brevemente, come integrarlo con gli strumenti comune in ambito ALM Microsoft, non ci resta che passare alla parte più interessante: dipingere la tela!

SampleProductCanvas

Un Product Canvas “popolato” (Roman Pichler)

Il product Canvas è pensato per essere “esplorato” e “popolato” da sinistra verso destra e, quindi, la prima area che va riempita è quella relativa al “Target Group”, utilizzando l’approccio personas-oriented.

ProductCanvasSteps

Se si riflette un attimo su questa priorità, ci si rende conto che è assolutamente ovvia ed in linea con un approccio Agile/Lean alla creazione di soluzioni IT.

Il secondo passo è quello di riempire la “Big Picture”, descrivendo le Features del prodotto attraverso tutti gli elementi che riteniamo idonei a rappresentarne la Vision. Ben vengano, quindi, user-story, StoryBoard, disegni della UI, ecc. Sono, invece, del tutto banditi elementi specifici dell’attività di implementazione: non troveremo mai: “creare le interfacce di accesso al db”.

Infine, il terzo step, è quello di decide quale feature verrà sviluppata nella prossima iterazione di sviluppo, elencando le relative user-story ed evidenziando eventuali attività atte a esplorare specifiche soluzioni o a ridurre il rischio.

Attenzione però a non interpretare questi step come sequenziali in senso stretto. Dopo la prima formalizzazione (sequenziale), l’intero Product Canvas va incontro a continue review e aggiornamenti, dovuti al know-how di dominio, continuamente aumentato man mano che si procede con il progetto.

Ecco il punto: il Product Canvas è uno strumento di apprendimento che posa la sua essenza sul tanto amato pattern inspect-and-adapt.

ProductCanvasAndLearning3

Product Canvas come strumento di apprendimento (Roman Pichler)

VSO Rest APIs e operator asOf

Ho appena bloggato sul mio Blog Inglese riguardo alle REST APIs ed operatore asOf, ma ritengo l’argomento interessante, per cui voglio postare qui velocemente alcune riflessioni.

Le REST APIs sono molto comode perché permettono di interagire con TFS, soprattutto per quanto riguarda il “prelevare dati” in maniera semplice e veloce. Se siete curiosi riguardo le REST APIs, vi consiglio prima di tutto di guardare l’endpoint che vi permette di  eseguire una query con il Work Item Query Language.

Il Work Item Query Language è una sintassi Sql Like che permette di interrogare il Work Item Store per recuperare le informazioni di cui avete bisogno. Questa funzionalità è FONDAMENTALE se volete recuperare dati sull’andamento del team per fare grafici, report o quant’altro.

Basta effettuare un post a questo endpoint

https://gianmariaricci.visualstudio.com/defaultcollection/_apis/wit/queryresults?api-version=1.0-preview

Utlizzando un Content-Type header di application/json (non lo dimenticate altrimenti le APIs vi restuitiranno errori del tipo “avete dimenticato il parametro QueryId” che difficilmente vi faranno capire dove sta l’errore), potete inviare questa query al Work Item Store.

{ "wiql": "Select [System.Id] FROM WorkItems where 
[System.TeamProject] = 'Experiments' AND
[System.WorkItemType] = 'Bug' AND
[System.State] = 'Proposed'" }

Il risultato è una serie di Work Item Id, ovvero la lista degli id che soddisfano la query. In questo caso io potrei semplicemente essere interessato al conteggio dell’array Json, per capire che ho 13 bug ins tato Proposed nel progetto Experiments.

{
asOf: "2014-07-05T09:52:39.447Z"
query: {
type: "query"
columns: [1]
0:  "System.Id"
-
queryType: "flat"
sortOptions: [0]
wiql: "Select [System.Id] FROM WorkItems where [System.TeamProject] = 'Experiments' AND [System.WorkItemType] = 'Bug' AND [System.State] = 'Proposed'"
url: null
}-
results: [13]
0:  {
sourceId: 108
}-
1:  {
sourceId: 270

Se faccio una query per ogni stato posso creare un grafico, cosa che però mi è permessa nativamente da VSO, per cui dove sta il vantaggio??

image_thumb2

Figure 1: Count of Bugs grouped by state

Il reale vantaggio è il fatto di poter interrogare il Work Item Store in precisi istanti di tempo, infatti la risposta contiene come prima riga il timestamp del momento in cui è stata eseguita la query, che indica il timestamp per cui il risultato è valido.

asOf: “2014-07-05T09:52:39.447Z”

Molti non lo sanno, ma potete usare l’operatore asOf nella query per eseguire la query in un preciso istante temporale, ovvero conoscere il risultato in un determinato momento nel passato. Ecco come fare:

{ "wiql": "Select [System.Id] FROM WorkItems where 
[System.TeamProject] = 'Experiments' AND
[System.WorkItemType] = 'Bug' AND
[System.State] = 'Proposed'
asof '2014-07-04T10:00:00.000Z'
 " }

Come si può vedere dalla risposta sottostante, il risultato è cambiato e la query è stata eseguita in quel particolare timestamp, permettendoci di interrogare il Work Item Store per dirci il suo contenuto in qualsiasi istante di tempo nel passato.

{
asOf: "2014-07-04T10:00:00Z"
query: {
type: "query"
columns: [1]
0:  "System.Id"
-
queryType: "flat"
sortOptions: [0]
wiql: "Select [System.Id] FROM WorkItems where [System.TeamProject] = 'Experiments' AND [System.WorkItemType] = 'Bug' AND [System.State] = 'Proposed' asof '2014-07-04T10:00:00.000Z' "
url: null
}-
results: [16]
0:  {
sourceId: 108

A questo punto potete fare una semplice routine che esegue una serie di query utilizzando asOf per costruire grafici di trend, che non sono ancora disponibili su VSO, o per fare analisi personalizzate sui propri dati.

Il consiglio in questo caso è di creare una routine che interroga VSO per i dati storici e poi salva il risultato in una cache locale, per non dover ogni volta rifare decine di query al vostro account.

Gian Maria.

0  

Visual Studio Update 3 è ora RC

l’Update 3 di Visual Studio e TFS esce dalla CTP ed entra nella fase RC. Le novità sono molte anche nella parte di TFS. Potete leggere alcuni dettagli nel blog di Visual Studio ed in quello di Brian Harry

http://blogs.msdn.com/b/visualstudio/archive/2014/07/02/update-3-release-candidate-for-visual-studio-2013.aspx

http://blogs.msdn.com/b/bharry/archive/2014/07/02/vs-tfs-2013-3-update-3-rc.aspx

Per TFS le novità piu succose sono l’introduzione del Code Lens per I progetti Git, e quindi poter avere Code Lense anche per progetti GitHub, non solamente quelli basati su VSO / TFS. Un’altra interessante novità sono Test Suite e Test Plan che sono rappresentati ora da Work Item e non piu entità separate, infine Release Manager supporta ora il rilascio tramite DSC o Chef.

Happy TFS.

0  

Back to Value, dematerialisation

Come accennato nel post precedente, Back to Value, vediamo ora di sfruttare gli strumenti che comunemente utilizziamo per ottenere una versione “digitale” ed integrata del Product Canvas.

E’ utile fare una premessa: il Product Canvas dà il meglio di se in versione “materializzata”, quindi è opportuno che tutte le discussioni relativi (Inception Meeting, Iteration 0, ecc…) vengano effettuate con un bel Canvas fisico, con tutti gli strumenti tipici. La versione “dematerializzata” è utile per poter conservare in modo più efficace (non la semplice foto!) il lavoro prodotto e consentire di visualizzare i risultati ottenuti anche a stakeholder fisicamente non localizzati nella stessa struttura. Si tratta dello stesso approccio che suggerisco per la Kanban Board.

Ma veniamo all’oggetto del post.

Step 1

Il primo passoè quello di creare/dotarsi di una versione digitale del Product Canvas, realizzato sfruttando PowerPoint, come quello mostrato nella figura seguente:

 ProductCanvasTemplate

Product Canvas PPoint Template

A questo punto, una volta fatte tutte le modifiche opportune, riempito il Canvas e aggiunti gli elementi di Story Board (consigliato), non resta che linkare direttamente il nostro elaborato direttamente a TFS in modo da condividerlo con gli stakeholder di progetto.

Step 2

Sempre in PowerPoint, selezionate “STORYBOARD” dalla Ribbon bar e poi attivate la voce “Storyboard Links”. Si aprirà una finestra simile alla seguente:

productcanvas ppoint 1

Linked Work Item

Step 3

Selezionate “Connect”, scegliete il server TFS di riferimento e il Team Project a cui volete associare il Product Canvas:

productcanvas ppoint 2

TFS Server & Team Project Selection

Step 4

Selezionate il WorkItem a cui collegare il Product Canvas (nell’esempio della figura seguente: “Product Canvas Definition”) e confermate l’operazione:

productcanvas ppoint 3

Scelta Work Item

Step 5

Il linking è avvenuto con successo e non vi resta che chiudere la schermata di riepilogo:

productcanvas ppoint 4

Ripeilogo

Possiamo ora verificare se tutto è andato a buon fine, aprendo VisualStudio Online, selezionando il progetto e visualizzando i dettagli del Work Item “linkato”:

productcanvas ppoint 5

Work Item & Product Canvas linked

Il file deve chiaramente risiedere in una directory condivisa (eventualmente sharepoint) per poter essere accessibile da chiunque e non risiedere sul vostro disco privato.

Bene, a questo punto abbiamo definito il MODELLO, abbiamo creato il TEMPLATE e collegato il tutto a TFS e ora… non ci resta che “disegnare la tela”. Lo faremo, però, nel prossimo post.

{phocadownload view=file|id=16|text=Scarica il template per Power Point|target=s}

Aggiornamento VSO 1 luglio

Nel nuovo aggiornamento di Visual Studio Online del primo luglio abbiamo alcune interessanti novità. La prima riguarda la possibilità di decidere se visualizzare o meno nel backlog gli elementi che sono “In Progress”.

Ma la modifica che preferisco è la possibilità di avere il full-screen nella Kanban Boards e nel backlog. La possibilità di eliminare tutte le informazioni non necessarie e mostrare solamente le board nella loro interezza le rende ancora piu adatte ad essere mostrate in uno schermo touch.

image

Un’altra importante modifica è infine la possibilità di avere Service Hooks e REST APIs per le pull request in Git, a dimostrazione che le REST APIs sono si, ancora in preview, ma sono cittadini di prima classe, perchè rappresentano un modo semplice e facile per accedere ai dati di TFS da ogni device.

Gian Maria.

0  

Back to Value!

Nel nostro percorso di scoperta dell’Agile abbiamo parlato di DAD, SAFe, TFS e tanto altro, ma dopo aver presentato metodologie e strumenti, è utile fare un esercizio mentale che ci riporti a quello che è l’obiettivo fondamentale dell’Agile/Lean: creare Valore per tutti gli stakeholder, noi compresi, coinvolti nel processo di sviluppo.

Si tratta, in pratica, di focalizzare cosa stiamo realizzato, per chi lo stiamo facendo e quali sono i risultati che ci attendiamo.

Un metodo particolarmente efficace per esplicitare questi elementi è l’utilizzo di un Product Canvas, che permette di guidare il processo di creazione di un prodotto (o una release) evidenziando in modo diretto: User Stories, Personas, Storyboard, Scenari, Design Sketches e ulteriori artefatti ritenuti rilevanti.

Un tipico Product Canvas è quello riportato nella figura seguente:

SampleProductCanvas

Tale esempio è basato sulla “Product Canvas Structure”, proposta da Roman Pichler:

ProductCanvasStructure

In esso sono ben evidenti:

  • Name: semplicemente il nome, ed eventualmente la versione, del progetto;
  • Goal: si tratta del motivo stesso d’essere del prodotto/progetto, ovvero degli obiettivi primari;
  • Metrics: esplicita i parametri che consentono di “misurare”i Goal al fine di valutare il raggiungimento degli obiettivi;
  • Target Group: descrive i diretti destinatari del prodotto/progetto. Tipicamente tali attori vengono descritti come Personas, ovvero sotto forma di archeo-tipi che descrivono le caratteristiche dei potenziali utilizzatori. (delle Personas parleremo prossimamente);
  • Big Picture: è la parte più corposa del Product Canvas, in cui vengono descritti gli elementi portanti del progetto steso. In esso ritroviamo: Epic/Feautures, Mock-up della UI, Story Board, e i constraints a cui attenersi (es: req. non funzionali). In particolare è possibile definire il “journey” delle singole Personas, intersecando i vari elementi e creare quello che è il flusso di utilizzo tipico relativo. Questo aspetto è particolarmente interessante perché permette rapidamente di raggiungere “l’ottimo”, effettuandone continue review, rapide e sempre visibili all’interno Team di delivery;
  • Product Details: contiene i goal previsti per la prossima iterazione e i relativi item per raggiungerli, nonché quelli per gestire il rischio, per l’acquisizione di nuovo know-how, e similari. In generale possiamo immaginare di avere in quest’area una elenco di User Story, opportunamente priorizzate e con i relativi test di accettazione: un po’ come se fosse il Backlog di iterazione.

Sebbene il Product Canvas dia il meglio di se in formato “fisico” (carta, post-it, disegni, ecc…) possiamo pensare di utilizzare il nostro amato PowerPoint per realizzarne una versione digitale, al fine di integrarlo con la relativa funzionalità di Story Board e, più importante, collegarlo in modo diretto al nostro Team Project TFS per le attività di sviluppo.

Nel prossimo post presenteremo un approccio pragmatico per popolare il nostro Product Canvas digitale, fornendo anche un template base di riferimento.

Aiuto: Il database di TFS è diventato grandissimo

Una delle operazioni che vanno effettuate periodicamente sul proprio TFS on-premise è il controllo del data layer per evitare alcuni fastidiosi problemi.

Il primo problema è finire spazio su disc;, problema che tipicamente accade quando non sono effettuati I backup del database e per questo il file del transaction log cresce a dismisura. Dato che avere I backup del proprio server non è opzionale ma necessario, questo primo problema si risolve semplicemente schedulando un backup dalla apposita console.

image

E’ comunque possibile che la dimensione del proprio database diventi notevole nel corso del tempo, e se da una parte questo è abbastanza normale per l’inevitabile crescita della mole di dati gestiti, ci sono alcune operazioni che possono essere fatte per evitare di tenere spazio occupato da dati inutili.

Tra i dati che possono occupare molto spazio e possono essere cancellati senza troppi problemi vi sono i test attachment, generati da Microsoft Test Manager o dall’esecuzione dei test automatici. I power tools contengono quindi un tool, chiamato Test Attachment Cleaner che vi permetterà di capire sia quali set di attachment stanno occupando spazio, sia liberare spazio cancellando gli attachment che non sono piu per voi rilevanti.

Un’altra tabella che tende a crescere molto è la tbl_localVersion, che talvolta può arrivare ad avere molti GB. Questa tabella è usata da TFS per tenere traccia dello stato dei file nei vari workspaces quando si utilizza TFVC. La crescita continua di questa tabella avviene spesso perché non viene mai fatta pulizia dei workpsace non piu utilzzati. Esempio tipico sono: workspace di sviluppatori non più presenti in azienda oppure workspace su computer che sono stati dismessi o formattati.

In questo caso il consiglio è usare uno strumento chiamato Team foundation Sidekick che permette con una comoda GUI di cercare I workspace non piu utilizzati e di cancellarli. Questa operazione può comodamente essere fatta da linea di comando, ma usare una GUI è sicuramente più semplice e funzionale. Vi consiglio di fare periodicamente un controllo sui workspace non piu usati da molti mesi, dato che stanno li ad occupare inutilmente spazio nel vostro DB.

Gian Maria.

Comments Off