Il sistema Kanban ha iniziato il suo percorso negli anni ’50 sulle linee di produzione della Toyota, dopodiché è passato agli uffici ed è diventato uno strumento importante per i manager di progetto.
La flessibilità illimitata della pratica e la sua capacità di auto-organizzare il personale hanno consentito efficienza dove altre approcci non funzionavano. Questo è il caso in cui il biglietto da visita del sistema è diventato il cartoncino stesso — si è affermato come una valuta interna nelle organizzazioni che hanno implementato Kanban.
Origine
Come il concetto di produzione snella, il sistema Kanban è stato sviluppato dai manager della Toyota. L’autore del sistema, l’ingegnere giapponese Taiichi Ohno, è stato ispirato dai principi operativi dei supermercati americani, dove i clienti selezionavano autonomamente i prodotti di cui avevano bisogno. Il ruolo di “supermercato” in Toyota era svolto dal magazzino.Lì, le schede di segnalazione — che è ciò che “kanban” si traduce letteralmente dal giapponese — venivano scambiate tra i lavoratori, che regolavano manualmente il processo produttivo.Le schede erano attaccate a casse con parti. Tali etichette indicavano informazioni sul numero di parte e quantità, quale dipartimento le stava inviando e dove dovevano arrivare.
Il lavoratore direttamente coinvolto nell’assemblaggio delle macchine (“downstream”) prelevava parti dalla cassa a cui era attaccato il “kanban” che richiedeva il rifornimento. La scheda veniva rimossa e passata insieme alla cassa vuota al trasportatore per il magazzino. Lì, un altro lavoratore preparava una nuova cassa con pezzi di ricambio, a cui era attaccato il “kanban” di produzione — un’etichetta con informazioni sui pezzi di ricambio prodotti.
Il “kanban” di produzione veniva sostituito da un “kanban” che richiedeva il rifornimento e inviato alla linea di produzione dei pezzi di ricambio — “upstream”. Così, esattamente la quantità di parti specificata sulla scheda veniva prodotta. La cassa con nuovi pezzi di ricambio veniva posizionata dai trasportatori sulla linea di assemblaggio.
Principi di Kanban
I manager della Toyota hanno articolato 6 regole formative del sistema:
- I lavoratori “downstream” rimuovono esattamente il numero di parti dall’inventario come specificato nel kanban
- I lavoratori “upstream” forniscono anche parti rigorosamente secondo le schede
- Nulla viene prodotto o spostato senza un kanban
- Il kanban deve sempre essere attaccato alle parti
- Le parti difettose non sono utilizzate nel sistema
- Ridurre il numero di schede kanban rende la gestione più sensibile ai cambiamenti. Ma senza estrema necessità, non è consigliabile cambiare il numero stabilito di schede.
Il Kanban è un sistema di “pull”. Crea un equilibrio tra un flusso costante, che elimina i costi di attesa, e una quantità minima di lavoro in corso (WIP), che riduce i rischi di sovrapproduzione. Il WIP è regolato usando schede: il loro numero è fisso e le istruzioni in esse guidano i lavoratori “downstream”.
Il limite del WIP consiste in proporzione al numero di schede kanban, calcolato sulla base dei livelli di vendita e della variabilità statistica nei processi attuali. Il numero massimo di etichette — l’ ”energia” nel sistema — garantisce il livello superiore di WIP in un dato momento. Il WIP è anche limitato dal principio di pull: la velocità di produzione dell’upstream dipende dalla velocità di lavoro del downstream.
Il grafico mostra che uno degli elementi basilari del sistema è la cultura Kaizen. I processi autonomi e la variabilità standard liberano la gestione da un controllo costante, consentendole di concentrarsi sul miglioramento delle prestazioni dei dipendenti.
Applicazione di Kanban nell’IT
Il sistema Kanban, continuando a fornire benefici sulle linee di produzione, ha penetrato il dominio del software.
Solo le schede, che contengono informazioni su scadenze, descrizioni o numeri di processo e nome dell’esecutore, sono ora attaccate non a casse di pezzi di ricambio ma a lavagne con colonne divise:
- Backlog — attività da completare
- Attività attualmente in fase di sviluppo
- Attività completate ma non ancora consegnate ai tester
- Attività pronte per la consegna al dipartimento di testing
- Attività in fase di revisione del project manager (PM)
- Attività completate
Il numero è di solito scritto sopra le colonne — il limite, che indica il numero massimo di processi al suo interno. Il limite del backlog è calcolato a seconda del tempo di consegna. Se ci sono 5 processi lavorativi nel sistema e il tempo medio di completamento per ciascuno è di 1 giorno, il backlog può essere limitato a 5.
La struttura sopra non è rigida — a seconda delle specifiche del progetto, colonne improvvisate possono essere aggiunte. Un sistema Kanban può spesso avere la necessità di definire criteri per la prontezza dell’attività prima dell’esecuzione. In questo caso, appaiono due colonne, indicate in inglese come specify (parameteri di chiarimento) e execute (assumere il lavoro).
- Un’altra colonna con una coda di priorità può essere aggiunta. Quando un esecutore diventa disponibile, deve prima liberare questa colonna dai compiti prima di assumere altri.
- Le attività non completate sono restituite al backlog o barrate dallo schema.
- Il Kanban non incoraggia il multitasking, limitando così il numero di processi per ogni esecutore.
- Un lavoro completato è migliore di diverse attività avviate.
- Un secondo lavoro può essere assunto se il primo è bloccato.
- Il tempo per l’esecuzione delle attività deve essere equilibrato. Una scadenza troppo breve può influire sulla qualità. Un limite eccessivamente esteso consuma le risorse del team e aumenta i costi di processo.
Perché la lavagna Kanban è utilizzata ovunque invece di, ad esempio, tablet o grandi monitor? I sostenitori del sistema rispondono a questa domanda affermando che una tavola regolare ha due vantaggi: è semplice e fornisce un controllo visivo. È facile apportare modifiche su di essa e incoraggia l’interazione tattile e sociale tra i membri del team.
Vantaggi e Svantaggi di Kanban
Il Kanban ha i seguenti vantaggi:
- Flessibilità nella pianificazione. Il team si concentra esclusivamente sul lavoro attuale, con la priorità delle attività impostata dal manager.
- Alto coinvolgimento del team nel processo di sviluppo. Grazie a riunioni regolari, trasparenza del processo e opportunità di auto-organizzazione, i dipendenti si uniscono e mostrano un reale interesse.
- Durata del ciclo più breve. Se le competenze necessarie sono possedute da più persone, la durata diminuisce; se solo una persona le possiede, si crea un collo di bottiglia. Pertanto, i dipendenti dovrebbero condividere conoscenze ottimizzando così la durata del ciclo. Questo consente all’intero team di lavorare su attività bloccate e ripristinare un flusso regolare.
- Fewer collo di bottiglia. I limiti di WIP consentono l’identificazione rapida di colli di bottiglia e aree problematiche sorgenti da mancanza di concentrazione, forza lavoro o competenze.
- Visibilità. Quando tutti gli esecutori hanno accesso ai dati, diventa più facile individuare i colli di bottiglia. I team Kanban, oltre alle schede stesse, utilizzano di solito due report comuni: grafici di controllo e flusso cumulativo.
In pratica, il sistema mostra risultati notevoli in aree di produzione non core:
- gruppi di supporto software o help desk.
- Il Kanban funziona bene nella gestione di startup senza un piano chiaro ma dove sono in corso sviluppi attivi.
Il Kanban ha anche svantaggi:
- il sistema funziona male con team di più di 5 persone
- non è destinato alla pianificazione a lungo termine.
Differenze rispetto a Scrum
Scrum, come il Kanban agile, è una metodologia flessibile che viene spesso applicata anche nell’ambito IT. Le differenze tra loro non sono ovvie a prima vista. Ci sono molte somiglianze, ad esempio, la presenza di un backlog in entrambi gli approcci.
Scrum | Kanban | |
Ritmo | Sprint ripetuti di durata fissa | Processo continuo |
Uscita di rilascio | Alla fine di ogni sprint dopo l’approvazione del project manager (product owner) | Il flusso continua senza interruzioni o a discrezione del team |
Ruoli | Product owner, Scrum master, team di sviluppo | Team guidato da PM; in alcuni casi vengono coinvolti esperti di Kanban agili |
Metriche chiave | Velocità del team | Tempo di consegna |
Riguardo all’accettabilità del cambiamento | Durante uno sprint, i cambiamenti sono indesiderabili poiché possono portare a miscalcoli delle attività | I cambiamenti possono avvenire in qualsiasi momento |
Esempi di Applicazione nell’IT
Proprio da Microsoft: il debutto del Kanban nello sviluppo software
L’uso dei principi del Kanban nell’informatica è iniziato poco oltre 10 anni fa. David Anderson, uno dei principali promotori del Kanban per sviluppatori software, ha consultato Microsoft nel 2005. Erano insoddisfatti delle prestazioni del loro dipartimento — XIT Sustained Engineering, che si occupava di correggere i bug nelle applicazioni interne. All’inizio dell’anno di reporting, questo dipartimento era il peggiore della sua divisione. Il backlog superava le dimensioni accettabili di cinque volte e il tempo di consegna per l’elaborazione di una richiesta era tipicamente di cinque mesi.
Il nuovo PM, con le consultazioni di Anderson, ha aumentato la produttività del dipartimento problematico del 155% in nove mesi. Il tempo di consegna era ora di cinque settimane, il backlog è tornato a una dimensione normale e il completamento tempestivo delle attività si è stabilizzato al 90%. Tutti questi risultati sono stati raggiunti con un’aderenza minima di nuovi dipendenti; il personale ha continuato a correggere bug nello stesso modo — solo gli approcci per organizzare il lavoro sono cambiati.
Un fatto interessante: il program manager Dragos Dumitriu, che si è proponendo di ribaltare la situazione in XIT, era semplicemente affascinato dal libro di Anderson. Con sua sorpresa, ha incontrato l’ideologo del Kanban nel Microsoft dove aveva iniziato solo il giorno precedente. Dumitriu ha chiesto ad Anderson aiuto per il suo compito e quest’ultimo si è detto disponibile ad applicare i principi del suo libro nella pratica.Dumitriu si è trovato di fronte a un dipartimento composto da tre sviluppatori e tre tester, che aveva 80 richieste accumulate nel backlog. Lo stesso PM è stato nominato temporaneamente poiché i requisiti del lavoro includevano competenze nella tecnologia ASP, amministrazione di SQL Server e conoscenza di MS Project Server. La direzione prevedeva un “techie” che potesse codificare, preparare rapporti e prevedere il carico del backlog in questa posizione. Come si credeva allora, il problema del dipartimento sarebbe stato rivelato se si fosse raccolto un gran numero di dati. Dumitriu non era un tale “techie”.
Tuttavia, iniziando ad analizzare le operazioni di XIT insieme ad Anderson, ha rapidamente identificato i fattori chiave che influenzavano negativamente la velocità del dipartimento:
- Prevedere le implicazioni (ROM) per soddisfare una richiesta richiedeva molto tempo. Sia lo sviluppatore che il tester dovevano impiegare un’intera giornata lavorativa per eseguire i calcoli necessari, verificare il codice e completare la documentazione. In media, una richiesta arrivava ogni giorno. Secondo i calcoli del PM, il 40% della produttività del dipartimento andava verso il ROM;
- Era data priorità alle richieste di valore più alto. XIT era finanziato sulla base del valore dell’ordine. La priorità delle richieste veniva discussa mensilmente nelle riunioni dei manager di dipartimento con i clienti — manager di altri dipartimenti. Con un backlog che si espandeva alla velocità attuale, dove solo 6 – 7 richieste venivano elaborate mensilmente, le priorità delle altre richieste cambiavano costantemente a causa del passare del tempo. Molte di esse venivano rimandate a un significato “più tardi”, non in egual modo neppure al mese successivo.
- Alla fase ROM, metà delle richieste venivano filtrate. Alcune erano troppo grandi e venivano riassegnate come progetti da trasferire ad altri dipartimenti, altre erano troppo costose e semplicemente annullate. Alcune richieste non venivano prese in considerazione perché la loro implementazione avrebbe richiesto troppo tempo. Così, il 40% della produttività del dipartimento veniva spesa ad analizzare le richieste, di cui il 50% venivano respinte. Circa il 15 – 20% delle risorse lavorative veniva sprecato.
- Il lavoro preparatorio sulle richieste poteva protrarsi per mesi prima che l’implementazione iniziasse. I calcoli della fase ROM potevano perdersi o essere dimenticati durante quel periodo. Soprattutto se l’implementazione era gestita da un diverso sviluppatore rispetto a quello che aveva avviato l’analisi.
Soluzioni Kanban per il dipartimento problematico di Microsoft
Alla fine del 2005, la produttività del dipartimento è aumentata del 155%. Per migliorare ulteriormente il lavoro di XIT, sono stati assunti due dipendenti: uno sviluppatore e un tester. Il numero di richieste nel backlog è diminuito a 10, e uno sviluppatore ha costantemente elaborato 11 richieste per trimestre. In media, 56 richieste sono state completate per trimestre rispetto a 11 in precedenza. Il costo delle richieste è sceso da $7500 a $2900.
Applicazione in Corbis
Dopo aver ottenuto successo presso Microsoft, Anderson nel 2006 ha iniziato a occuparsi di un nuovo compito complesso. Ora lavorava per Corbis — un’altra azienda di Bill Gates, che non aveva ancora lasciato MS. Una delle attività di Corbis era la licenza fotografica. All’epoca era la seconda più grande libreria di stock photo al mondo con un database di circa 3.5.000 immagini.
Il compito di Anderson era quello di accelerare i principali rilasci dell’azienda. L’intervallo tra i loro rilasci era di tre mesi e poteva crescere ancora di più. Già discutere il piano di rilascio richiedeva due settimane alla direzione. Era necessario stabilire il rilascio di rilasci secondari o aggiornamenti ogni due settimane. Allo stesso tempo, le risorse chiave dovevano essere dirette verso il progetto principale.
Una lavagna Kanban è apparsa nell’ufficio di Corbis, dove Anderson parlava quotidianamente con il team. L’obiettivo del PM era migliorare il controllo visivo sui processi, incoraggiare l’auto-organizzazione e una maggiore responsabilità personale tra gli esecutori. Il sistema Kanban era anche destinato a ridurre il controllo dei manager e aumentare la produttività.
Oltre a schede colorate e grafici, è apparso un “cestino della spazzatura” sulla lavagna — in cui venivano inviate attività troppo grandi.
Foto dalla presentazione ufficiale
Un Sistema Kanban per il Sostegno Ingegneristico sui Sistemi Software di David J Anderson
Il sistema Kanban chiariva quando il flusso smette di essere fluido e dove si verificano ritardi, il cosiddetto collo di bottiglia. Discussioni rapide con il team hanno aiutato a identificare i problemi attuali. Ad esempio, il testing richiedeva 3 giorni, il che ha influito negativamente sulla tempistica di rilascio. Tre dipendenti si sono riuniti e hanno trovato un modo per ridurre il tempo a un giorno.
Un collo di bottiglia è una sezione dello schema o algoritmo delle operazioni dell’azienda, in cui le limitazioni di produttività delle risorse o umane riducono drasticamente la fluibilità del flusso delle attività. Una mancanza di personale, una connessione internet scadente o un direttore in vacanza bloccano o rallentano l’esecuzione delle attività.
I limiti per le schede Kanban sono stati impostati empiricamente due volte. Nella colonna “pronta per lo sviluppo”, i limiti sono stati aumentati. È anche apparsa una nuova colonna — “pronta per il testing”. Molte richieste per il downstream erano formulate in modo errato, causando spese di tempo non necessarie. Pertanto, il PM ha esaminato le operazioni del flusso superiore e ha trovato errori.
La procedura di revisione delle richieste potrebbe richiedere 100 giorni, ma i rilasci hanno comunque cominciato a emergere ogni due settimane come pianificato. Le decisioni sui contenuti del rilascio venivano prese 5 giorni prima della pubblicazione. La pratica di conteggio, come nel caso del dipartimento XIT presso Microsoft, è stata abbandonata a favore della produttività. Le priorità delle attività sono state impostate secondo “costo di ritardi” o prontezza delle risorse.
Il sistema Kanban non solo ha aiutato Anderson a raggiungere l’obiettivo stabilito, ma ha anche migliorato il morale all’interno del team. Grazie a discussioni collettive e visibilità dei processi, i dipendenti hanno stabilito fiducia reciproca. Il personale ha anche abbracciato il Kaizen, ovvero la pratica del miglioramento continuo.
Programmi e App per KANBAN
Trello
Popolare sistema Kanban per la gestione delle attività. È noto per il suo fascino visivo e l’interfaccia user-friendly. Gli utenti evidenziano la sua super flessibilità.
Kanbantool
Lavagna gratuita per due utenti. Supporto API e interfacce touch.
Lean Kit Kanban
Lavagna gratuita per cinque utenti con buone caratteristiche di collaborazione. Supporto API e capacità di import/export, statistiche ampie.
Kanbanize
Servizio completamente gratuito con funzionalità decenti. I suoi proprietari garantiscono un aumento del 300% della produttività quando utilizzano il loro prodotto.
Worksection
Ukrainian SaaS — applicazione per il tracciamento e la gestione rapida dei progetti. Attualmente, oltre a contabilizzare le finanze e le scadenze, c’è un diagramma di Gantt. Nei prossimi mesi, gli sviluppatori aggiungeranno una lavagna Kanban con opzioni di personalizzazione, rendendo il servizio ancora più adatto al Kanban.
Sentenza
Il Kanban è una pratica che aiuta a raggiungere il successo, mentre l’uso di soli metodi agili non è obbligatorio. Cambiamenti significativi sono raggiunti eliminando il tempo perso, gestendo i colli di bottiglia e riducendo la variabilità.
Tuttavia, i cambiamenti di successo richiedono tempo. Si verificano gradualmente, mentre la resistenza del team alle innovazioni è minima. Il sistema Kanban motiva il personale a migliorare senza cambiamenti nei metodi ingegneristici.
I libri per l’articolo sono forniti da kniga.biz.ua