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 lo stato 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 che Kanban punta principalmente attraverso le bacheche Kanban. Queste schede usano schede 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 eseguono il push del lavoro sui team che stanno già lavorando alla capacità. Al contrario, gli stakeholder aggiungono richieste a un backlog che un team effettua il pull 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 il lavoro non viene fatto, causando tempi di lead inaccettabili. 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 assicura di non superare il limite wip. Se i team superano i limiti wip, esaminano il motivo e lavorano per risolvere la causa radice.

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.

Bacheche Kanban

La lavagna Kanban è uno degli strumenti usati dai team per implementare le procedure 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.

Schede kanban basate sullo sviluppo software che corrispondono agli elementi di 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 Windows Information Protection non si applicano alle prime e alle ultime colonne, perché tali colonne rappresentano operazioni che non sono state avviate o completate. Le bacheche Kanban aiutano i team a rimanere entro i limiti di WIP attirando l'attenzione sulle colonne che superano i limiti. Teams può quindi determinare un corso di 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 le tendenze nel tempo, inclusi colli di bottiglia e altre interruzioni alla velocità di avanzamento. Un buon CFD mostra una tendenza verso l'alto coerente mentre un team sta lavorando a un progetto. Le aree colorate nel grafico devono essere approssimativamente parallele se il team sta lavorando entro i limiti wip.

Unbulge in una o più aree colorate indica in genere un collo di bottiglia o un ostacolo nel flusso del team. Nel CFD seguente, il lavoro completato in verde è piatto, mentre lo stato di test in blu è in crescita, probabilmente a causa di un collo di bottiglia.

Kanban e Scrum nello sviluppo Agile

Sebbene sia ampiamente adattata sotto l'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.