Tag Archives: agile

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  

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  

Il valore di un approccio iterativo

Mi riallaccio al post di Felice Be an owner not a tenant per aggiungere una considerazione sullo sviluppo Iterativo, uno dei fondamenti dei processi agili. Il terzo punto dell’agile manifesto infatti cita Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale. Uno degli aspetti più […]

Comments Off on Il valore di un approccio iterativo  

Configuration di un Team Project per più team con Backlog Multipli

Precedenti post della serie: Organizzare I Team Project del proprio TFS Nel precedente articolo ho trattato l’argomento spinoso dell’organizzazione dei Team Project, suggerendo la strategia di tenere pochissimi Team Project e se possibile uno solamente (per ogni eventuale Project Collection). Dal TFS 2012 è presente una ulteriore funzionalità che permette di suddividere un Team Project […]

Comments Off on Configuration di un Team Project per più team con Backlog Multipli