Kanban e Scrum a confronto: qual è il tuo modello Agile?

Riepilogo: Kanban è un framework di gestione dei progetti che utilizza task visivi per gestire i flussi di lavoro, mentre Scrum è un framework di gestione dei progetti che aiuta i team a strutturare e gestire il proprio lavoro attraverso un insieme di valori, principi e pratiche.

Agile è un insieme di ideali e principi che fungono da stella polare. DevOps è un modo per automatizzare e integrare i processi tra lo sviluppo software e i team operativi. Quando si tratta di implementare Agile e DevOps, Kanban e Scrum forniscono diverse metodologie per farlo.

È facile indicare le differenze tra le pratiche Scrum e le pratiche Kanban, ma la diversità esiste solo a un livello superficiale. Sebbene le pratiche siano diverse, i principi sono sostanzialmente gli stessi. Entrambi i framework aiutano a creare prodotti (e servizi) migliori con meno problemi.

Dunque, dove eravamo rimasti?

Agile è un approccio strutturato e iterativo alla gestione dei progetti e allo sviluppo dei prodotti. Riconosce la volatilità dello sviluppo dei prodotti e fornisce ai team che si organizzano autonomamente una metodologia che consente di rispondere ai cambiamenti senza stravolgere i piani. Oggi, l'agilità non è un vantaggio competitivo. Nessuno può permettersi il lusso di sviluppare un prodotto per anni o addirittura per mesi in una "scatola nera". Ciò significa che è più importante che mai affrontarla bene.

Kanban riguarda essenzialmente la visualizzazione del lavoro, la limitazione del lavoro in corso e l'ottimizzazione dell'efficienza (o del flusso). I team Kanban si concentrano sulla riduzione del tempo richiesto da un progetto (o dalla storia utente) dall'inizio alla fine. A tale scopo utilizzano una board Kanban e migliorano continuamente il flusso di lavoro.

I team Scrum si impegnano a completare un incremento di lavoro, potenzialmente rilasciabile, attraverso intervalli prestabiliti definiti sprint, con l'obiettivo di creare cicli di apprendimento per raccogliere e integrare rapidamente il feedback dei clienti. I team Scrum adottano ruoli specifici, creano artefatti speciali e organizzano cerimonie regolari per far procedere il lavoro. La Guida Scrum fornisce la migliore definizione di Scrum.

Qualunque sia il framework di gestione dei progetti più indicato per le tue esigenze, abbiamo modelli Jira che ti aiutano a iniziare a utilizzarlo rapidamente. Dai un'occhiata al nostro modello Scrum o al nostro modello di board Kanban: sono entrambi gratuiti.

Con Scrum, il tuo team promette di rilasciare un valido incremento di lavoro entro la fine di ogni sprint. Scrum si basa sull'empirismo, concentrandosi su piccoli incrementi di lavoro che ti aiuteranno ad apprendere dai tuoi clienti e a informare meglio i passi successivi. Ecco come si suddivide:

Scrum è veloce, con sprint che di solito durano da una a quattro settimane e date di inizio e fine chiare. Il breve lasso di tempo impone la suddivisione di task complessi in story più piccole e aiuta il tuo team a imparare velocemente. Ecco una domanda chiave: il tuo team può rilasciare codice utilizzabile così velocemente?

Gli sprint sono punteggiati da riunioni di pianificazione degli sprint, revisione degli sprint e retrospettiva e costellati da riunioni Scrum quotidiane (riunioni stand-up). Queste cerimonie Scrum sono leggere e vengono eseguite su base continua.

Scrum ha tre ruoli definiti in modo chiaro.

• L'owner di prodotto è sostenitore del cliente, gestisce il backlog di prodotto e aiuta a definire le priorità del lavoro svolto dal team di sviluppo.
• Lo Scrum Master assicura il rispetto dei principi Scrum.
• Il team di sviluppo sceglie il lavoro da svolgere, fornisce incrementi e dimostra responsabilità collettiva.

Chi gestisce il team Scrum? In realtà, nessuno. I team Scrum si organizzano in modo autonomo e i suoi membri sono tutti a pari livello, pur avendo responsabilità diverse. Il team è unito dall'obiettivo di offrire valore ai clienti.

Le metriche Scrum sono punti dati che i team Scrum possono utilizzare per migliorare l'efficienza e l'efficacia. Possono informare il processo decisionale e aiutare i team a diventare più efficienti nella pianificazione e nell'esecuzione. Durante la fase di pianificazione dello sprint, i team possono utilizzare metriche come obiettivi dello sprint, velocity del team, capacità del team e tipo di lavoro. Durante le riunioni stand-up, i team possono anche trarre vantaggio dalla misurazione dell'avanzamento verso gli obiettivi dello sprint, dalla revisione del burn-down dello sprint, dalla comprensione della distribuzione del carico di lavoro e da molto altro.

I team si sforzano di capire quanto lavoro possono portare a termine entro i limiti di tempo dello sprint e si impegnano a completare il lavoro entro tale sprint. Tuttavia, i team Scrum possono ricevere feedback dai clienti che li spingono a cambiare direzione e modificare lo sprint per offrire il massimo valore ai clienti. Durante la retrospettiva sprint, i team Scrum dovrebbero discutere su come limitare i cambiamenti in futuro, poiché le modifiche mettono a rischio l'incremento di lavoro potenzialmente rilasciabile. Se un team cambia spesso ambito a metà sprint, potrebbe significare che è stato selezionato un lavoro che non è stato adeguatamente compreso. Potrebbe anche significare che il team deve svolgere anche un lavoro operativo/non pianificabile che interferisce con il piano.

Per ulteriori informazioni sulle metodologie Scrum, vedi Che cos'è Scrum?

Kanban ti aiuta a visualizzare il tuo lavoro, a limitare il lavoro in corso (WIP) e a spostare rapidamente il lavoro dallo stato "Da completare" a "Completato".

Kanban è eccellente per i team che ricevono molte richieste diverse in termini di priorità e dimensioni. Mentre i processi Scrum richiedono un elevato controllo su ciò che è incluso nell'ambito, con Kanban puoi seguire il flusso. Diamo un'occhiata alle stesse cinque considerazioni per aiutarti a decidere.

Kanban si basa su una struttura continua del flusso di lavoro che mantiene i team agili e pronti ad adattarsi alle priorità in continuo cambiamento. Gli elementi di lavoro, rappresentati da schede, sono organizzati in una board Kanban, dove si spostano da una fase del flusso di lavoro (colonna) a quella successiva. Le fasi del flusso di lavoro più comuni sono Da completare, In corso, In revisione, Bloccato e Completato. Ma non è questo l'aspetto interessante.

L'aspetto migliore di Kanban è la creazione di colonne personalizzate in base al modo di lavorare del tuo team. Il mio team rilascia contenuti, quindi le nostre colonne (semplificate) includono Backlog, Con priorità, Bozze pronte, Scrittura, Progettazione, Revisione tecnica e Rilasciato. La nostra board ci ha aiutati a capire che rilasciamo circa un contenuto a settimana e a individuare i colli di bottiglia (grazie alla revisione tecnica).

In Kanban, gli aggiornamenti vengono rilasciati ogni volta che sono pronti, senza una programmazione regolare o date di scadenza predeterminate.

In teoria, Kanban non impone una tempistica fissa per la consegna di un task. Se il task viene completato in anticipo (o più tardi), può essere rilasciato in base alle esigenze senza dover attendere una milestone di rilascio come la revisione sprint.

L'intero team è responsabile della board Kanban. Alcuni team ingaggiano un Agile Coach; tuttavia, a differenza di Scrum, non esiste un singolo "Kanban Master" che garantisca un'esecuzione fluida di tutte le fasi. È una responsabilità collettiva dell'intero team collaborare ed eseguire i task indicati nella board.

Il lead time e la durata ciclo sono metriche importanti per i team Kanban. Riguardano il tempo medio necessario affinché un task completi l'intero ciclo. Il miglioramento della durata ciclo indica il successo dei team Kanban.

Il diagramma di flusso cumulativo (CFD) è un altro strumento analitico utilizzato dai team Kanban per comprendere il numero di elementi di lavoro in ogni stato. I CFD aiutano a identificare colli di bottiglia specifici che devono essere risolti per migliorare la produttività.

Un altro modo per affrontare i colli di bottiglia prevede l'uso dei limiti del lavoro in corso (WIP). Un limite WIP applica un numero massimo di schede che possono trovarsi in una specifica colonna alla volta. Quando raggiungi il limite WIP, uno strumento come Jira chiude quella colonna e il team si occupa di quegli elementi per spostarli in avanti.

Un flusso di lavoro Kanban può cambiare in qualsiasi momento. Nuovi elementi di lavoro possono essere aggiunti al backlog e le schede esistenti possono essere bloccate o rimosse in base alle priorità definite. Inoltre, se la capacità del team cambia, il limite WIP può essere ricalibrato e gli elementi di lavoro modificati di conseguenza. L'essenza di Kanban è la flessibilità.

Per ulteriori informazioni sulle metodologie Kanban, vedi Che cos'è Kanban?

La comunità Agile è convinta che questa conversazione non debba riguardare gli strumenti. Spesso accade che sia lo strumento scelto a guidare il framework scelto e che quest'ultimo guidi i principi adottati dal team. Noi crediamo che la decisione debba andare nella direzione opposta.

Se hai scelto i principi Scrum e sei soddisfatto del framework Scrum, devi trovare uno strumento Scrum adeguato alle tue esigenze. Lo stesso vale per Kanban. Siamo di parte, ma visto che è lo strumento di sviluppo software numero 1 utilizzato dai team Agile, pensiamo che Jira sia ciò che fa per te.

Con i tipi di progetto dedicati di Jira per Scrum e Kanban puoi attuare i principi di ogni framework. Inoltre, siamo a tua disposizione per aiutarti a muovere i primi passi con le nostre guide su come utilizzare Scrum con Jira e come utilizzare Kanban con Jira.

Scrum e Kanban sono "Agile secondo le regole". Funzionano in un modo autentico e collaudato che è francamente difficile confutare. Riprendendo un altro famoso slogan, si potrebbe dire che "nessuno viene licenziato per aver scelto Scrum".

Ma non è necessario che la tua decisione sia bianco o nero. Centinaia di team utilizzano modelli ibridi influenzati sia da Scrum che da Kanban. Abbiamo deciso di aiutare i team a operare in questo modo in Jira, motivo per cui abbiamo creato progetti gestiti dal team.

I progetti gestiti dal team, come suggerisce il nome stesso, consentono ai team di scegliere le funzioni Agile che hanno senso per loro, che si tratti di Scrum, Kanban o di una combinazione di entrambi. Invece di implementare un unico framework il primo giorno, i progetti gestiti dal team consentono di sovrapporre progressivamente funzioni sempre più potenti man mano che scopri cosa funziona (e cosa non funziona) per il tuo team.

Puoi scegliere con fiducia Scrum gestito dal team o Kanban gestito dal team sapendo che entrambi i modelli possono evolversi per soddisfare le esigenze del tuo team.

A prescindere dalla tua scelta, portala avanti per un po' di tempo. Prendi del lavoro dal backlog, portalo a termine e poi chiedi al tuo team cosa è andato bene e cosa è andato male. Provando Scrum e Kanban e ponendo queste domande, sei sulla buona strada per raggiungere la beatitudine Agile.