Guida Scrum | 33. Board Scrumban e Kanban in Scrum

Scrum e Kanban sono metodi di lavoro di squadra che condividono molte somiglianze. Tuttavia, ci sono anche differenze di cui vorremmo discutere oggi. Le bacheche Kanban sono spesso adottate anche dagli Scrum Team. Questo perché sono molto pratici nel visualizzare il lavoro di squadra e il suo progresso. Combinando il meglio di entrambe le metodologie, è apparsa una tecnica chiamata Scrumban. È popolare nei progetti che combinano lo sviluppo del Prodotto con l'erogazione del servizio, dove gli Sprint lunghi e le riunioni Scrum relativamente formalizzate non sono sempre adatte.

Bacheche Scrumban e Kanban in Scrum – Sommario:

1. introduzione
2. Kanban vs Scrum
3. Tavole Kanban in Scrum
4. Scruban
5. Riepilogo

introduzione

Kanban è un metodo sperimentato in Giappone. Nato negli anni '50 , era principalmente uno strumento per gestire la produzione continua in modo da non creare scorte e eccedenze, ma elaborare risorse in modo continuativo. All'inizio del 21° secolo Kanban è stato adattato alle esigenze dello sviluppo del software da David J. Anderson.

Kanban vs Scrum

Il modo generale di lavorare in Kanban differisce da Scrum principalmente perché determina un approccio meno formale. In Kanban, non ci sono linee guida così dettagliate su, ad esempio, lavorare negli Sprint, ruoli di Product Owner, Scrum Master e Team di sviluppo. Ciò è possibile perché Kanban si concentra sulla continuità di compiti come fornire un tipo specifico di servizio, che sono più ripetibili e non richiedono una pianificazione così complessa.

Tuttavia, lo scopo e le modalità di lavoro sono simili. L'obiettivo di Kanban è fornire al cliente un prodotto della massima qualità in tempo. I principi relativi alle modalità di lavoro comuni a entrambi i metodi possono essere formulati come segue:

1. Il lavoro dovrebbe essere regolare e senza tempi di inattività : in Scrum, ciò si ottiene grazie alla continua successione di Sprint, mentre in Kanban il lavoro è continuo grazie al flusso regolare delle attività. Formano una coda, dalla quale gli sviluppatori scelgono (tirano) alcune attività da completare.
2. Il team dovrebbe concentrarsi solo su attività selezionate : utilizzando la terminologia Kanban, il team dovrebbe "ridurre il lavoro in corso". In Scrum, l'equivalente di questo sono le User Story scelte dal Product Backlog da inserire nello Sprint Backlog
3. Lo stato di avanzamento delle attività dovrebbe essere visibile a tutte le persone coinvolte : in Kanban sono visualizzate dalle bacheche, che sono spesso presenti anche negli Scrum Team.

Tavole Kanban in Scrum

Una lavagna Kanban è uno strumento ampiamente utilizzato per visualizzare il lavoro di squadra. È una tabella con più colonne. In ognuno di essi ci sono compiti con un certo stato. 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 schede 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 scheda kanban da un sistema di gestione dei progetti all-in-one : Firmbee.com

Comunemente, ci sono più colonne. Se ci sono più attività da completare, di solito c'è una colonna aggiuntiva intitolata "selezionato per il completamento" tra le colonne "da completare" e "in corso" . Mentre la colonna "da fare" funge da Product Backlog, di cui abbiamo parlato qui, la colonna "selezionato per il completamento" funge da Sprint Backlog, che descriviamo in dettaglio in questo articolo.

La seconda aggiunta comune è una colonna "in corso di revisione" o "per approvazione". Di solito viene inserito tra le colonne contenenti le attività “in corso” e quelle “completate”. Contiene le attività completate dal Team di sviluppo che è in attesa di approvazione da parte del Product Owner. Il compito del Product Owner è di verificarne la 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.

Scruban

A causa dell'enorme popolarità di Scrum e Kanban, è apparso il loro ibrido, che combina il meglio di entrambi i modi di lavorare. Scrumban funziona al meglio nelle organizzazioni che collegano la creazione di Prodotti con la fornitura di servizi, spesso implicando 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 Scrum della necessità di un miglioramento continuo del processo di lavoro e di adattarli alle condizioni e alle esigenze del cliente.

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

La programmazione del lavoro segue il principio “On-Demand”, cioè come si verifica. Le User Story sono posizionate direttamente nella prima colonna della bacheca Kanban contenente le attività "da fare". Pertanto, funge da Sprint Backlog, di cui abbiamo parlato in modo più dettagliato in questo articolo. Come nello Sprint Backlog, le attività più urgenti vengono poste in cima alla lista delle cose da fare. Tuttavia, per i progetti più complessi, il Project Manager può mantenere un elenco di attività separato corrispondente al Product Backlog, dal quale 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à posizionate nella colonna centrale, "da completare", è solitamente limitato a seconda delle dimensioni del team, in modo che, se possibile, ognuno si occupi di un solo compito alla volta.

Riepilogo

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

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog