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.

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.

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.