Il sistema Kanban per lo sviluppo agile del software

Il sistema Kanban è stato inventato nell'industria automobilistica giapponese negli anni '40. Ispirandosi al modo in cui i supermercati riforniscono gli scaffali in base alla domanda, l'obiettivo di Toyota era quello di ridurre le scorte e migliorare il flusso in tutto il sistema produttivo. 

Nel suo libro "Kanban: Successful Evolutionary Change for Your Technology Business", David Anderson ha descritto come applicare i principi Kanban allo sviluppo del software. Questi principi sono:

• Iniziare con ciò che si sta facendo ora.
• Concordare cambiamenti incrementali ed evolutivi.
• Rispettare il processo, i ruoli, le responsabilità e i titoli attuali.

Mentre nel nostro articolo precedente "Kanban vs Scrum: 6 motivi per cui Kanban potrebbe essere più adatto" abbiamo parlato dei vantaggi di Kanban rispetto a Scrum, oggi dedichiamo la nostra attenzione totalmente a Kanban entrando un po' più in dettaglio su questo sistema.

 

Che cos'è il sistema Kanban

Kanban è un processo di produzione Just-in-Time (JIT) che si riferisce alla filosofia di produrre o consegnare materiali, componenti o servizi esattamente al momento in cui sono necessari, senza accumulare scorte e riducendo al minimo gli sprechi. Nello sviluppo del software, il sistema Kanban ottimizza il flusso dei lavori in corso ("WiP") in base alla capacità del team di sviluppo.

Un altro pilastro fondamentale di Kanban è che si tratta di un sistema "pull", non "push". Questo significa che vengono eliminati gli sprechi fornendo ciò che è necessario solo quando è richiesto e, di conseguenza, si viene a creare una maggiore flessibilità per il team perché nessuno esegue lavori inutili o basati su ipotesi, consentendo anche di adattarsi ai cambiamenti che possono avvenire durante il processo di sviluppo.

Il concetto centrale di Kanban è quello di mantenere il processo produttivo il più possibile snello e privo di "disordine":

• Migliora l'organizzazione.
• Mantiene la concentrazione.
• Aumenta la produttività mantenendo un "flusso" coerente di attività che sfociano nel prodotto finale.
• Migliora la definizione delle priorità dei compiti, lasciando spazio all'agilità e alla capacità di rispondere rapidamente ai cambiamenti.
• Promuove la collaborazione tra i team.
• Promuove la leadership in tutti i ruoli e a tutti i livelli di gestione.

Kanban è un sistema molto visivo perché si basa sull'uso di schede o segnalatori visivi per rappresentare le attività, i compiti o le unità di lavoro. Il termine "Kanban" deriva infatti da due parole giapponesi: "kan", che significa "visibile" o "carta", e "ban", che significa "segno" o "scheda".

A un team kanban viene assegnato il numero di compiti ottimale per la sua capacità. I membri del team prendono i compiti uno per uno e li spostano il più rapidamente possibile attraverso le varie fasi di completamento (che possono variare a seconda del progetto o dell'organizzazione), da "da fare" a "fatto", prima di passare al compito successivo.

Tutte le schede dei compiti vengono posizionate sulla colonna "da fare" di una lavagna Kanban e poi spostate attraverso le colonne che rappresentano le diverse fasi di completamento. Visualizzando il flusso di lavoro in questo modo, diventa chiaro molto rapidamente se i colli di bottiglia ostacolano l'avanzamento delle attività mentre vengono completate, in modo da poterli affrontare.

La visualizzazione Kanban del backlog delle attività e del flusso di lavoro è una forma di gamification applicata alla produttività e al lavoro di squadra.

 

Che cosa significa Kanban per lo sviluppo Agile?

Fonte: Opensource

Kanban può essere utilizzato come sistema o struttura nell'ambito dell'ampio ombrello dello sviluppo software Agile. Esiste una compatibilità naturale, poiché sia Agile che Kanban mirano ad aiutare i team a trovare l'equilibrio ottimale tra disciplina e adattabilità per soddisfare le richieste del mercato nel modo più efficace possibile. 

L'implementazione di Kanban comporta la definizione di fasi e pratiche che supportano le sei pratiche del metodo:

1. Visualizzazione del flusso di lavoro
2. Limitazione del lavoro in corso (WiP)
3. Controllo dello stato del flusso
4. Definizione esplicita delle linee guida del processo
5. Implementare i cicli di feedback
6. Migliorare insieme, sviluppare in modo sperimentale

La lavagna Kanban è centrale per la maggior parte delle pratiche del sistema, in particolare per la visualizzazione del lavoro, la limitazione del lavoro in corso (WIP) e il controllo del flusso di lavoro. La lavagna Kanban può essere fisica, ma è per lo più utilizzata digitalmente nei team di sviluppo software, soprattutto quando i membri del team lavorano temporaneamente o interamente in altre sedi.

Il lavoro sotto forma di attività (spesso definite come storie utente nei team di sviluppo agile) viene trascinato sulla lavagna Kanban e rappresentato visivamente da tessere colorate. Il numero di compiti trascinati sulla lavagna Kanban deve corrispondere alla capacità del team di sviluppo e limitare di conseguenza il WIP.

Le lavagne sono divise in colonne che rappresentano le diverse fasi di completamento di un compito. La struttura più semplice della lavagna Kanban ha solo tre colonne:

• Da fare
• In corso
• Completato

Tuttavia, spesso ce ne sono di più in base alle caratteristiche e alla complessità del progetto in questione.

Uno degli elementi più importanti per un'implementazione di successo del metodo Kanban, definito come creazione di valore per il cliente/utente finale, è la comprensione del termine "Completato" perché rappresenta il risultato finale desiderato per le attività o i compiti nel sistema..

Il valore di Kanban consiste nel creare e gestire le condizioni per un flusso efficiente di lavoro di alta qualità. Tracciare efficacemente l'avanzamento dei compiti è fondamentale per mantenere il flusso di lavoro. E per misurare efficacemente l'avanzamento di un'attività, è necessario sapere quando è completata.

Spesso nei progetti di lavoro non si ha un quadro chiaro dello stato finale del progetto perché membri del team iniziano a lavorare su compiti o storie utente i cui dettagli finali non sono ancora chiari.

Tuttavia, è necessario definire che cosa significa "completato" per i singoli compiti in modo da poter classificare la loro fine, al fine di evitare il rischio di rimanere "in corso" indefinitamente. Per evitare ciò, è necessario stabilire dei criteri per la definizione di "completato" sia per le singole attività che per i processi.

 

Limitare il lavoro incompiuto e le code

Limitare il work-in-process (WiP) significa stabilire un limite massimo per il numero degli elementi su cui si lavora. Questo limite è chiamato limite di lavoro in corso o limite WiP. 

Fonte: Kanbanize

In questa immagine, gli sviluppatori hanno un massimo di 4 elementi su cui possono lavorare alla volta. Al massimo. Se la loro colonna arriva a contenere 4 elementi, non possono più trascinarli. Questo ha due conseguenze.

In primo luogo, incoraggia le persone a completare il loro lavoro piuttosto che iniziarne altro. Il lavoro iniziato che non viene portato a termine comporta dei rischi. Quanto saranno contenti i vostri clienti se non riuscite a consegnare il software come previsto? Perché avete iniziato a lavorare su tutte quelle grandi idee ma non le avete portate a termine?

La seconda conseguenza della limitazione del work-in-process è che i colli di bottiglia diventano visibili. Se una fase del processo inizia un lavoro che non può essere completato, le persone lo percepiscono immediatamente. Questo perché la fase di processo successiva non sarà in grado di estrarre elementi..

 

Monitorare e migliorare il flusso

Accorgersi dei colli di bottiglia può essere spiacevole. Ma almeno si sa dove sono i problemi principali del processo. E Kanban vi incoraggia a migliorare il flusso eliminando il collo di bottiglia. Un flusso coerente vi permette di consegnare in modo più affidabile, e questo è un bene per tutti i soggetti coinvolti, compresi gli sviluppatori.

Per monitorare il flusso, registra il momento in cui una scheda entra in una fase del processo. E l'ora in cui viene completata la fase del processo. In questo modo si sa quanto tempo trascorre la scheda in ogni fase e in ogni coda tra le fasi.

Sulla base dei dati, è possibile creare metriche per migliorare il flusso. Le metriche più comuni includono:

1. Tempo di ciclo: il tempo necessario a una carta per passare da quando un team inizia a lavorarci (cioè lo sviluppo) a quando viene consegnata (cioè il rilascio). Migliorare questa metrica può aiutare a ridurre il time-to-market.
2. Throughput: il numero di schede che passano attraverso il sistema in un determinato periodo di tempo. Il miglioramento di questa metrica può aiutare a migliorare le prestazioni dell'organizzazione di sviluppo.

Un modo comune per avere una visione d'insieme di quante schede si trovano in una determinata fase del processo nel corso del tempo è quello di utilizzare un diagramma di flusso cumulativo. Idealmente, il numero di carte in ogni fase rimane all'incirca lo stesso nel tempo, ad eccezione dell'ultima carta. Il numero di carte consegnate dovrebbe aumentare. Se il grafico si discosta da questo valore, è possibile che si sia verificato un collo di bottiglia.

 

Lavorare insieme in modo efficace

Le metriche Kanban sono uno strumento potente per analizzare e migliorare il lavoro. Ma sono inutili senza le persone che lavorano. Tutte le persone coinvolte nelle fasi del processo devono essere aperte alla trasparenza che Kanban crea.

Le persone dovrebbero collaborare in modo costruttivo per eliminare i colli di bottiglia, piuttosto che incolpare i singoli. Esaminare regolarmente lo stato attuale. Ci sono colli di bottiglia? C'è troppo o troppo poco lavoro disponibile per una particolare fase del processo? La produttività è sufficiente? Ci sono altre fonti di insoddisfazione? Che cosa deve essere migliorato?

Organizza esperimenti per provare piccole modifiche al sistema. Apporta le modifiche. Verifica in seguito se gli esperimenti hanno funzionato come previsto. Per poter attuare i cambiamenti, spesso è fondamentale il supporto della direzione.

 

Conclusione

L'implementazione del sistema Kanban nello sviluppo Agile del software ha dimostrato di offrire numerosi vantaggi. La combinazione di visualizzazione, limitazione del lavoro incompiuto e approccio pull ha portato a un miglioramento complessivo dell'efficienza, della produttività e della qualità del lavoro svolto. I team che adottano il sistema Kanban possono godere di una maggiore agilità, adattabilità e successo nella realizzazione dei progetti software.

 

Ti potrebbero interessare:

"Il processo di sviluppo di DevInterface"

"Scrum: la pianificazione dello sprint"

"Metodologia Agile: Scrum vs Kanban"

"L'importanza dei test nello sviluppo Agile"

"Kanban: valida alternativa a Scrum per lo sviluppo Agile?"

"Team augmentation: che cos'è e a cosa serve"

"Outsourcing vs offshoring"