Nell’articolo precedente abbiamo visto la storia e i principi di Kanban, metodologia di lavoro che nasce in Giappone nell’ambito della produzione Lean e che viene adattata in anni recenti all’ambito di sviluppo del software. In questa seconda parte, entriamo nella pratica, vedendo come si progetta e si implementa una lavagna Kanban.

Kanban in pratica

Lo scopo di questa seconda puntata è di guidare il lettore all’utilizzo della metodologia Kanban, tramite semplici esempi che mostrino come progettare e come utilizzare una lavagna Kanban e soprattutto come, grazie all’uso dei cartellini visuali e di una lavagna sia possibile applicare le indicazioni della metodologia e dei principi della produzione Lean.

In perfetto rispetto dei principi della metodologia, questo articolo fornisce una introduzione visuale facendo uso di un gran numero di figure: non poteva essere altrimenti, se si ripensa al significato della parola Kanban. Rimandiamo alle puntate successive tutti gli approfondimenti teorici, necessari per poter comprendere le ragioni e i fondamenti di determinate scelte.

Progettiamo la prima Kanban board

Il primo step nella realizzazione di una lavagna Kanban consiste nel raccogliere su una parete o su un pannello dei cartellini corrispondenti alle attività che si vogliono gestire con Kanban. L’uso di uno spazio ampio e libero da schemi preimposti  può aiutare a comprendere meglio lo stato attuale del lavoro all’interno dell’organizzazione (figura 1).

Figura 1

Per questo può essere utile mappare in forma molto ampia e approssimativa il processo di lavorazione, per esempio raggruppando i cartellini corrispondenti alle attività simili, oppure provare a impostare una qualche forma di ordinamento, per esempio in alto quelle che dovranno essere prese in lavorazione per prime, oppure dividendo quelli corrispondenti alle cose da fare da quelli che rappresentano le cose attualmente in lavorazione da quelli che invece sono ormai stati completati (figura 2).

Figura 2

Il passo successivo (figura3) potrebbe essere quello di dettagliare maggormente il processo, suddividendo la fase di lavorazione e introducendo i vari step intermedi relativi alle varie sottofasi. In questo caso si sono create le colonne relative ai classici step che si compiono in un team di sviluppo software: dall’analisi, allo sviluppo al test e infine al deploy (in questo caso identificato dalla etichetta run).

Figura 3

Nella figura 4 si può notare, per ogni fase della lavorazione, la presenza di un’ulteriore suddivisione in modo da introdurre, fra le varie fasi, delle aree di “parcheggio” per i task (i cosiddetti buffer).

Figura 4

Come accennato nella puntata precedente di questa serie quando si è provato a descrivere una tipica giornata lavorativa del pizzaiolo Antonio, e come avremo modo di vedere meglio nel prosieguo di questa serie di articoli, l’introduzione di queste zone di stazionamento aumenta la performance complessiva del sistema e abilita l’applicazione di un approccio pull.

In questo caso, infatti, dopo aver completato il proprio lavoro. ogni membro del team invece di spingere il task alla fase successiva (approccio push), lo parcheggia nella colonna delle attività completate, in attesa che qualcun altro (o lui stesso se è libero) lo prenda in lavorazione nella fase successiva (approccio pull).

Infine, sulle varie fasi del ciclo di lavorazione si possono introdurre dei limiti al numero di attività che si possono eseguire in contemporanea (figura 5).

Figura 5

Limitare il numero di attività per fase di lavorazione permette di stabilizzare il flusso della lavorazione, impedendo che, per esempio, il lavoro si accumuli in alcuni punti del ciclo di lavorazione (“colli di bottiglia”) o che altre parti siano completamente scariche (le “secche” a valle del restringimento): Il sovraccarico e lo sbilanciamento del flusso sono due fenomeni che abbassano in modo evidente le performance del sistema, tanto che nella teoria della produzione snella (Lean Production) insieme allo spreco diretto, sono indicati come le  tre principali motivi di degrado di un sistema di produzione;

La gestione di queste tre forme di spreco ricopre una parte importante nel Toyota  Production System, messo a punto nel secolo scorso da Taichi Ohno, tanto da dare vita alle famose 3M su cui si poggia l’intera filosofia Lean: Mura (“sbilanciamento”), Muri (“sovraccarico”) e Muda (“spreco”). La scelta dei valori da assegnare alle varie colonne non è affatto casuale nè semplice: avremo modo di parlarne in modo dettagliato in un prossimo articolo.

Simulazione di un flusso di lavorazione

Dopo aver introdotto gli elementi fondamentali di una Kanban board, si proverà adesso a simulare la gestione di un tipico processo di lavorazione. Per fare questo si partirà con una situazione iniziale come quella raffigurata in figura 6, dove ancora nessuna attività è stata presa in carico per la lavorazione.

Figura 6

Il primo passo (figura 7) è quello di mettere in lavorazione due attività nella prima fase che è quella dell’analisi. Dato che il WIP (Work In Progress) Limit della lavorazione è di 2 task, questa operazione è consentita.

Figura 7

Non appena viene completata la lavorazione di uno dei due task di analisi (figura 8), questo verrà messo nella colonna delle cose fatte e sarà pronto per essere preso in lavorazione in sviluppo. In questo momento si libera un WIP sulla colonna di analisi per cui un altro task potrà essere messo in lavorazione in analisi.

Figura 8

Proseguendo simulazione (figure 9 e 10) si nota che i vari task si spostano in orizzontale verso destra dando luogo a un vero e proprio flusso di lavorazione.

Figura 9

Figura 10

Push e Pull

Nella figura 11 viene raffigurata una board in cui non sono stati utilizzati i WIP Limits sulle varie colonne; dato che la tendenza a “mettere altra carne al fuoco” è molto comune, in casi come questo, non essendoci alcun limite alle cose che si possono avviare alla lavorazione, spesso si nota che dopo qualche tempo si formano degli ingorghi, tipicamente nel punto più lento del processo di lavorazione.

Figura 11

Nella figura successiva (figura 12) si nota come il vincolo imposto sulle colonne permetta di impedire l’accumulo, e anzi renda più omogenea la lavorazione delle attività: in questo caso infatti, non appena si raggiunge il limite per una qualsiasi colonna, il sistema tende a saturarsi impedendo ulteriori inserimenti in lavorazione. In casi come questo infatti, se i WIP Limits sono stati assegnati con criterio, solo agendo in modalità pull (si tirano verso destra le attività da svolgere) si può prevenire il blocco totale del sistema.

Figura 12

Gli avatar del team

Una tecnica efficace per migliorare il controllo del flusso prevede l’uso di icone da apporre sulle card e con le quali si rappresentano i vari membri del team: si possono utilizzare figure di fantasia, disegni astratti o vere e proprie foto. Normalmente si dedica una parte della board per parcheggiare le varie icone delle persone del team (figura 13).

Figura 13

Quando una persona prende in carico un’attività, preleva il proprio avatar e lo appone sul cartellino; viceversa, quando l’attività è terminata, l’avatar viene staccato dal cartellino e rimesso nel “parcheggio“.

Figura 14

L’uso degli avatar permette di verificare in modo semplice e immediato l’impegno delle varie persone del team sulle varie attività, così come coordinarne lo spostamento quando si presentano attività critiche che richiedono un rapido intervento (in gergo swarming).

Come si è già avuto modo di dire più volte uno dei principi fondamentali del Lean è la riduzione del sovraccarico di lavoro su determinate fasi del processo: in un team agile questo si traduce nel bilanciare in modo uniforme il lavoro e di limitare il più possibile il numero di cose che ogni persone svolgerà in parallelo. Purtroppo, spesso queste raccomandazioni non sono rispettate proprio per la naturale tendenza che abbiamo a fare più cose contemporaneamente e nel cercare di lavorare oltre i nostri limiti naturali.

Grazie all’uso degli avatar si può combattere questa tendenza per esempio introducendo un limite sul numero di avatar a disposizione per ogni persona.

Se si guarda per esempio la figura 14, notiamo che Andrea, che in questo caso probabilmente non è uno sviluppatore, si occupa delle attività di test e di deploy finale. In questo caso Andrea è impegnato su tre differenti attività, quindi la sua capacità operativa è giunta al limite massimo; egli potrà  eseguire altri test solo dopo aver terminato le attività che ha preso in carico attualmente.

Il numero degli avatar da assegnare ad ogni membro del team può essere uguale per tutti, oppure come in realtà accade, è funzione del tipo ti attività che le persone devono svolgere. Parleremo più in dettaglio di questi aspetti in una prossima puntata di questa serie.

Il lavoro in un team cross-funzionale

Nelle figure 15, 16, 17 e 18 viene raffigurata una tipica situazione in cui le persone del team si spostano fra le varie attività e lavorano in coppia per velocizzarne la lavorazione. il che si verifica quando si dispone di un team crossfunzionale, ossia composto da persone capaci di svolgere tutte le attività previste dal processo: è questa una situazione ottimale che permette un adeguato bilanciamento fra le varie persone e le varie attività, evita la dipendenza dai singoli e consente in generale di avere performance maggiori. Nella figura 15, Yury ha terminato il suo compito e quindi sposta il proprio cartellino nella colonna del finito.

Figura 15

A questo punto, egli potrebbe mettersi alla lavorazione di un nuovo task: per esempio, come mostrato nella figura 16, prendere un task dalla colonna done dell’analisi e metterlo in lavorazione per lo sviluppo.

Figura 16

Dato che Yury è in grado di svolgere il lavoro dei suoi colleghi, per velocizzare il flusso e favorire lo “scodamento” delle attività, potrebbe in alternativa lavorare insieme con Francesco per completare più rapidamente il  task di quest’ultimo (figura 17).

Figura 17

Nel caso in cui Yury infine sia in grado di svolgere anche le attività di test o di deploy finale, potrebbe aiutare Andrea a “evadere” le attività sulla destra, cosa che, come abbiamo avuto modo di vedere, ha effetti benefici sulle performance complessive, oltre a ridurre il rischio di blocchi e rallentamenti (figura 18). Ne parleremo più in dettaglio in una puntata appositamente dedicata a questi aspetti.

Figura 18

Gestione delle emergenze

L’ordine con cui le varie attività sono messe in lavorazione segue l’ordinamento che viene dato ai cartellini nella colonna iniziale del ToDo, la quale viene ordinata in base a una qualche priorità: valore rilasciato al cliente, come in Scrum, urgenza o tempo di arrivo come spesso avviene in Kanban.

A volte è necessario poter gestire emergenze improvvise che sovvertono l’ordine iniziale delle attività: si pensi per esempio al caso dello sviluppo della versione 2.0 di un qualche prodotto, che contemporaneamente è in produzione  con la versione 1.0. da utenti che lo sfruttano in tutte le sue funzionalità. In questo caso, durante il suo utilizzo, la versione 1.0 potrebbe evidenziare dei problemi che dovrebbero essere risolti tempestivamente: potrebbe trattarsi di un bug da risolvere, un impedimento infrastrutturale (p.e:. un server bloccato) o altro ancora.

Per non perturbare il team con qualcosa che esula dall’applicazione del processo Kanban, la presa in carico e la soluzione di questi problemi potrebbe essere inserita nella Kanban board come normali attività alle quali si assegna una priorità maggiore: si tratta infatti di emergenze che devono essere evase prima possibile.

Figura 19

Per questo motivo, spesso si disegna nella board una corsia particolare dove dovranno “viaggiare” le emergenze, attività che devono avere la priorità rispetto alle altre; per questa ragione spesso questa corsia prende il nome di corsia di emergenza (o expedite lane); a volte si disegnano icone particolari come l’ambulanza o il camion dei pompieri, oppure si colora l’intera corsia (come in figura 19). Le card di emergenza sono in genere colorate di un colore diverso (rosso o arancione) proprio per evidenziarne il carattere di emergenza.

Figura 20

Nelle figure 20, 21, 22 e 23 si può osservare un tipica modalità di lavoro del team quando un’emergenza viene assegnata al gruppo: in questo caso, ove necessario, le persone interrompono il proprio lavoro per dedicarsi completamente alla lavorazione del cartellino. Se necessario, e se possibile, le persone lavorano in coppia in modo da velocizzare il completamento del lavoro.

Figura 21

Figura 22

Nella figura 23 si può vedere come test e il deploy siano eseguite da una sola persona: sebbene sia piuttosto tipico infatti che il test o il deploy siano svolti da una sola persona, si noti come questa configurazione possa introdurre un collo di bottiglia in fondo al processo di lavorazione del ticket, cosa che non è auspicabile se si vuole risolvere rapidamente il problema.

Figura 23

Gestione dei difetti di lavorazione

Una variante del caso precedente si ha quando il team si imbatte in un difetto del software che sta sviluppando: questo difetto potrebbe apparire durante un’attività di test unitario eseguito in fase di sviluppo oppure durante il test utente eseguito in fondo alla linea di produzione (come in figura 24).

Figura 24

Una prima opzione per gestire il difetto potrebbe essere quella di inserirlo come attività nel backlog, in mezzo alle altre cose da fare o eventualmente in cima all’elenco, nel caso si desideri dare precedenza a questo task rispetto alle altre attività (figura 25).

Figura 25

Qualora la gravità o l’importanza del difetto fossero tali da richiedere una pronta soluzione a discapito dello sviluppo di ogni altra attività (per esempio per non propagare l’errore in tutte le nuove componenti che nel frattempo verrebbero sviluppate), si potrebbe optare per inserire nella board tale difetto come emergenza: in questo caso la sua gestione seguirebbe quella vista in precedenza (figure 26 e 27).

Figura 26

Figura 27

Suddivisione del flusso di lavoro: scatter  merge

Le varie colonne della Kanban board corrispondono a quella che si potrebbe definire la scomposizione verticale e sequenziale delle attività del processo: ogni colonna rappresenta una fase atomica del processo di lavorazione; per essere completata, ogni attività deve passare per tutte le colonne della Kanban board.

A volte però non è possibile scomporre il processo  in fette verticali, proprio perchè le varie fasi non sono atomiche ma possono essere costituite da attività che devono essere eseguite in parallelo.

Si pensi per esempio a un processo di lavorazione di un qualche componente che preveda lo sviluppo della parte di hardware, di firmware di sistema e di software applicativo. Lo sviluppo potrebbe essere quindi diviso in queste tre linee di lavoro mentre il test potrebbe essere eseguito sul componente dopo che tutte le varie parti siano state sviluppate e integrate. Per poter gestire questo tipo di situazioni si può procedere a modificare la board introducendo delle corsie orizzontali solo nella colonna relativa allo sviluppo, come riportato nella figura 28.

Figura 28

In questa configurazione, tutte le volte che un cartellino arriva nella colonna di sviluppo, verrà scomposto in 4 sotto–cartellini  che verranno poi ricongiunti in un unico cartellino man mano che lo sviluppo sarà terminato (figure 29 e 30).

Figura 29

Figura 30

Conclusioni

Per questo mese la lezione di pratiche Kanban termina qui. Nella prossima puntata proseguiremo con altri esempi pratici legati alla gestione dei flussi di lavorazione e cominceremo contestualmente a introdurre alcuni concetti teorici che sono alla base della metodologia e che permetteranno di comprendere meglio il motivo di certe scelte pratiche.