Kanban

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.

Sebbene i principi fondamentali del framework siano senza tempo e applicabili a quasi tutti i settori, i team di sviluppo software hanno riscontrato risultati particolarmente interessanti con la pratica Agile. In parte, questo è dovuto al fatto che i team software possono iniziare a esercitarsi con un sovraccarico minimo o nullo una volta compresi i principi di base. A differenza dell'implementazione di Kanban in fabbrica, che comportava modifiche ai processi fisici e l'aggiunta di materiali, gli unici elementi fisici necessari a un team software sono una board e delle schede, e anche queste possono essere virtuali.

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.

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.

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.

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.

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.

La sovrapposizione delle competenze determina durate di ciclo più brevi. Quando solo una persona possiede una serie di competenze, questa diventa un collo di bottiglia nel flusso di lavoro. Quindi, i team utilizzano best practice di base come la revisione del codice e il mentoring per diffondere la conoscenza. Grazie alle competenze condivise, i membri del team possono svolgere un lavoro eterogeneo, ottimizzando ulteriormente la durata di ciclo. Inoltre, se è presente un collo di bottiglia del lavoro, tutto il team può occuparsene affinché il processo riprenda senza intoppi. Ad esempio, i test non vengono eseguiti solo dagli ingegneri del controllo di qualità, ma anche dagli sviluppatori.

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

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.

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.

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.

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

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.