Scrum Guide | 33. Scrumban e bacheche Kanban in Scrum

Scrum e Kanban sono metodi di lavoro di squadra che condividono molte somiglianze. Tuttavia, ci sono anche differenze di cui ci piacerebbe discutere oggi. Le bacheche Kanban sono spesso adottate anche dai Team Scrum. Questo perché sono molto pratiche per visualizzare il lavoro di squadra e il suo progresso. Combinando il meglio di entrambe le metodologie, è emersa una tecnica chiamata Scrumban. È popolare in progetti che combinano lo sviluppo del prodotto con la fornitura di servizi, dove Sprint lunghi e riunioni Scrum relativamente formalizzate non sono sempre adatte.

Scrumban e bacheche Kanban in Scrum – indice:

1. Introduzione
2. Kanban vs Scrum
3. Bacheche Kanban in Scrum
4. Scrumban
5. Riepilogo

Introduzione

Kanban è un metodo pionieristico in Giappone. È nato negli anni ’50 ed era principalmente uno strumento per gestire la produzione continua in modo da non creare inventari e surplus, ma per elaborare le risorse in modo continuo. All’inizio del 21° secolo, Kanban è stato adattato alle esigenze dello sviluppo software da David J. Anderson.

Kanban vs Scrum

Il modo complessivo di lavorare in Kanban differisce da Scrum principalmente per portare a un approccio meno formale. In Kanban, non ci sono linee guida così dettagliate su, ad esempio, il lavoro in Sprint, i ruoli di Product Owner, Scrum Master e Development Team. Questo è possibile perché Kanban si concentra sulla continuità delle attività come fornire un tipo specifico di servizio, che sono più ripetibili e non richiedono una pianificazione così complessa.

Tuttavia, lo scopo e i modi di lavorare sono simili. L’obiettivo di Kanban è fornire il prodotto di massima qualità al cliente in tempo. I principi riguardanti i modi di lavorare comuni a entrambi i metodi possono essere formulati come segue:

1. Il lavoro dovrebbe essere fluido e senza tempi morti – in Scrum, questo è raggiunto dalla successione continua di Sprint, mentre in Kanban il lavoro è continuo grazie al flusso regolare delle attività. Esse formano una coda, dalla quale gli sviluppatori scelgono (pull) alcune attività da completare.
2. Il team dovrebbe concentrarsi solo su attività selezionate – usando la terminologia Kanban, il team dovrebbe “ridurre il lavoro in corso”. In Scrum, l’equivalente di questo sono le User Stories scelte dal Product Backlog da inserire nel Sprint Backlog.
3. Il progresso delle attività dovrebbe essere visibile a tutte le persone coinvolte – in Kanban sono visualizzate tramite bacheche, che sono spesso presenti anche nei Team Scrum.

Bacheche Kanban in Scrum

Una bacheca Kanban è uno strumento ampiamente utilizzato per visualizzare il lavoro di squadra. È una tabella con diverse colonne. In ognuna di esse, ci sono attività con uno stato specifico. La categorizzazione delle attività si basa su una semplice regola: una scheda con la descrizione dell’attività – o il suo equivalente virtuale – è collocata in una delle colonne. La versione minima delle bacheche Kanban contiene tre colonne:

• Da fare
• In corso
• Completato – nell’ultima colonna vanno le attività che soddisfano la Definizione di Completamento, di cui abbiamo scritto qui.

Di seguito puoi trovare un esempio di una bacheca kanban di un sistema di gestione progetti all-in-one – Firmbee.com

Comuni, ci sono più colonne. Se ci sono più attività da completare, di solito c’è un’ulteriore colonna intitolata “selezionate per completamento” tra le colonne “da completare” e “in corso”. Mentre la colonna “da fare” funge da Product Backlog, di cui abbiamo scritto qui, la colonna “selezionate per completamento” funge da Sprint Backlog, che descriviamo in dettaglio in questo articolo.

La seconda aggiunta comune è una colonna “in revisione” o “per approvazione”. Di solito è inserita tra le colonne contenenti le attività “in corso” e quelle “completate”. Contiene attività completate dal Development Team che è in attesa di approvazione da parte del Product Owner. Il compito del Product Owner è verificare la loro conformità ai criteri di accettazione e ottenere la loro approvazione finale dal Cliente. In questa situazione, solo le attività finalmente accettate vengono spostate nell’ultima colonna.

Scrumban

Grazie alla grande popolarità di Scrum e Kanban, è apparso il loro ibrido, che combina il meglio di entrambi i modi di lavorare. Scrumban funziona meglio nelle organizzazioni che collegano la creazione di Prodotti con la fornitura di servizi, spesso coinvolgendo l’implementazione del Prodotto presso il Cliente. A causa della riduzione delle riunioni e della comunicazione, il Team può essere più grande.

Scrumban pone meno enfasi sulle metriche comunemente utilizzate in Scrum, come il Burndown Chart. Tuttavia, utilizza i pilastri di Scrum della necessità di miglioramento continuo del processo di lavoro e di adattamento alle condizioni e ai bisogni del cliente.

Quando si lavora in Scrumban, tuttavia, il lavoro non è suddiviso in Sprint. Le riunioni Scrum si tengono ogni 3, 6 o 12 mesi.

La pianificazione del lavoro segue il principio “On-Demand”, cioè come si presenta. Le User Stories vengono collocate direttamente nella prima colonna della bacheca Kanban contenente attività “da fare”. Così, funge da Sprint Backlog, di cui abbiamo scritto in modo più dettagliato in questo articolo. Come nello Sprint Backlog, le attività più urgenti sono collocate in cima alla lista delle cose da fare. Tuttavia, per progetti più complessi, il Project Manager può mantenere un elenco separato di cose da fare corrispondente al Product Backlog, da cui seleziona quali attività inserire nella prima colonna.

Quando si spostano le attività dalla prima alla seconda colonna, si applica la regola “Pull”. Significa che le attività non sono delegate a un particolare Sviluppatore. Ogni persona sceglie un’attività dalla coda e la esegue in modo indipendente.

Il numero di attività collocate nella colonna centrale, “da completare” è solitamente limitato a seconda delle dimensioni del team, in modo che, se possibile, tutti si occupino di una sola attività alla volta.

Riepilogo

Scrum e Kanban, sebbene utilizzati per scopi simili, sono modi di lavorare diversi. Scrum funziona meglio in progetti creativi e innovativi realizzati da piccoli Team Scrum. Kanban, d’altra parte, è stato creato per operare in un ambiente continuo e senza tempi morti per fornire servizi simili. Scrum utilizza spesso le bacheche Kanban come metodo per visualizzare il lavoro svolto. La combinazione di entrambi ha portato a Scrumban, che funziona meglio come framework per le organizzazioni che vendono i loro prodotti e forniscono servizi basati su di essi al cliente.

Se ti piace il nostro contenuto, unisciti alla nostra comunità di api laboriose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.