Close

Kanban

Come si applica la metodologia Kanban allo sviluppo software

Sfoglia tra gli argomenti

Che cos'è Kanban?

Kanban è un framework molto diffuso utilizzato per implementare lo sviluppo di software Agile e DevOps. Richiede una comunicazione in tempo reale della capacità e la trasparenza completa del lavoro. Gli elementi di lavoro sono rappresentati visivamente su una board Kanban per consentire ai membri del team di vedere lo stato di ogni lavoro in qualsiasi momento.

Board Jira

Inizia gratuitamente con il modello Kanban di Jira

Usa modello

Articoli su Kanban

[CONTINUA]

Kanban gode di un'enorme popolarità tra i team software Agile e DevOps di oggi, ma questa metodologia di lavoro risale a più di 50 anni fa. Alla fine degli anni '40 Toyota iniziò a ottimizzare i suoi processi ingegneristici sulla base dello stesso modello che i supermercati usavano per rifornire i loro scaffali. I supermercati reintegrano le scorte solo per la quantità di prodotti necessaria per soddisfare la domanda dei consumatori, una pratica che ottimizza il flusso tra il supermercato e l'utente. Poiché i livelli di inventario corrispondono ai modelli di consumo, il supermercato acquisisce una significativa efficienza nella gestione dell'inventario, diminuendo la quantità in eccesso che deve detenere in un dato momento. Nel frattempo, il supermercato può comunque garantire che il prodotto di cui un consumatore ha bisogno sia sempre disponibile.

Quando Toyota ha applicato questo stesso sistema ai suoi stabilimenti, l'obiettivo era quello di allineare meglio gli enormi livelli di scorte con il consumo effettivo di materiali. Per comunicare i livelli di capacità in tempo reale in fabbrica (e ai fornitori), i dipendenti dei vari team si passavano una scheda, o "kanban". Quando un contenitore di materiali utilizzati sulla linea di produzione si svuotava, al magazzino veniva passata una scheda Kanban con la descrizione del materiale necessario, dell'esatta quantità del materiale e così via. Il magazzino aveva in attesa un nuovo contenitore di questo materiale, che avrebbe poi inviato alla fabbrica che, a sua volta, avrebbe inviato la propria scheda Kanban al fornitore. Anche il fornitore aveva un contenitore di questo particolare materiale, in attesa di essere spedito al magazzino. Sebbene la tecnologia di segnalazione di questo processo si sia evoluta rispetto agli anni '40, al centro del sistema vi è ancora lo stesso processo di produzione "just-in-time" (o JIT).

Kanban per i team software

Oggi i team di sviluppo software Agile sono in grado di sfruttare questi stessi principi JIT abbinando la quantità di lavoro in corso (WIP) alla capacità del team. Ciò offre ai team opzioni di pianificazione più flessibili, risultati più rapidi, maggiore chiarezza e trasparenza durante tutto il ciclo di sviluppo.

Board Kanban | Agile Coach Atlassian

While the core principles of the framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice. In part, this is because software teams can begin practicing with little to no overhead once they understand the basic principles. Unlike implementing kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things software teams need are a board and cards, and even those can be virtual.

Board Kanban

Il lavoro di tutti i team Kanban è incentrato sulla board Kanban, uno strumento che consente di visualizzare il lavoro e di ottimizzarne il flusso nell'ambito del team. Mentre le board fisiche sono molto utilizzate da alcuni team, le board virtuali rappresentano una funzione cruciale in qualsiasi strumento di sviluppo software Agile perché offrono tracciabilità, collaborazione più facile e accessibilità da più posizioni.

Indipendentemente dal fatto che la board di un team sia fisica o digitale, la sua funzione è garantire che il lavoro del team sia visualizzato, che il flusso di lavoro sia standardizzato e che tutti i bloccanti e le dipendenze siano immediatamente identificati e risolti. Una board Kanban di base è costituita da un flusso di lavoro in tre passaggi: Da completare, In corso e Completato. Tuttavia, a seconda delle dimensioni, della struttura e degli obiettivi di un team, il flusso di lavoro può essere mappato per soddisfare il processo specifico di un particolare team.

La metodologia Kanban si basa sulla completa trasparenza del lavoro e sulla comunicazione in tempo reale della capacità. Pertanto, la board Kanban dovrebbe essere considerata come l'unica fonte di verità per il lavoro del team.

Board Kanban Agile | Agile Coach Atlassian

Schede Kanban

In giapponese la parola Kanban significa letteralmente "segnale visivo". Per i team Kanban, ogni elemento di lavoro è rappresentato da una scheda diversa sulla board.

Lo scopo principale di rappresentare il lavoro come scheda sulla board Kanban è quello di consentire ai membri del team di tenere traccia dell'avanzamento del lavoro attraverso un flusso di lavoro altamente visivo. Le schede Kanban contengono informazioni critiche su quel particolare elemento di lavoro, offrendo a tutto il team la visibilità completa su chi ne abbia la responsabilità, una breve descrizione del lavoro svolto, il tempo stimato per l'esecuzione di quella parte di lavoro e così via. Le schede delle board Kanban virtuali spesso presentano anche screenshot e altri dettagli tecnici utili per l'assegnatario. Consentire ai membri del team di vedere lo stato di ogni elemento di lavoro in un dato momento, così come tutti i dettagli associati, garantisce maggiore attenzione, tracciabilità completa e identificazione rapida di bloccanti e dipendenze.

I vantaggi di Kanban

Kanban è una delle metodologie di sviluppo software più popolari adottate oggi dai team Agile. Offre diversi vantaggi aggiuntivi per la pianificazione dei task e la produttività dei team di tutte le dimensioni.

Flessibilità di pianificazione

Un team Kanban si concentra solo sul lavoro in corso. Dopo aver completato un elemento di lavoro, il team sceglie quello successivo dalla parte superiore del backlog. L'owner di prodotto può ridefinire liberamente le priorità del lavoro nel backlog senza interrompere le attività del team, perché eventuali modifiche esterne agli elementi di lavoro correnti non hanno alcuna influenza sul team. A condizione che l'owner di prodotto mantenga gli elementi di lavoro più importanti in cima al backlog, il team di sviluppo ha la certezza di fornire il massimo valore all'azienda. Quindi, le iterazioni di durata fissa di Scrum non sono necessarie.

Suggerimento:

Gli owner di prodotto esperti coinvolgono sempre il team di sviluppo quando prendono in considerazione le modifiche al backlog. Ad esempio, se le storie utente da 1 a 6 sono nel backlog, la stima della storia utente 6 potrebbe essere basata sul completamento delle storie utente 1-5. È sempre una buona prassi confermare le modifiche con il team tecnico per avere la certezza che non ci siano sorprese.

Cicli temporali più brevi

La durata ciclo è una metrica chiave per i team Kanban. Indica la quantità di tempo necessaria a un'unità di lavoro per completare l'intero flusso di lavoro del team, dal momento di inizio dell'attività fino al momento del rilascio. Ottimizzando la durata ciclo, il team può prevedere con sicurezza la consegna del lavoro futuro.

Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. So teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a bottleneck of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in, too.

In un framework Kanban, è l'intero team che ha la responsabilità di assicurarsi che il lavoro si svolga in modo fluido durante il processo.

Riduzione dei colli di bottiglia

Il multitasking è la tomba dell'efficienza. Quanto più numerosi sono gli elementi di lavoro in corso in un dato momento, tanto più frequenti saranno i cambiamenti di contesto, che ostacolano il percorso verso il completamento. Ecco perché un principio chiave di Kanban è quello di limitare la quantità di lavoro in corso (WIP). I limiti del lavoro in corso evidenziano colli di bottiglia e backup nel processo del team dovuti alla mancanza di attenzione, di personale o di competenze.

Ad esempio, un tipico team software potrebbe avere quattro stati del flusso di lavoro: Da completare, In corso, Revisione del codice e Completato. Potrebbe scegliere di impostare un limite WIP di 2 per lo stato di revisione del codice. Questo limite, in apparenza basso, è giustificato da una buona ragione: gli sviluppatori spesso preferiscono scrivere nuovo codice, piuttosto che passare il tempo a rivedere il lavoro di un'altra persona. Un limite basso incoraggia il team a prestare particolare attenzione ai problemi nello stato di revisione e a rivedere il lavoro degli altri prima di pubblicare le proprie revisioni del codice, riducendo in ultima analisi la durata ciclo complessiva.

Metriche visive

Uno dei valori fondamentali è una forte attenzione al miglioramento continuo dell'efficienza e dell'efficacia del team a ogni iterazione del lavoro. I diagrammi forniscono ai team un meccanismo visivo per garantire che continuino a migliorare. Quando il team può vedere i dati, è più facile individuare i colli di bottiglia nel processo (e rimuoverli). Due report utilizzati frequentemente dai team Kanban sono i diagrammi di controllo e i diagrammi di flusso cumulativo.

Un diagramma di controllo mostra la durata ciclo per ogni ticket nonché una media mobile per il team.

Suggerimento:

L'obiettivo del team è ridurre il tempo impiegato dal ticket per completare tutte le fasi del processo. Una riduzione della durata ciclo media nel diagramma di controllo è un indicatore di successo.

Diagramma di controllo Agile | Agile Coach Atlassian

Un diagramma di flusso cumulativo mostra il numero di ticket per ogni stato. Il team può individuare facilmente i bloccanti visualizzando l'aumento del numero di ticket in un determinato stato. I ticket negli stati intermedi come "Da completare" o "In revisione" non sono ancora stati rilasciati ai clienti e un bloccante in questi stati può aumentare la probabilità di enormi conflitti di integrazione quando il lavoro viene unito a monte.

Diagramma del flusso cumulativo

Produzione continua

La continuous delivery (CD) è la pratica di effettuare rilasci di lavoro frequenti ai clienti. La continuous integration (CI) è la pratica di creare e testare automaticamente il codice in modo incrementale nel corso della giornata. Insieme, formano una pipeline CI/CD che è essenziale affinché i team di sviluppo (in particolare i team DevOps) possano distribuire il software più velocemente, garantendo allo stesso tempo una qualità elevata.

Kanban e CD si completano a vicenda perché entrambe le tecniche si concentrano sulla consegna di valore just-in-time (e un passo alla volta). Quanto più velocemente un team è in grado di fornire innovazione al mercato, tanto più competitivo sarà il suo prodotto sul mercato. E i team Kanban si concentrano proprio su questo: ottimizzare il flusso di lavoro verso i clienti.

Scrum e Kanban a confronto

Kanban e Scrum hanno in comune alcuni concetti, ma utilizzano approcci molto diversi. Non vanno confusi.

Scrum

Kanban
Cadenza

Sprint regolari di durata fissa (ad es. 2 settimane)

Flusso continuo
Metodologia di rilascio Alla fine di ogni sprint se approvato dall'owner di prodotto Continuous delivery o a discrezione del team
Ruoli Owner di prodotto, Scrum Master, team di sviluppo Nessun ruolo esistente. Alcuni team si avvalgono dell'aiuto di un Agile Coach.
Metriche chiave Velocity Durata ciclo
Filosofia delle modifiche I team dovrebbero cercare di non apportare modifiche alle previsioni dello sprint durante lo sprint; questo per evitare di compromettere le informazioni sulla stima. Le modifiche possono essere effettuate in qualsiasi momento

Alcuni team uniscono gli ideali di Kanban e Scrum in "scrumban". Utilizzano sprint di durata fissa e i ruoli di Scrum e si concentrano sui limiti del lavoro in corso e sulla durata ciclo di Kanban. Ai team che hanno appena iniziato a utilizzare Agile, tuttavia, consigliamo vivamente di scegliere una delle due metodologie e di utilizzarla per un po' di tempo. Puoi sempre decidere di passare a qualcosa di nuovo in un secondo momento.

Board Jira

Inizia gratuitamente con il modello Kanban di Jira

Usa modello
Dan Radigan
Dan Radigan

L'approccio Agile ha avuto un impatto enorme su di me sia a livello professionale che a livello personale perché ho imparato che le migliori esperienze sono agili, sia nel codice che nella vita. I miei interessi includono la tecnologia, la fotografia e il motociclismo. 

Prossimo contenuto
Boards