Esempi di Kanban

Kanban può significare un certo numero di cose. In giapponese, la traduzione letterale è "cartello", ma si riferisce anche ad un sistema di produzione snella, e di fatto, un processo di eliminazione dei rifiuti da un sistema di produzione di qualsiasi tipo. In questo articolo , io subito descrivono come vengono utilizzate le schede kanban, e come il Kanban con un sistema di capitale K può essere utilizzata per migliorare i sistemi esistenti.

Esempi di Kanban

Se avete mai ordinato un drink espresso da Starbucks, probabilmente avete visto li scrivi il tuo ordine sulla vostra tazza. Se non c'è nessuna linea, la coppa va al barista making vostro drink. Tuttavia, se sono occupati, la coppa va al retro di una coda, e il barista tira dalla coda fino a quando hanno raggiunto e ognuno ha il proprio drink In questo semplice sistema, la tazza con il vostro ordine su di esso si comporta come un kanban -. un token che fornisce informazioni all'interno del sistema. Immaginate come il sistema potrebbe funzionare se non ci fosse segno tale, e solo uno o due clienti potrebbero essere serviti in un momento. Ogni cliente avrebbe posto il loro ordine, il cassiere li avrebbe telefonato, e tutti avrebbero aspettato mentre le bevande sono state fatte. Poi, il cliente riceverà il proprio drink (s), e il cliente successivo potrebbe essere servita da quella cassa. Questo processo, ovviamente, si tradurrebbe in tempi di attesa più lunghi e tempi di throughput totale per molti clienti, soprattutto quelli che erano solo afferrare un semplice caffè, non una bevanda espresso. È anche possibile pensare a come tutto questo parallele richieste sincrone ad una applicazione web al contrario di una applicazione web che mette semplicemente le richieste in una coda per un altro processo per completare i lavori, ma che è al di là del campo di applicazione del presente articolo.
Nel classico esempio di utilizzo Kanban in un sistema di produzione, le schede kanban effettivi residenti su bidoni di pezzi in una fabbrica. Loro scopo era quello di tenere l'inventario al minimo e fornire un segnale all'interno del sistema per il rifornimento di code. Ad una stazione di assemblaggio particolare che richiedono una certa componente, un contenitore pieno dei componenti sarebbe stato presente. Il lavoratore o la squadra in questa stazione avrebbe preso dal bin come hanno completato il loro lavoro di assemblaggio. Quando il bin esaurisce parti, viene scambiato per uno pieno dalla fabbrica in loco ripostiglio. All'interno di questo ripostiglio, un bidone vuoto fornito un segnale che più parti sono stati necessari. Lo staff magazzino sarebbe scambiare il contenitore vuoto per una piena da parte del fornitore (forse la prossima volta che il fornitore ha una consegna , o andando al loro fornitore). Così, in un dato momento ci sono 3 contenitori in gioco (uno al punto di raccolta, uno al magazzino locale, e uno presso il fornitore), e quindi questo è in genere indicata come uno a tre-bin System.

Kanban per il Project Management

Nel regno di progetti software, Kanban può essere uno strumento utile per eliminare gli sprechi e migliorare l'agilità. L'obiettivo principale del Kanban è quello di identificare ed eliminare i colli di bottiglia e dei rifiuti e per aumentare la produttività attraverso il sistema. E 'proprio non l'obiettivo di massimizzare l'efficienza o l'utilizzazione di tutto il personale coinvolto nel sistema. Un passo comune prima Kanban si applicano ad un sistema esistente è quello di creare una mappa del flusso del valore. Questo processo comporta l'identificazione di tutti i passi che un unità di valore passa da dall'inizio alla consegna, notando il tempo sia produttivo e dello spreco. Per esempio, se si lavora in un reparto di assistenza che fare con bug segnalati dagli utenti finali, si potrebbe avere un processo che coinvolge questi passaggi (questo rappresenta solo un possibile flusso di lavoro attraverso il sistema ):

• Cliente segnala un problema per il supporto
• Gestione priorità la questione
• Uno sviluppatore viene assegnato il problema e crea una correzione
• QA verifica il problema e garantisce l'assenza di regressioni sono state create
• Rilasciare orari squadra del problema per un rilascio e crea un hotfix per il cliente, se richiesto
• Fix viene rilasciato in un aggiornamento software a disposizione del pubblico

Ognuno di questi passi è necessaria nel processo, e l'obiettivo qui non è quello di cambiare nessuno di loro, ma semplicemente di individuare dove il valore e il tempo viene speso. Ciò che manca nel processo di cui sopra, però, è il tempo impiegato per ognuna di queste azioni, e il tempo trascorso tra di loro. In genere, ci sono code tra ciascuna delle fasi di cui sopra, e alcuni degli eventi si verificano solo in alcuni punti nel tempo. Per esempio, la gestione non ha intenzione di dare la priorità di ogni questione come arriva. Più probabilmente, faranno tenere una riunione priorità in base a una pianificazione, forse una volta ogni settimana o due. Allo stesso modo, i comunicati genere non si verificano con tutti i bug fix, ma piuttosto su una sorta di programma o almeno solo quando la quantità di nuove caratteristiche e correzioni di bug garantisce un comunicato.
Se diciamo che aver segnalato il problema dura 15 minuti, e le altre fasi, ciascuna per un'ora o due, e tra un passo e abbiamo una media di 4 giorni di tempo di attesa (tranne che per la riunione settimanale di priorità, che in media 3,5 giorni dal accade settimanale), allora possiamo creare una mappa di Value Stream come questo:

Sommando il tempo produttivo e sprecato, otteniamo:

• Valore Aggiunta del tempo: 7 ore e 15 minuti
• Wait Wasted Time: 19,5 giorni
• Tempo complessivo (tempo di ciclo): 19 giorni, 19 ore, 15 minuti (19,8 giorni o ore 475.25)

Una volta che queste informazioni è visibile, modifiche possono essere apportate al sistema per migliorare il flusso globale e ridurre i tempi di attesa inutili. Questo è in genere fatto riducendo la quantità di Work In Progress (WIP), perché l'unico altro modo per ottenere un aumento in volume è di aggiungere capacità di produzione aggiuntivo (tutti nel suddetto sistema è già completamente utilizzata). Little legge afferma che il tempo medio totale di un elemento attraverso il sistema (anche noto come tempo di ciclo) è inversamente proporzionale al numero di elementi in il sistema. Cioè, Tempo di ciclo = Work in Progress / (ritmo di lavoro). il ritmo di lavoro nello scenario sopra dovrebbe essere di 1 bugfix per 7.25 ore. Così, il tempo di ciclo deve essere uguale al WIP * 7,25, che per un tempo di ciclo di 475.25 ore WIP significa un totale di circa 65 elementi.
Se il WIP totale sono stati ridotti a 30 elementi, e niente altro il sistema è cambiato, allora correzioni di bug sarebbe stato completato in media in 9 giorni, non 19, una riduzione del 52%. Questa è la promessa di Kanban. Come goccia tempi di ciclo, il valore di ogni elemento di lavoro è aumentato, in quanto i clienti vedono i loro correzioni di bug e richieste di nuove funzioni prima, riducendo l'anello di retroazione, e la fiducia comincia a sviluppare che le cose possono ottenere fatto in un ragionevole lasso di tempo, così i clienti e la gestione non si sentono come loro necessario cercare di stipare quanto più possibile in una sprint dato o ciclo di rilascio.

Kanban Boards

Un modo per ridurre WIP è visualizzare ciascuno degli stati un elemento di lavoro passa attraverso il sistema e per limitare il numero di elementi che possono essere in qualsiasi stato somministrato una volta. Quando uno stato a valle è al suo massimo WIP, il monte gli stati devono interrompere la produzione e fare qualcos'altro. Possono aiutare lo stato a valle, il che potrebbe significare che gli sviluppatori di saltare e di fornire un aiuto per il team di QA o di rilascio, oppure possono recuperare il ritardo su altre attività che sono necessarie (documentazione, refactoring, formazione, sistema di automazione, ecc.) Non è una cattiva idea tenere una scheda separata miglioramento che ha lista di priorità del team di cose che vorrebbero fare per migliorare il loro sistema, che le persone che sono bloccati a valle possono utilizzare per decidere cosa lavorare fino a quando il sistema è nuovamente. Se il sistema è sempre bloccato nello stesso punto, allora questo rende visibile a tutti che le risorse supplementari a questo punto.
Boards più kanban vengono creati utilizzando post-it su una lavagna, ma ci sono molte opzioni elettronici disponibili pure. Quello che ho usato con successo è AgileZen, Illustrato di seguito:

Utilizzando una scheda elettronica kanban, si può facilmente mantenere un team distribuito sincronizzato. Ogni Stato sostiene l'idea di un limite WIP, qui sopra il numero tra parentesi nel titolo. Develop (2) Stato è attualmente in piena, che è perché è mostrato in rosso.

Riassunto

Kanban è una tecnica di miglioramento dei processi in grado di identificare dei rifiuti e migliorare la reattività di un sistema di produzione. Visualizzando tempo sprecato in coda, identificando i colli di bottiglia, e contribuendo a ridurre il lavoro in progress, kanban permette di lavorare a scorrere rapidamente attraverso un sistema. Se si ' piacerebbe saperne di più su kanban, vi consiglio il libro Kanban: successo cambiamento evolutivo per il tuo Business Technology da David Anderson.