Gabriele Lana

E’ noto che nel nostro campo ogni nome viene sovraccaricato di significati, l’ultimo esempio riguarda i Kanban

Prima si è iniziato a parlare di Lean, poi qualcuno ha iniziato ad usare e a parlare di Kanban Board, infine adesso Kanban è diventato quasi il nome di una metodologia. Adesso quando uno parla di Kanban non so a cosa pensare:

• Starà parlando di Kanban come sinonimo di Lean? Si ma Lean come sinonimo di Lean Thinking, ovvero la filosofia Lean o Lean Development, ovvero l’applicazione della filosofia Lean allo sviluppo del software?
• Starà parlando di Kanban come sinonimo delle board che adesso vanno tanto di moda negli Agile shop?
• Starà parlando di Kanban come di una non meglio precisata metodologia? Come lo ScrumBan, ovvero uno Scrum che fa uso di Kanban Board o come Kanban, ovvero l’uso delle Kanban Board misto a qualche pratica presa da XP?

Insomma un delirio, la salvezza come al solito sta nella conoscenza: bisogna tornare alle origini della parola, studiarne l’evoluzione per capirne le implicazioni ed un eventuale contesto d’uso

Kanban si traduce in cartellino: I giardini imperiali giapponesi sono curati all’ossessione e sono considerati un patrimonio del giappone, per questo solo poche (supponiamo 100) persone alla volta sono autorizzate ad entrare, per garantirlo vengono usate delle tessere di plastica bianche, ne esistono solo 100, una persona può entrare solo se possiede una di queste tessere che possono essere prelevate da un contenitore all’ingresso, quando il contenitore è vuoto nessuno può entrare, quando una persona esce deposita la sua tessera che verrà automaticamente trasferita nel contenitore all’ingresso consentendo a qualcuno di prelevarla ed entrare. Le tessere di plastica sono Kanban

Quindi i Kanban sono la rappresentazione sistemica del vincolo sulla capacità produttiva dell’impianto. Cosa significa quesa frase e come può tornare utile allo sviluppo del software lo spiego subito

L’applicazione del pensiero Lean porta ad eliminare una classe di problemi e/o di sprechi nell’attività produttiva attraverso un approccio sistemico ovvero creando un ambiente di lavoro che rende difficile commettere errori. Un esempio tipico sono i connettori la cui forma impedisce fisicamente di sbagliare verso. Un altro bell’esempio ce lo forniscono gli ospedali in cui si applica il pensiero Lean, nei quali tutte le attrezzature hanno un posto dedicato che solitamente viene marcato con un’immagine stilizzata del tipo di attrezzo che dovrebbe occupare quello spazio, in questo modo

• E’ molto semplice accorgersi se uno strumento è fuori posto perchè ci sarebbe l’immagine dello strumento senza lo strumento stesso
• Nei momenti d’emergenza non devi metterti a pensare dove si trova uno strumento perchè sta sempre nello stesso posto
• L’ordine non è più una questione di gusto personale :-)
• Essendo la distribuzione degli strumenti così rigorosa è possibile fare esperimenti per capire se un’eventuale riorganizzazione (che è quasi sempre microscopica seguendo il principio del Kayzen) produce un miglioramento o meno

Quando si ha a che fare con dei sistemi complessi è molto più efficiente ed efficace applicare un controllo indiretto invece che tentare di forzare le singole parti al proprio volere, basta pensare all’acqua, le singole particelle costituiscono un sistema complesso con proprietà emergenti, come fai a trasportare l’acqua? tenti di convincere le singole particelle? La sposti fisicamente? O crei un canale e lasci che felicemente scorra seguendo le proprie leggi ma finendo esattamente dove vogliamo Quest’ultimo può essere definito un approccio sistemico

Ahhhh se solo la maggior parte dei manager sapesse… il mondo girerebbe diversamente, ma la resa dei conti arriverà presto caro cravattato dall’ignoranza bovina… ma sto divagando

Le Kanban Board creano un ambiente di lavoro dove è difficile commettere una serie di errori classici della produzione: avere molte user stories in lavorazione (semilavorati) che non portano valore al sistema, evitare il sovraccarico di lavoro del team, individuare molto velocemente eventuali parti critiche dello sviluppo di una user story, ecc… Bene, ma dove sono i Kanban nelle Kanban Board che si usano nella produzione di software? Non sono le carte delle user stories (come banalmente si potrebbe pensare), i kanban rappresentano i limiti della produttività del sistema, in questo caso il limite è sul numero delle user stories che possono essere in lavorazione ovvero i kanban sono i singoli “posti” che possono essere occupati dalle carte delle user stories.

Per ogni fase ci possono essere un numero limitato di user stories, in questo modo si possono facilmente identificare eventuali stalli, fasi problematiche, sprechi di vario genere ecc…, peccato che tutto questo sia molto lontano dall’essere Agile… perchè? Semplice il limite è imposto sulle fasi, si presuppone quindi che ogni fase sia un sottosistema dimensionabile a piacere per equilibrare il flusso delle user stories fino al loro completamento, una fabbrica insomma, alla fine siamo tornati al waterfall (il cravattato ci prova sempre, non c’è niente da fare)

Molto più Agile e sensato sarebbe limitare la capacità produttiva del team sulle dimensioni del team stesso, banalmente una user story per sviluppatore, al limite per coppia di sviluppatori. Ad ogni sviluppatore assegnamo una calamita, le user story appese alla lavagna sono in lavorazione, una user story può essere appesa usando solo una di quelle calamite, una calamita può essere usata solo con una user story alla volta ed il gioco è fatto. Le fasi possono essere ancora conservate, possono essere utili per stanare certi problemi, ma l’enfasi dovrebbe essere sugli sviluppatori e non sulle fasi (“Individuals and interactions over processes and tools” vi ricorda qualcosa?)

Concludo dicendo una cosa ovvia: più si studia uno strumento/pratica/tecnica e più è facile utilizzarlo saggiamente nel contesto in cui ci si trova per raggiungere i nostri obiettivi, il pericolo è quello di abusarne o peggio essrne abusati :-)