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.

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.