«Kanban (Japanese: 看板, meaning signboard or billboard) is a scheduling system for lean manufacturing and just-in-time manufacturing (JIT)»: lo sviluppò Taiichi Ohno, industrial engineer alla Toyota, «per migliorare l'efficienza produttiva». Il sistema prende il nome dalle card che tracciano la produzione dentro la fabbrica; nel settore automotive è noto anche come «Toyota nameplate system».
Nell'ambito della produzione di beni, l'obiettivo del lean manufacturing è limitare le scorte, aumentare la flessibilità del sistema produttivo e dare una risposta rapida alle richieste del mercato. La conseguenza: ci si procura le risorse necessarie (componenti, materie prime) solo in presenza di un ordine e solo all'ultimo momento utile per andare in produzione.
Nel sistema Toyota ogni oggetto o scatola che fluisce nel processo produttivo porta la propria kanban: «kanbans come off items that have been used or transported and go back to the preceding processes as orders for additional items». In forma semplice una kanban board mostra goods in, goods in production, goods out — e «over time, Toyota has evolved this considerably».
Toyota ha sei regole per l'applicazione efficace del Kanban:
«Kaizen (改善, かいぜん), the Sino-Japanese word for "improvement"», è il concetto che si riferisce alle attività di business che migliorano continuamente tutte le funzioni e coinvolgono tutti i dipendenti, dal CEO alla linea di assemblaggio; si applica anche ai processi che attraversano i confini organizzativi (purchasing, logistica, supply chain).
Il processo di miglioramento continuo implica l'analisi critica e la revisione costante dei processi aziendali. Negli approcci agili è importante effettuare un'analisi retrospettiva a ogni iterazione per migliorare i processi di gestione e produzione.
La retrospettiva di fine iterazione riprende il ciclo «build – measure – learn» e le pratiche agili del capitolo 2: Kaizen è il nome giapponese del miglioramento continuo che nei team agile si chiama retrospettiva.
Il Kanban è «un approccio di project management utilizzato in ambito agile e DevOps» che:
Dal punto di vista del PMLC (capitolo 4): il ciclo di vita è iterativo, ma a differenza di altri approcci (es. Scrum) non prevede la definizione formale di uno schema «sincrono» di iterazioni. «Come sono svolte le iterazioni? E in cosa consistono? Lo discuteremo…» — la domanda che il corso lascia aperta.
Gli elementi fondamentali della kanban board (fonte citata dalle slide: Atlassian):
Clicca una card per farla avanzare di una colonna. Le colonne «In lavorazione» (WIP 2) e «In revisione» (WIP 1) bloccano gli ingressi quando sono piene: il team deve fare swarm sulle card prima di avanzare. Quando una card arriva in «Fatto», viene registrato il suo lead time in passi.
Le slide dedicano due KPI al Kanban: il Lead Time e il Cycle Time.
Nel simulatore della sezione 4, il «lead time in passi» di ogni card è il conteggio degli avanzamenti dal commitment point al delivery point: riproduce in forma semplificata la definizione data dalle slide.
Il corso contrappone i due approcci agile:
Sei affermazioni. Scegli se descrivono Kanban o Scrum secondo il corso, poi verifica.
L'approccio Kanban è adatto a essere impiegato «in progetti in cui c'è l'esigenza di iterare», in particolare dove «si è focalizzati sullo scope, che non è chiaramente definito, e la gestione di cicli di durata costante è non praticabile». Due ambiti in cui l'uso potrebbe essere adatto: DevOps e progetti R&D.
Per i progetti R&D i vantaggi sono chiari:
Sei contesti. Scegli Sì se il corso indica Kanban come adatto, No altrimenti; poi verifica.
«DevOps nasce dalla sinergia tra cultura aziendale, pratiche e strumenti e fornisce a un'organizzazione l'abilità di sviluppare applicazioni e servizi con la massima agilità»; consente «l'evoluzione e il miglioramento dei prodotti a ritmo più serrato» rispetto ai processi tradizionali di sviluppo software e gestione dell'infrastruttura. La maggiore agilità si traduce in servizi migliori ai clienti e maggiore competitività.
Il modello DevOps prevede che i team di sviluppo (Development) e produzione (Operations) non agiscano più separatamente: Development + Operations = DevOps. I due team vengono fusi in un'unica unità in cui i tecnici sono attivi lungo tutto il ciclo di vita dell'applicazione — sviluppo, testing, distribuzione, produzione — e acquisiscono competenze non limitate a una singola funzione. I team lavorano insieme per automatizzare i processi aziendali, adattando il workflow alle diverse esigenze e migliorando produttività e qualità.
Il corso chiude il capitolo con una discussione aperta: «Se gestiamo un progetto con un approccio Kanban, proviamo a rispondere assieme alle seguenti domande»:
Queste domande rileggono con gli occhi di Kanban tutto quello visto nei capitoli 8–11: stime, risorse, costi e contratti erano costruiti attorno a un piano; in Kanban non c'è uno schema sincrono di iterazioni, quindi tempi, risorse e costi vanno rinegoziati con un approccio diverso. È il tipo di argomentazione che il corso premia nell'elaborato del capitolo 19.
È un sistema di schedulazione per il lean manufacturing e la produzione just-in-time (JIT), sviluppato da Taiichi Ohno alla Toyota: il nome (看板, «signboard») viene dalle card che tracciano la produzione in fabbrica. Obiettivo: limitare le scorte, aumentare la flessibilità e rispondere rapidamente al mercato.
Never pass on defective products; take only what is needed; produce the exact quantity required; level the production; fine-tune production; stabilise and rationalise the process.
È il concetto giapponese (改善) di miglioramento continuo che coinvolge tutte le funzioni e tutti i dipendenti. Negli approcci agili si traduce nell'analisi retrospettiva a ogni iterazione.
Visual signals (le card), columns (il workflow), WIP limits (il numero massimo di card per colonna), commitment point (quando il lavoro inizia) e delivery point (quando il prodotto è nelle mani del cliente).
Limitano il numero di card in una colonna: quando la colonna è «maxed-out» il team deve fare swarm e spostare le card avanti. Sono critici per esporre i bottleneck del workflow e danno un early warning quando ci si è impegnati in troppo lavoro.
Il tempo che trascorre tra il commitment point e il delivery point: «the elapsed time between the two is called the Lead Time». I team Kanban migliorano continuamente per ridurlo il più possibile.
Kanban è focalizzato sullo scope (visualizzazione del lavoro, WIP limit, flusso, lead e cycle time); Scrum è focalizzato sul tempo (sprint di durata prefissata, ruoli, artefatti e cerimonie per cicli di apprendimento).
Progetti con esigenza di iterare, focalizzati sullo scope con scope non chiaramente definito e in cui la gestione di cicli di durata costante non è praticabile. Due ambiti indicati: DevOps e progetti R&D.
È la sinergia tra cultura aziendale, pratiche e strumenti che consente di sviluppare applicazioni e servizi con massima agilità. Development + Operations = DevOps: i team vengono fusi in un'unica unità attiva lungo tutto il ciclo di vita (sviluppo, testing, distribuzione, produzione), con processi automatizzati.