Scrum o Kanban

Scrum e Kanban sono i due metodi agili che i team confrontano più spesso. Entrambi rendono visibile il lavoro ed entrambi puntano a consegnare a piccoli pezzi. Differiscono nel modo in cui danno il ritmo al lavoro: Scrum pianifica in blocchi di tempo fissi, Kanban tira il lavoro in modo continuo e limita quanto ce n’è in corso allo stesso tempo.

Questa pagina li mette a confronto. Per la famiglia più ampia, inclusi XP e Lean, vedi Cos’è lo sviluppo agile?.

Scrum in breve

Scrum organizza il lavoro in sprint: blocchi di tempo fissi, di solito da una a quattro settimane. Ogni sprint inizia con lo sprint planning, in cui il team sceglie il lavoro che prevede di completare, e si chiude con una review di ciò che è stato costruito e una retrospettiva su come ha lavorato il team.

Scrum definisce tre ruoli:

• Product Owner — è responsabile del product backlog e del suo ordine.
• Scrum Master — guida il team nel processo e rimuove gli ostacoli.
• Developer — costruiscono l’incremento.

La misura principale è la velocity: quanto lavoro il team completa per sprint, che alimenta il piano dello sprint successivo. Vedi Cos’è la velocity?.

Kanban in breve

Kanban parte dal flusso di lavoro che il team ha già. Gli elementi di lavoro attraversano una board di colonne che rappresentano le fasi (per esempio Da fare → In corso → Review → Fatto). Tre idee reggono il metodo:

• Visualizzare il flusso di lavoro — ogni elemento e ogni fase sono sulla board.
• Limitare il lavoro in corso (WIP) — ogni colonna ha un tetto; un nuovo elemento entra solo quando un altro esce.
• Gestire il flusso — il team misura quanto tempo richiedono gli elementi (cycle time, lead time) e rimuove i colli di bottiglia.

Kanban non ha blocchi di tempo e non prescrive ruoli. La pianificazione avviene ogni volta che la coda va riempita di nuovo.

Fianco a fianco

	Scrum	Kanban
Cadenza	Sprint fissi (1–4 settimane)	Flusso continuo
Impegno	Il lavoro pianificato per lo sprint	Nessun impegno a lotti; si tira il lavoro quando c’è capacità
Ruoli	Product Owner, Scrum Master, Developer	Nessuno prescritto
Cambiamenti a metà ciclo	Sconsigliati all’interno di uno sprint	Ammessi in qualsiasi momento
Limitazione del lavoro	La capacità dello sprint	Limite WIP per colonna
Metriche principali	Velocity, burndown	Cycle time, lead time, throughput
Board	Azzerata a ogni sprint	Persistente

Scegliere tra i due

Nessuno dei due metodi è migliore in assoluto. Scrum si adatta ai team che vogliono un ritmo di pianificazione regolare e una previsione basata sugli sprint passati, come i team di prodotto che rilasciano funzionalità secondo un calendario. Kanban si adatta al lavoro che arriva in modo imprevedibile e va gestito man mano che si presenta, come supporto, operations o manutenzione.

Molti team combinano i due (“Scrumban”): mantengono una cadenza di pianificazione e tengono d’occhio anche quanto lavoro è in corso.

Dove si colloca East Agile Tracker

East Agile Tracker è basato sulle iterazioni, il che lo avvicina più a Scrum e all’eXtreme Programming che a Kanban. Usa termini propri per alcuni dei concetti visti sopra:

• Gli sprint si chiamano iterazioni. Ogni progetto imposta una durata dell’iterazione da 1 a 4 settimane. Le iterazioni vengono create automaticamente; non c’è nessuno sprint da aprire o chiudere. Vedi Iterazioni.
• Il backlog è un unico elenco ordinato. Il product owner lo mantiene in rigoroso ordine di priorità, e il Backlog proietta le iterazioni future a partire dalla velocity. Vedi User story e pianificazione dell’iterazione.
• La velocity dimensiona il piano. Con auto-plan iterations attivo, l’iterazione corrente si riempie fino alla tua velocity e non oltre. Vedi Pianificare un’iterazione.
• Ogni storia porta con sé il proprio stato. Una storia passa per Unstarted → Started → Finished → Delivered → Accepted, mostrato sulla card, invece di spostarsi tra colonne della board. Vedi la macchina a stati.

Non ci sono limiti WIP né una modalità a flusso senza iterazioni. Le idee di Kanban che si ritrovano qui sono la visibilità (ogni storia e il suo stato sono su un’unica board) e le metriche di flusso: la pagina Metriche mostra l’andamento della velocity, il burndown e le storie riportate da un’iterazione all’altra.

Per approfondire

• Cos’è lo sviluppo agile? — il manifesto e la famiglia di metodi.
• Cos’è la velocity? — come la velocity viene calcolata e usata.
• Cosa sono gli story point? — la stima relativa.