Author Archives: Gian Maria Ricci

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.

0  

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.

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 […]

0  

I prezzi per le build e per I Load test in VSO sono usciti

Brian Harry aveva già annunciato alcune settimane fa una differenza al pricing per Build e Load Testing in VSO. Vi invito a leggere il suddetto post per i dettagli e ricordate che per ora le uniche modifiche che sono attive sono quelle che Brian ha annunciato oggi in questo post. Con la modifica ora le […]

Comments Off  

Aggiornamento bug di sicurezza per bug in Git

Oggi è stato pubblicato da Brian Harry un post che parla di una vulnerabilità in Git che permette, nel peggiore dei casi, di eseguire codice sulla macchina di uno sviluppatore. Il post in questione è questo Git vulnerability with .git\config La vulnerabilità è stata corretta in tutte le versioni di TFS e di Visual Studio, […]

Comments Off  

Update pre-natalizi

Potete leggere online le novità di Visual Studio Online relative all’update del 2 dicembre. Di tutte le novità, probabilmente la piu interessante è che, installando la versione del client di Release Manager Update 4, è ora possibile connettere Release Management al proprio account VSO per effettuare il deploy su azure. Come sempre il deploy non […]

Comments Off  

Perché non posso cancellare un Test Plan con TFS2013 Update 3

Se avete aggiornato TFS 2013 con update 3 o successivi ed usate Microsoft Test Manager, probabilmente vi sarete accorti che non più possibile cancellare un Test Plan da MTM. La ragione è da ricercarsi nella modifica introdotta con Update 3, che trasforma i Test Plan in Work Item veri e propri. In TFS non è […]

Comments Off  

Quel vecchio avido di SQL Server

Oggi ho incontrato un problema abbastanza fastidioso configurando un build controller in TFS. L’errore era generato dall’impossibilità di attivare un servizio WCF nell’AT per mancanza di memoria RAM libera. Questo porta ad una regola generale da applicare se avete un TFS a singola istanza, dove SQL Server e AT condividono la stessa macchina. Se seguite […]

2  

Quando faccio git push quali branch sto pushando?

Lavorando in command line in Git si potrebbe erroneamente pensare che facendo un

git push

Si effettui il push della sola branch che è in checkout, ma questo non è vero, dato che il reale comando per effettuare il push di una branch è

git push remotename branchname

Quindi se state nella branch XYZ ed avete un  unico remote chiamato origin dovete fare

git push origin XYZ

Il comportamento adottato da git se non specificate ne il remote ne la branch è determinato dalla impostazione push.default e come possiamo leggere dalla documentazione le possibilità sono.

nothing – do not push anything.

matching – push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default.

upstream – push the current branch to its upstream branch.

tracking – deprecated synonym for upstream.

current – push the current branch to a branch of the same name.

Il default è matching, per cui facendo un git push state effettuando il push di tutte le vostre branch. Questa opzione probabilmente non è il miglior default che si possa avere, per questo in Git 2.0 il default verrà modificato in “Simple”, un ulteriore nuovo possibile valore per push.default:

simple – in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch’s name is different from the local one. When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners. This mode has become the default in Git 2.0.

Fate quindi attenzione al modo che avete selezionato per evitare sorprese.

Gian Maria.