Che cos'è Kanban?

Kanban è un termine giapponese che significa cartellone o cartellone. Un ingegnere industriale di nome Taiichi Ohno ha sviluppato Kanban presso Toyota Motor Corporation per migliorare l'efficienza produttiva.

Anche se Kanban è stato creato per la produzione, lo sviluppo di software condivide molti degli stessi obiettivi, ad esempio l'aumento del flusso e della velocità effettiva. I team di sviluppo software possono migliorare l'efficienza e offrire valore agli utenti più velocemente usando i principi e i metodi guida kanban.

Principi Kanban

L'adozione di Kanban richiede l'adesione ad alcune procedure fondamentali che possono variare dai metodi precedenti dei team.

Visualizzare il lavoro

Comprendere lo stato del team di sviluppo e l'avanzamento del lavoro può essere difficile. Lo stato di avanzamento del lavoro e lo stato corrente sono più facili da comprendere quando vengono presentati visivamente anziché come un elenco di elementi di lavoro o un documento.

La visualizzazione del lavoro è un principio chiave su cui Kanban si concentra principalmente attraverso le bacheche Kanban. Questi pannelli utilizzano carte organizzate in base allo stato di avanzamento per comunicare lo stato complessivo. La visualizzazione del lavoro come schede in stati diversi in una lavagna consente di visualizzare facilmente il quadro generale di dove un progetto è attualmente in piedi, nonché identificare potenziali colli di bottiglia che potrebbero influire sulla produttività.

Usare un modello pull

Storicamente, gli stakeholder hanno richiesto funzionalità spingendo il lavoro nei team di sviluppo, spesso con scadenze limitate. La qualità ha sofferto se i team hanno dovuto prendere scorciatoie per fornire la funzionalità entro l'intervallo di tempo.

Kanban si concentra sul mantenimento di un livello di qualità concordato che deve essere soddisfatto prima di considerare il lavoro svolto. Per supportare questo modello, gli stakeholder non spingono lavoro sui team che stanno già operando al massimo delle loro capacità. Al contrario, gli stakeholder aggiungono richieste a un elenco di attività arretrate che un team integra nel flusso di lavoro man mano che la capacità diventa disponibile.

Imporre un limite WIP

I team che provano a lavorare su troppe cose contemporaneamente possono soffrire di una riduzione della produttività a causa del cambio di contesto frequente e costoso. Il team è occupato, ma non si riesce a completare il lavoro, risultando in tempi di attesa inaccettabilmente alti. La limitazione del numero di elementi di backlog su cui un team può lavorare in un momento consente di aumentare lo stato attivo riducendo il cambio di contesto. Gli elementi su cui sta lavorando il team sono chiamati lavoro in corso (WIP).

I team decidono un limite wip o il numero massimo di elementi su cui possono lavorare contemporaneamente. Un team ben disciplinato si assicura di non superare il limite WIP. Se i team superano i limiti WIP, esaminano il motivo e lavorano per risolvere la causa principale.

Misurare il miglioramento continuo

Per praticare il miglioramento continuo, i team di sviluppo hanno bisogno di un modo per misurare l'efficacia e la velocità effettiva. Le bacheche Kanban offrono una visualizzazione dinamica degli stati di lavoro in un flusso di lavoro, in modo che i team possano sperimentare i processi e valutare più facilmente l'impatto sui flussi di lavoro. I team che adottano Kanban per il miglioramento continuo usano misurazioni come il lead time e il tempo del ciclo.

Lavagne Kanban

La lavagna Kanban è uno degli strumenti usati dai team per implementare le pratiche Kanban. Una scheda Kanban può essere una scheda fisica o un'applicazione software che mostra le schede disposte in colonne. I nomi di colonna tipici sono To-do, Doing e Done, ma i team possono personalizzare i nomi in modo che corrispondano ai relativi stati del flusso di lavoro. Ad esempio, un team potrebbe preferire l'uso di New, Development, Testing, UAT e Done.

I board Kanban basati sullo sviluppo software mostrano schede che corrispondono agli elementi del backlog del prodotto. Le schede includono collegamenti ad altri elementi, ad esempio attività e test case. Teams può personalizzare le schede in modo da includere informazioni rilevanti per il processo.

In una scheda Kanban, il limite WIP si applica a tutte le colonne in corso. I limiti di Work In Progress (WIP) non si applicano alle prime e alle ultime colonne, perché tali colonne rappresentano lavori che non sono stati avviati o completati. Le bacheche Kanban aiutano i team a rimanere entro i limiti di WIP attirando l'attenzione sulle colonne che superano i limiti. I team possono quindi determinare un corso d'azione per rimuovere il collo di bottiglia.

Diagrammi di flusso cumulativi

Un'aggiunta comune alle schede Kanban basate sullo sviluppo software è un grafico denominato diagramma di flusso cumulativo (CFD). Il CFD illustra il numero di elementi in ogni stato nel tempo, in genere tra diverse settimane. L'asse orizzontale mostra la sequenza temporale, mentre l'asse verticale mostra il numero di elementi di backlog del prodotto. Le aree colorate indicano gli stati o le colonne in cui si trovano le schede.

Il CFD è particolarmente utile per identificare tendenze nel tempo, compresi i colli di bottiglia e altre interruzioni che influenzano la velocità di avanzamento. Un buon CFD mostra una tendenza verso l'alto coerente mentre un team sta lavorando a un progetto. Le aree colorate attraverso il grafico dovrebbero essere all'incirca parallele se il team sta lavorando entro i limiti WIP.

Una sporgenza in una o più aree colorate indica in genere un collo di bottiglia o un ostacolo nel flusso del team. Nel seguente Diagramma di Flusso Cumulativo (CFD), il lavoro completato, indicato in verde, rimane costante, mentre lo stato di test, indicato in blu, sta aumentando, probabilmente dovuto a un collo di bottiglia.

Kanban e Scrum nello sviluppo Agile

Sebbene sia ampiamente adattato nell’ambito dello sviluppo Agile, Scrum e Kanban sono piuttosto diversi.

• Scrum è incentrato sugli sprint a lunghezza fissa, mentre Kanban è un modello di flusso continuo.
• Scrum ha definito ruoli, mentre Kanban non definisce alcun ruolo del team.
• Scrum usa la velocità come metrica chiave, mentre Kanban usa il tempo del ciclo.

I team adottano in genere aspetti di Scrum e Kanban per aiutarli a lavorare in modo più efficace. Indipendentemente dalle caratteristiche scelte, i team possono sempre rivedere e adattarsi fino a quando non trovano la scelta migliore. I team devono iniziare in modo semplice e non perdere di vista l'importanza di offrire valore regolarmente agli utenti.

Kanban con GitHub

GitHub offre un'esperienza Kanban tramite schede di progetto (versione classica). Queste bacheche consentono di organizzare e classificare in ordine di priorità il lavoro per lo sviluppo di funzionalità specifiche, le roadmap complete o gli elenchi di controllo delle versioni. È possibile automatizzare le bacheche di progetto (versione classica) per sincronizzare lo stato della scheda con i problemi associati e le richieste pull.

Kanban con Azure Boards

Azure Boards offre una soluzione Kanban completa per la pianificazione di DevOps. Azure Boards offre un'integrazione approfondita in Azure DevOps e può anche far parte dell'integrazione di Azure Boards-GitHub.

• Per altre informazioni, vedere Motivi per l'uso di Azure Boards per pianificare e tenere traccia del lavoro.
• Il modulo Learn Scegliere un approccio Agile allo sviluppo di software offre un'esperienza Kanban pratica in Azure Boards.