Author Archives: Gian Maria Ricci

Definition of Done nella Kanban Board di VSO

Negli ultimi aggiornamenti di VSO abbiamo potuto notare alcune importanti migliorie nella Kanban Board, che onestamente era stata un po’ trascurata negli ultimi tempi.

Kanban Split Column

Novità di VSO Sprint 79

Nel secondo post avevo promesso di approfondire il concetto di Definition Of Done in Kanban, perché è di fondamentale importanza per gestire al meglio il processo. Per prima cosa, fin dagli albori del template SCRUM, in TFS/VSO si può trovare il campo Acceptance Criteria per i Product Backlog Item e le Feature.

image

Dal punto di vista prettamente agile, l’acceptance criteria rappresenta l’insieme dei criteri da soddisfare affinché la singola Card/PBI sia considerata completa a tutti gli effetti quindi, essa rappresenta la Definition of Done della singola card/PBI. Il problema è come declinare questa informazione dal punto di vista di una Kanban Board.

Sicuramente tutti i criteri che si trovano nella card/PBI debbono essere necessariamente soddisfatti prima che la card finisca nell’ultima colonna. Questa condizione è sicuramente intuitiva, ma visto che non vorremmo lasciare nulla al caso, possiamo utilizzare la nuova funzionalità di supporto alla Definition Of Done nella Kanban Board di VSO per rendere questa politica esplicita.

SNAGHTML12b0967

Come si può vedere, ogni colonna, tranne la prima e l’ultima, hanno la possibilità di editare la Definition Of Done. In realtà la posizione logica migliore per questa informazione sarebbe tra due colonne, in modo da rappresentare la barriera che determina le condizioni affinché una card possa essere mossa alla colonna successiva. In questo caso invece, essendo la DoD sulla singola colonna, essa rappresenta le condizioni da soddisfare affinché una card in quella colonna possa essere considerata come Done e quindi promuovibile alla colonna successiva.

Andando ad editare la Definition of Done della colonna Testing, possiamo esplicitare la condizione precedente, ovvero che per essere considerata DONE una card deve avere tutti gli Acceptance Criteria soddisfatti.

image

Ora sulla colonna si può una nuova icona con un piccolo punto esclamativo. Cliccandoci sopra si può vedere le DoD di quella specifica colonna.

image

Di base quindi l’acceptance criteria rappresenta la DoD della singola card, ma in Kanban esiste una DoD per ogni colonna, che vale comunque per tutte le card indipendentemente dalla acceptance criteria.

Questa funzionalità è molto utile per esplicitare in maniera chiara il livello di qualità che ci si attende prima di considerare completa una card. Nulla infatti rallenta il flusso come il dover riportare una card allo stato precedente perché si è dimenticati qualcosa. Un esempio tipico potrebbe essere quello di avere il codice pronto per andare in produzione, ma accorgerci che lo schema del nostro DB SQL è cambiato e gli sviluppatori hanno dimenticato di creare gli script di migrazione. In questo caso è evidente che è necessario aggiungere una condizione nella DoD della colonna Developing.

Per chi usa la Kanban Board su VSO, non dimenticate quindi di esplicitare tutte le condizioni di transizione, ricordate infatti che uno dei principi di Kanban è: Make Process Policies Explicit e la Definition Of Done è sicuramente una delle Policy più importanti dei processi agili.

Gian Maria.

Introduzione a Kanban su MVA ora online

Per chi fosse interessato è oggi online il corso su Microsoft Virtual Academy sul metodo Kanban, fatto da me dal caro amico Felice.

Trovate tutto qui.

http://www.microsoftvirtualacademy.com/training-courses/introduzione-a-kanban

Buona visione Smile.

Dove finisce la Kanban Board ed inizia il Feedback

,Nel precedente post ho continuato la dissertazione sul massimizzare il flusso, ed ho spiegato come sia fondamentale estendere la Kanban Board a più stadi del processo possibili. Lo scopo finale è visualizzare tutti i passi che portano *dall’idea ai guadagno*. In un sistema software quindi dovremmo avere come ultima colonna un qualche cosa simile a: […]

0  

Dove finisce la Kanban Board ed inizia il Feedback

Nel precedente post ho continuato la dissertazione sul massimizzare il flusso, ed ho spiegato come sia fondamentale estendere la Kanban Board a più stadi del processo possibili. Lo scopo finale è visualizzare tutti i passi che portano *dall’idea ai guadagno*. In un sistema software quindi dovremmo avere come ultima colonna un qualche cosa simile a: Usabile in produzione dal cliente finale. 

La domanda principale è: Usabile dal cliente finale significa guadagno?

In parole povere, il fatto che una determinata feature/card sia in produzione, è condizione spesso necessaria, ma non assolutamente sufficiente affinché inizi a generare guadagno. In questo caso quindi, anche se abbiamo massimizzato il flusso grazie alla nostra Kanban Board, non ci stiamo necessariamente avvicinando al Goal. Quello che viene spesso trascurato nell’implementazione del metodo Kanban è il considerare la metrica probabilmente più importante dei processi agili: IL FEEDBACK!!!!

L’aspetto interessante è che, si è tentato per anni di mutuare tecniche di progettazione da altre branche dell’ingegneria all’informatica (vedi il waterfall) ed il successivo fallimento di molti di questi tentativi ha generato un assioma di questo tipo:

Essendo il sistema waterfall mutuato da un altra branca dell’ingegneria, è possibile che mal si adatti all’informatica. Ergo è piuttosto inutile cercare di adattare metodologie di progetto da altre branche dell’ingegneria, perché l’informatica è troppo differente.

Questa affermazione è sempre vera? Venendo da studi di Elettronica, per me è naturale che un sistema di controllo per essere stabile debba necessariamente usare il principio del feedback.

Ora consideriamo che: il metodo Kanban è un sistema di controllo, il cui scopo è monitorare l’avanzamento dall’idea al prodotto finito grazie alla Board. A questo punto io sono fermamente convinto che:

Uno degli errori maggiori in Kanban applicato ad un progetto software è credere che il flusso finisca una volta raggiunta l’ultima colonna, ignorando per questo il feedback!!!!

Se grazie a Kanban abbiamo aumentato di molto il flusso di produzione (software o manifatturiero, …), ma nel contempo abbiamo una qualità scadente, siamo ben lontani dal Goal, a meno che il Goal non sia avere orde di clienti insoddisfatti (o di vendere contratti di assistenza).

In questo particolare caso l’ingegneria dei controlli e dell’automazione ci viene in aiuto, perché il modo migliore per capire se il prodotto del nostro processo è valido e di qualità, è acquisire FEEDBACK!.

Nei prossimi post vedremo quindi che tipologia di feedback utilizzare e come integrare questo processo in Kanban.

Gian Maria.

Kanban Board – Massimizzare il flusso

Come accennato nel post precedente sulle Split Columns della Kanban Board in VSO, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è:

Maximize Throughput while Minimizing Inventory and Operating Expense.

In questo post vorrei fare una precisazione sul concetto di Flusso e Throughput, di centrale importanza per il metodo Kanban. Se avete letto The Goal sapete benissimo che uno degli scopi principali di una azienda è fare soldi, punto! Sembra cinico, ma senza un flusso di cassa costante, potete avere delle idee bellissime, essere innovativi, brillanti, ma sicuramente avrete difficoltà nel realizzare le vostre idee.

Nel software, quando andiamo a declinare il metodo Kanban, che ricordo essere nato in un contesto manifatturiero (Toyota), bisogna capire cosa intendiamo con il termine throughput. Facciamo però prima un semplice ragionamento in ambito manifatturiero, pensando ad una azienda che produce elettrodomestici. Supponiamo che la azienda usi Kanban, il flusso sia ottimale e le linee di produzione lavorino in maniera efficiente, i colli di bottiglia sono stati individuati, etc etc.

La domanda interessante che ci si deve porre è questa: se si vuole massimizzare il flusso dell’azienda, bisogna definire in maniera inequivocabile quale sia lo stato finale della nostra Kanban board, altrimenti rischiamo di non trovare colli di bottiglia. Facciamo un esempio in cui consideriamo come ultima colonna della Kanban lo stato “imballato”, che identifica quando il nostro elettrodomestico è stato imballato e pronto per la vendita.

Possiamo da subito capire che probabilmente questo non è corretto, se per qualche ragione il nostro magazzino non è efficiente, rischiamo di accumulare prodotti in magazzino senza essere in grado di farli pervenire ai distributori. In questo modo, se il magazzino è il collo di bottiglia, esso non verrà individuato, e ci accorgeremo dei problemi quando gli elettrodomestici “imballati” non hanno più posto dove essere stoccati.

Ok! Per risolvere consideriamo come ultima colonna Kanban una nuova colonna chiamata immagazzinamento, in questo modo se il magazzino diventa saturo, essendo Kanban un metodo pull, le linee di produzione dovranno fermarsi, dato che il magazzino non è più in grado di accettare pezzi. Anche in questo caso, se in alcuni periodi dell’anno quel tipo di elettrodomestici si vede di meno (frigoriferi in inverno), rischiamo di riempire il magazzino perché i grossisti non hanno bisogno di nuova merce.

Piano piano ci si rende conto che idealmente, l’ultima colonna Kanban per la nostra azienda fittizia, dovrebbe essere “venduto al cliente”. Ora è chiaro che ragionare in questi termini è decisamente difficile, ma se nel nostro monitoraggio del processo non consideriamo che il nostro elettrodomestico deve essere venduto ad un cliente finale, si rischia di non vendere, non fare soldi, e fallire.

Tornando quindi al concetto iniziale: Throughput!! Se seguiamo le indicazioni di Goldratt, dobbiamo accertarci che quando parliamo di flusso, stiamo includendo tutti gli stadi fino a quello che ci permette di fare soldi per far vivere l’azienda!

Cosa implica questo in Kanban applicato ai processi software? Che nella nostra Kanban Board, l’ultima colonna deve essere, per lo meno, Usabile in Produzione, ovvero il software deve essere rilasciato e disponibile al cliente finale. Se ci dimentichiamo di questo, rischiamo di accumulare una grande quantità di lavoro “finito” ma che non è usabile dal cliente/utente finale, e che quindi non può generare soldi.

Ricordate quindi che in Kanban la massimizzazione del flusso è fondamentale ed è altrettanto fondamentale che nel flusso si considerino tutti gli stadi, dall’idea alla produzione!

In realtà nemmeno questo alla fine è realmente sufficiente e capiremo perché nel prossimo post.

Gian Maria.

0  

TFS2015 Build vNext

Nel lontano 2010, TFS2010 introduceva una nuova build, basata su Workflow Foundation, la quale andava a rimpiazzare la vecchia build di TFS 2008 basata su script MSBuild.

Personalmente debbo dire che ho sempre preferito la vecchia versione del 2008, soprattutto per la facilità di estensione. Mentre per Workflow Foundation è necessario usare Visual Studio ed addentrarsi in un designer non proprio semplice, personalizzare una build MSBuild è una operazione piuttosto semplice, alla fine si tratta solamente di file xml.

Chiaramente XML non è il linguaggio migliore per creare uno script, per cui nel corso degli anni molte persone hanno abbandonato questa strada a favore di Powershell, sicuramente più flessibile ed estendibile. Una build infatti non è altro che una sequenza, quasi sempre lineare, di operazioni da eseguire partendo dai propri sorgenti per ottenere dei risultati (build, test, deploy, etc) e quale migliore scelta dell’esecuzione di una serie di script PowerShell per definire una build?

Per questa ragione in TFS2015 la build è stata nuovamente modificata, per adattarsi a queste nuove richieste e sicuramente risolverà molti problemi emersi negli anni passati con l’attuale struttura di build. Dedicherò quindi una serie di post alle novità della build, cosi da potervi mostrare cosa ci aspetta nella prossima versione di TFS.

Build web experience

La novità più succosa e la prima che amo descrivere, è che tutta la configurazione e la gestione della build è completamente web. Niente più necessità di Visual Studio per editare una build, basta andare nella nuova voce di menu Build vNext e potrete gestire tutto dal vostro browser preferito.

image

Premendo il bottone per aggiungere una build viene subito presentata una possibile scelta tra due template già pronti, uno per una solution di Visual Studio, ed un altro per eseguire la build di Xcode.

image

Fin da subito possiamo quindi vedere che l’altra grande novità riguarda il fatto di poter avere agent di build che girano anche su macchine non Windows. La configurazione degli agent sarà appannaggio del successivo post, per cui non ci soffermeremo ora su questo aspetto.

Se scegliamo la build di Visual Studio si aprirà un editor web da cui si può configurare ogni aspetto della build.

image

Il primo tab da impostare è quello del Repository in cui basta selezionare repository git che volete utilizzare. Per questa CTP ancora è possibile solamente eseguire build vNext su team project basati su Git, nella versione finale si potrà usare anche TFVC.

image

La cosa interessante è che si può usare la build vNext per compilare qualsiasi repository git, anche su gitHub se necessario. La default Branch indica quale è la branch che verrà compilata di default per le build accodate manualmente.

Il successivo tab sarà quello dei Triggers, su cui si può indicare se si desidera la Continuous Integration (build ad ogni change), se si vuole accorpare più commit in un unica build (Batch changes) e chiaramente la possibilità di specificare tutte le branch che si vogliono monitorare, ad esempio in questo caso ho chiesto di monitorare ogni branch che comincia per feat-.

image

Una volta impostato il repository, si può direttamente fare il browsing da web per scegliere la o le solution che si vogliono compilare.

image

Nel tab dei test basta introdurre una regular expression che identifica gli assembly di test ed il gioco è fatto. Se si vogliono eseguire test differenti da MsTest, si hanno due scelte, la prima è specificare il percorso relativo dove trovare i test adapters, operazione che potete effettuare direttamente nelle opzioni del task di test.

image

Se invece usate nunit in tutti i vostri progetti e si vuole evitare di personalizzare ogni build di ogni progetto, si può andare nelle macchine dove è installato l’agent, aprire la cartella dove è localizzato il test runner di visual studio e copiare al suo interno i test adapters dopo averli scaricati dalla gallery di Visual Studio.

image

A questo punto si è creata una build minimale che esegue Build e Test run, interamente da interfaccia web con pochi semplici click. Se nell’installazione di TFS 2015 avete scelto di configurare il build agent automaticamente, potete direttamente lanciare una build e verificare che sia tutto ok.

image

Come si può vedere la build viene eseguita e potete verificarne l’output ed il progresso direttamente dall’interfaccia web.

Gian Maria.

Novità di VSO Sprint 79

Come sempre potete leggere tutte le novità sul blog di Visual Studio Online, precisamente a questo indirizzo, ma per chi si fosse perso il post, ecco le novità che sono ora disponibili. In questo sprint il team si è focalizzato nel risolvere alcuni issue di UserVoice che hanno un numero elevato di voti e che sono quindi sentiti come molto importanti da parte della community. Questo significa che, come sempre dico a tutti, il team legge i suggerimenti di User Voice, per cui se qualche cosa non vi soddisfa, quello è il posto migliore per dare i vostri suggerimenti.

Finalmente, dopo tanto tempo, ecco arrivare il parametro @currentIteration, che vi permetterà di fare delle query sui Work Item assegnati alla iterazione corrente. Purtroppo questo parametro non funziona in Excel.

Le novità più importanti riguardano però la Kanban Board, la quale supporta ora il riordinamento delle card, operazione molto importante per la prima colonna, che rappresenta il BackLog.

La modifica più importante è però l’introduzione della Definition of Done per le colonne della Kanban Board. Tornerò sull’importanza di questa funzionalità in un successivo post.

Un’altra importante aggiunta è la possibilità di visualizzare i bug come task nella Taskboard e considerarli logicamente figli dei vostri requisiti.

Come potete vedere il team di Visual Studio ALM continua, sprint dopo sprint, a migliorare il prodotto.

Happy VSO.

Gian Maria.

Comments Off  

Kanban Split Column

Finalmente in Visual Studio Online sono stati introdotti alcuni miglioramenti alla Kanban Board, che per lungo tempo era stata lasciata senza sensibili miglioramenti. In questo ultimo update di VSO è stato introdotto una funzionalità realmente fondamentale, che aumenta di molto la possibilità di usare realmente la Kanban Board in TFS/VSO.

Il cambiamento di cui sto parlando è l’introduzione delle Split Columns, ovvero la possibilità di suddividere ogni colonna in due sotto-colonne, rispettivamente Doing and Done. Vediamo il perché questa funzionalità è cosi importante.

Si parte da un presupposto: Kanban è un processo PULL, in cui ogni stadio decide di prendere in carico una card dallo stato precedente, se e solo se non ha raggiunto il suo limite e se tutte le regole sono soddisfatte (regole aggiuntive e Definition of Done). Questo è il segreto e la base su cui poggia Kanban, ogni stadio inizia a lavorare su un task solamente se ha modo di farlo. Questo viene fatto per evitare ingorghi nel processo e per massimizzare il flusso. Lo strumento principale di Kanban è la Board, che deve permettere immediatamente di individuare i problemi affinché il team possa affrontarli.

Ora analizziamo la situazione seguente:

image

La situazione rappresentata ci dice che: le colonne di Analysis e Committed sono attualmente piene (3/3), quindi non è possibile aggiungere del Work In Progress a nessuna delle due colonne. La domanda che ci si pone è: lo stadio di Analysis non può prendere in carico nessun nuovo item, ma i tre item che sono attualmente nella colonna sono stati terminati o no?

La risposta alla domanda precedente è di fondamentale importanza. Supponiamo i due casi estremi. Caso A: i tre item nella colonna Analysis sono tutti “in progress” questo significa che la colonna Analysis è in stato di pieno regime. Caso B: i tre item nella colonna Analysis sono completati e pronti per lo stadio successivo, questo significa che la colonna Analysis è paralizzata, dato che non può prendere in carico nuovo lavoro fino a che la colonna successiva (Committed) non prende in carico ancora del lavoro. Purtroppo dalla Kanban Board precedente è impossibile discernere i due casi.

Senza entrare nei dettagli, stiamo toccando quella che è chiamata teoria delle code che stabilisce modelli matematici per predire l’avanzamento in una catena di processi. L’identificazione delle code è fondamentale in Kanban, ed è una delle ragioni principali per l’adozione stessa del metodo.

Il metodo Kanban ha come scopo la massimizzazione del flusso ed in questa ottica l’individuazione delle code è un’operazione di massima importanza.

D’altra parte, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è: Maximize Throughput while Minimizing Inventory and Operating Expense. La declinazione nello sviluppo software non appare sempre semplice, se da una parte è chiara la parte di minimizzare le Spese (Operating Expenses), si può anche intuire la massimizzazione del flusso (Maximize Throughput, concetto su cui tornerò in un post successivo), è difficile capire come minimizzare lo stoccaggio (Minimizing Inventory), dato che alla fine il codice non occupa spazio :).

Kanban ci aiuta a rispondere a questo problema adottando la tecnica dello split column. Nel nostro account VSO, se premiamo il Customize column troviamo una nuova opzione per le colonne.

image

Quello che accade è che ogni colonna viene ora suddivisa in due sotto-colonne, Doing e Done; questo ci permette di iniziare ad individuare le code nel nostro sistema. Vediamo allora come sarebbero rappresentati i due casi precedenti adottando questa nuova funzionalità. Il CasoA: sarebbe cosi rappresentato

image

è chiaro che il sistema sta larvando bene, tutte le colonne sono impegnate e a pieno regime. Il CasoB avrebbe invece una rappresentazione molto differente.

image

Si è creata una coda tra gli stati di Analysis e Committed, dato che abbiamo la colonna Analysis bloccata dal fatto che il lavoro nella colonna Committed non sta proseguendo, per questo non vengono prese in carico (pull) le card terminate in Analysis e questo fa si che la colonna Doing di Analysis sia vuota e bloccata. Tutte le card che sono nella colonna Dona rappresentano infatti card in Coda per lo stadio successivo e possono essere paragonate a quello che Eliyahu Goldratt chiama Inventory in “The Goal”.

Se siamo d’accordo che è necessario minimizzare le code ed evitare che il lavoro si accumuli nelle colonne “done”, senza questa funzionalità, è impossibile capire dalla nostra Kanban Board se siamo nel CasoA oppure nel CasoB e si perde una informazione di vitale importanza.

Un altro valore secondario dello split column è permettere in maniera semplice allo stadio successivo, di capire quali card dello stadio precedente possono essere prese in carico. Senza la colonna Done infatti, quando si libera uno spazio nella colonna Committed, non è ben chiaro dalla Board quali card dello stadio precedente (Analysis) possono essere prese in carico, perché non si ha la distinzione tra ciò che è in corso d’opera e ciò che invece lo stadio precedente ha completato.

Gian Maria.

Comments Off  

Some love to Kanban Board in TFS

Nell’ultimo update di VSO che è stato effettuato ieri (http://www.visualstudio.com/news/2015-feb-18-vso) sono finalmente state fatte importanti modifiche alla Kanban Board, che era rimasta un po ferma da troppo tempo a mio avviso.

La prima novità è che è possibile aggiungere gli item direttamente dalla board, ma sicuramente la funzionalità piu succosa è la divisione delle colonne in doing e done. Non starò qui a sottolineare l’importanza di questa funzionalità, dato che senza la possibilità di capire quali Item sono realmente fatti e sono pronti per essere presi (pull) dalla colonna successiva, la Kanban board ha poco valore.

Nell’upgrade vi sono anche altre novità, tra cui la possibilità di assegnare piu persone alle test suites, e l’annuncio che le funzionalità di Application Insights saranno migrate nel nuovo portale di azure. Il nuovo link di riferimento per Application Insights è quindi il seguente: http://azure.microsoft.com/en-us/services/application-insights/

Happy VSO e buon fine settimana. Smile

Code search–In preview su VSO

Il blog di VS ALM ha appena pubblicato questo post in cui viene mostrata una nuova funzionalità, ancora in limited preview, presente su Visual Studio Online, il Code Search.

In un progetto è spesso di vitale importanza poter effettuare una ricerca nel source control, alla ricerca di una particolare porzione di codice, oppure di una classe con un particolare commento, etc. Le nuove funzionalità di ricerca introdotte in VSO permettono infatti di effettuare una ricerca semantica, in cui I risultati vengono suddivisi in base alla porzione di codice dove viene effettuato il match. Ad esempio I risultati ci permettono di dire se il testo cercato è presente in un commento, oppure in una dichiarazione di classe Etc.

E’ anche possibile andare a richiedere direttamente un filtro per restringere lo “scope” della ricerca, Es: class: per ricercare nelle dichiarazioni di classe, oppure comment: per cercare all’interno di un commento. La lista completa è presente nel post del blog sopracitato e la riporto per comodità.

image

Attualmente, data la natura di preview di questa funzionalità, esistono delle limitazioni. Il servizio è disponibile solamente per gli account del Nord America, e per progetti che utilizzano Git; la ricerca viene inoltre fatta solamente nella master branch ed il supporto ai linguaggi è per ora disponibile per C#, C e C++.

Gian Maria.