Tag Archives: kanban

Live update nella Kanban Board in VSTS

Una delle ultime novità per la Kanban Board in VSTS offre la possibilità di abilitare il “live update” per la board, attivabile selezionando una semplice icona a fianco delle impostazioni.

image

Figure 1: Icon to enable live update to Kanban Board

Una volta abilitata, la board rifletterà in tempo reale ogni cambiamento dei work item che sono rappresentati nella board stessa. Questo significa che modificando o riordinando o cambiando colonna o in generale modificando qualsiasi proprietà di un Work Item da qualsiasi sorgente (web, Visual Studio, Integratione con Excel, etc), i cambiamenti si rifletteranno immediatamente nella board.

Questa possibilità è interessante in accoppiata con la visione in full screen (l’icona a destra dei settaggi), che permette di visualizzare la board a pieno schermo. Questa funzionalità, assieme al Live Update, permette di mettere un monitor o televisione che mostra sempre in tempo reale la situazione della board.

Questa funzionalità è per ora solamente disponibile per VSTS.

Gian Maria.

Visual Studio Online, deploy del 18 settembre

Anche in questa versione, molte delle novità riguardano la Kanban Board, che, deploy dopo deploy, diventa uno strumento sempre più interessante. Se una User Story è scomposta in Task, vedrete un sommario dei task direttamente nella task.

image

In questo caso la User Story ha due task, entrambi non completati. L’aspetto interessante è che cliccando sul sommario si apre una visione di dettaglio, che vi permette di aggiungere task e di marcare i task come completati.

image

Se si utilizza Kanban la scomposizione in task non ha la stessa valenza di Scrum, dove il team assegna le ore ai vari task per tracciare il Burndown chart, ma i task hanno più una valenza di Checklist, ovvero le “cose da fare”. Per questo nella Kanban board vedrete solamente i titoli dei task, e selezionando la checkbox, il task verrà direttamente portato dallo stato “to do” allo stato “Done”. Questa funzionalità è particolarmente interessante perché permette una sottodivisione delle card più impegnative, (ad esempio le XL se usate il T-Shirt sizing). Non viene richiesto di fare stime o di assegnare i Task, sebbene voi possiate farlo; per cui la scelta del dettaglio sul come gestire i task è lasciata al team, e la board vi darà una visione comunque più corretta ed allineata. Sapere infatti che 8 su 10 task di una card XL sono completati vi da una migliore predittibilità di quando la card potrà essere Mossa nella colonna successiva.

image

Mentre per le storie di piccola entità il team può trovare inutile scomporre in Task, per quelle più impegnative questa funzionalità diventa decisamente interessante, perché permette di avere una idea migliore delle cose che rimangono da fare.

La funzionalità decisamente più interessante di questo deploy è sicuramente la possibilità di utilizzare le colonne custom della Kanban board nelle query di TFS, una funzionalità che è stata richiesta da moltissimo tempo da un nutrito gruppo di utenti.

image

Finalmente è quindi possibile creare query che filtrino tutte le card in base alla colonna di appartenenza. Attenzione agli operatori <, >, >=, etc, perché di primo impatto potreste pensare che con un operatore > (Maggiore) la query vi ritorni solamente le card presenti in colonne a destra della colonna usata come filtro. Purtroppo il risultato è che vi verranno restituite tutte le card presenti in colonne il cui nome, inteso come stringa, sia maggiore del valore selezionato. Volendo è possibile utilizzare questa funzionalità chiamando le colonne (1_analysis, 2_ developing) etc.

E’ infine possibile utilizzare anche i filtri “Board column Done”, che vi permette di specificare se la card deve trovarsi nella colonna Done o Doing (nel caso utilizziate le splitted columns) e la possibilità di filtrare per Swimlane. In questo modo potrete creare query per estrarre dati e fare facilmente report sullo stato della vostra board.

image

Le altre modifiche di questo sprint riguardano la possibilità di effettuare operazione di Drag And Drop nella board per cambiare il parent di un Work Item, poter effettuare il drag in una interazione con elementi multipli e fare il Move to Top and Move to Position con elementi multipli selezionati.

Per quanto riguarda le pull request di Git, è ora possibile impostare una policy per cui non è possibile effettuare una pull request se non vi è un Work Item assegnato e bloccare la merge se non esiste un work item assegnato.

Infine è ora possibile esportare anche il risultato dei test nel Test Hub.

Nel post relativo del blog di VisualStudio.com trovate tutti i dettagli.

Happy VSO

Kanban Board e Swim lanes

Nell’ultimo update di Visual Studio online è stata introdotta una nuova migliora per la Kanban Board, ovvero l’implementazione delle Swim Lanes. In una Kanban Board infatti la suddivisione in colonne permette di visualizzare immediatamente il “work in progress” per tutti gli stadi di sviluppo, ma nelle varie colonne non esiste differenza nella priorità delle card. Questo significa che se nella colonna Testing vi sono 4 card una sotto all’altra non implica, come per un backlog, che le card in alto sono in qualche modo più importanti o prioritarie delle altre.

In alcune situazioni è però comodo poter dare priorità ad alcune card, indicando appunto che il team deve in qualche modo focalizzarsi nel fare avanzare alcune card rispetto ad altre. Un esempio pratico potrebbe essere costituito da una card che rappresenta un bug bloccante in produzione. Quando si verifica un bug bloccante in produzione, molto probabilmente tutto il team deve collaborare per far si che il bug sia corretto nel minor tempo possibile e quindi la card (o le card) che sono collegate al bug debbono avanzare con priorità rispetto alle altre.

Per visualizzare in maniera chiara ed evidente questo fatto, è comodo avere nella board delle suddivisioni orizzontali, in modo da suddividere la board in più fasce orizzontali. In realtà la fascia principale, rimane la board come la si conosce, mentre le fasce aggiuntive sono appunto dette Swim Lanes e servono appunto a raccogliere particolari card che debbono essere gestite con priorità differente rispetto al resto.

image

Nella swimlane le colonne sono esattamente le stesse della board principale, dato che ogni card ha comunque un percorso ben definito nella vostra organizzazione. In generale la visualizzazione normale della board può mantenere la SvimLane collassata, dato che appena qualcuno vi sposta dentro un item è possibile comunque visualizzare nell’header quante carte sono presenti per ogni colonna.

image

In questo modo, anche se la SwimLane priorità massima è normalmente collassata per non sprecare spazio, appena un elemento vi viene spostato l’header cambia e si può quindi espandere la SwimLane per visualizzare le card che in questo caso hanno Priorità Massima.

La regola di base è non abusare delle Swim Lanes, se il PM o chi per lui si abitua ad inserire frequentemente molte card in Priorità Massima, il team inizierà a considerare le card in Priorità Massima come tutte le altre e quindi si perde il significato originale. D’altra parte far lavorare un team sempre “in emergenza” è il modo migliore per diminuire le performance del team stesso.

Come ultima nota, si può verificare che le card poste nelle swim lanes vanno a sommarsi al conteggio totale delle card nelle varie colonne. Questo significa che se il Work In Progress Massimo per la colonna di testing è 4 e vi sono all’interno già 4 card, in teoria non sarebbe possibile spostare una card in Testing nella swimlane di Priorità Massima. Nella pratica, se la Swim Lane è usata con cognizione di causa e contiene solamente gli elementi con reale Priorità Massima, si può eccedere il WIP nelle varie colonne. Se la colonna di testing è piena ma è necessario fare una verifica per una patch di un bug bloccante in produzione, si può tranquillamente pensare che il team di testing dedichi risorse al bug bloccante, trascurando le card su cui stava lavorando attualmente.

Chiaramente deve essere chiaro che questa violazione del Work In Process può avvenire solamente per le Swim Lanes associate ad eventi eccezionali e non può costituire la normalità. Se i bug bloccanti diventano molto frequenti (la speranza è che questo non accada, ma potrebbe avvenire), significa che la Swim Lane di Priorità Massima è spesso piena di card, a questo punto il team potrebbe decidere di lasciare costantemente uno slot libero in ogni colonna, dato che la probabilità di avere un elemento nella Swim Lane è grande. D’altra parte in caso di frequenti bug bloccanti, è doveroso lasciare il team scarico in modo da poter affrontare i bug velocemente.

Gian Maria.

Comments Off on Kanban Board e Swim lanes  

Nuovo sprint in VSO

Sono state messe online le modifiche del nuovo sprint per Visual Studio Online, e questa volta le novità sono veramente interessanti e tante.

Per prima cosa è ora live la nuova infrastruttura di build, di cui avete avuto una preview con TFS 2015 RC. La build è stata completamente riscritta, e le novità sono veramente molte. Avevo già iniziato a parlare della nuova infrastruttura di build in un vecchio post, TFS2015 build vNext, ed ora che la preview è pubblica in VSO seguiranno altri post sull’argomento.

Abbiamo inoltre una nuova funzionalità per fare opt-in nel Portfolio Management, è ora infatti possibile decidere se utilizzare o meno il livello Features, ed è stato anche aggiunto il livello Epics. Nei template sono stati aggiunti nuovi campi per un migliore supporto al metodo di sviluppo SAFe (Scaled Agile Framework).

Choosing portfolio backlog levels

Continuano infine le migliore alla Kanban Board. Con questo sprint potete editare in place, direttamente nella card, ogni campo che avete visualizzato; questo vi permette di gestire in maniera molto più veloce le varie card.

Sono state aggiunte poi le Branch Policies su Git, ovvero la possibilità di assegnare una build alle pull requests. In questo modo ogni qualvolta viene fatta una pull request di una branch, viene verificata la build e se quest’ultima fallisce non viene data la possibilità di fare la merge dalla interfaccia utente. Inoltre è possibile specificare altre regole, come ad esempio un numero minimo di revisori minimo affinché la pull request possa essere accettata. Sempre sul fronte git è ora possibile accedere ai repository direttamente utilizzando oAuth.

Gian Maria

Comments Off on Nuovo sprint in VSO  

Ancora novità nella Kanban Board di VSO/TFS

Nei precedenti post abbiamo parlato delle novità che sono state introdotte nella Kanban Board di VSO:

Kanban Split Column

Novità di VSO Sprint 79

Definition of Done

Nell’ultimo deploy del 10 Aprile troviamo ancora ulteriori novità. In alto a Destra, potrete trovare un nuovo link, chiamato Settings, che vi permetterà di personalizzare le colonne (opzione già esistente) e le card (la nuova opzione introdotta con questo deploy).

image

La personalizzazione delle Cards permette di scegliere quali campi del Work Item saranno visibili nelle card della board. Ecco qui il pannello delle opzioni.

image

Come potete vedere, finalmente si ha la possibilità di mostrare l’ID del work item in alto a sinistra nella card. Si può poi scegliere se visualizzare avatar e FullName o solo l’avatar o solamente il nome per la persona a cui è assegnata la card. Infine si può scegliere se mostrare l’Effort e i Tag.

La possibilità di visualizzare i Tag è particolarmente importante, soprattutto in VSO, che ammanca ancora della funzionalità di personalizzazione dei Work Item. In Kanban infatti, non si tende a fare stime esatte dell’effort per ogni card, ma spesso basta il T-Shirt sizing: Small, Medium, Large, eXtra Large. Si può pertanto utilizzare i tag per categorizzare le proprie Card, ed avere una migliore visualizzazione:

image

In questo caso è immediatamente visibile la “dimensione” della card, in maniera molto chiara ed esplicita. Ricordo inoltre, che negli sprint precedenti è stata data la possibilità di fare editing in place del titolo della card, basta cliccare nella icona della matitina in alto a destra.

image

Sebbene questa serie di post sia focalizzata sulla Kanban Board, le personalizzazioni di cui vi ho parlato sono presenti anche per la TaskBoard. Ora anche per chi usa SCRUM e vuole scomporre lo Sprint Backlog in Task, è possibile decidere quali informazioni visualizzare nelle card.

image

In questo caso potete personalizzare l’aspetto dei Product Backlog Item e dei task separatamente. La possibilità di creare elementi direttamente nella board rende molto semplice e veloce creare la propria task board, partendo dai PBI dello sprint corrente.

image

Gian Maria.

Comments Off on Ancora novità nella Kanban Board di VSO/TFS  

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.

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

Comments Off on Dove finisce la Kanban Board ed inizia il Feedback  

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.

Comments Off on Kanban Board – Massimizzare il flusso  

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 on Novità di VSO Sprint 79  

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 on Kanban Split Column