La Guida Kanban per Team Scrum - Settembre 2019 - AWS

Pagina creata da Simone Montanari

Finanza

Italiano

Piace
Condividi
Incorpora
Schermo intero
Diapositive
Scarica HTML
Scarica PDF
Abuso

←

CONTINUA A LEGGERE

→

Trascrizione del contenuto della pagina

Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù

La Guida Kanban
per Team Scrum
Settembre 2019

 Sviluppato e mantenuto da Scrum.org, Daniel Vacanti e Yuval Yeret

Indice
Scopo .............................................................................................................................................. 3
Relazione con The Scrum Guide ..................................................................................................... 3
Definizione di Kanban ..................................................................................................................... 3
Kanban con la Teoria Scrum ........................................................................................................... 3
Flusso ed empirismo ................................................................................................................... 3
Le Metriche di base del flusso .................................................................................................... 4
Legge di Little – La chiave per governare il Flusso ...................................................................... 4
Le Pratiche di Kanban ..................................................................................................................... 4
Visualizzare il Workflow – la Kanban Board ................................................................................ 5
Limitare il Work in Progress (WIP) .............................................................................................. 5
Gestire attivamente i Work Item in Progress ............................................................................. 6
Ispezionare ed Adattare la Definizione di “Workflow” ............................................................... 6
Eventi basati sul Flusso ................................................................................................................... 7
Lo Sprint ..................................................................................................................................... 7
Sprint Planning ........................................................................................................................... 7
Daily Scrum ................................................................................................................................. 7
Sprint Review.............................................................................................................................. 8
Sprint Retrospective ................................................................................................................... 8
Incremento ..................................................................................................................................... 8
Nota finale ...................................................................................................................................... 9
Storia e Riconoscimenti .................................................................................................................. 9

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative Commons,
accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary
form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Kanban Guide for Scrum Teams,
you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share-Alike license of Creative Commons.
La Guida Kanban per Team Scrum | Pagina 2

Scopo
La prospettiva basata sul flusso [flow] di Kanban può migliorare e integrare il framework Scrum e
la sua implementazione. I team possono aggiungere pratiche Kanban complementari sia che
stiano appena iniziando ad usare Scrum o che lo stiano usando da sempre.
La Kanban Guide per Team Scrum è il risultato di una collaborazione tra i membri della comunità
di Scrum.org e i leader della comunità Kanban. Insieme, sostengono la Guida Kanban per i Team
Scrum. È loro convinzione condivisa che i professionisti dello sviluppo di prodotti professionali
possono beneficiare dell'applicazione del Kanban insieme a Scrum.

Relazione con La Guida a Scrum
Questa guida non sostituisce o aggiorna alcuna parte de La Guida a Scrum. È stata progettata per
migliorare ed espandere le pratiche di Scrum. Questa guida presuppone che il lettore stia
operando un processo utilizzando il framework Scrum. Pertanto, La Guida a Scrum si applica nella
sua interezza.

Definizione di Kanban
Kanban (n): una strategia per ottimizzare il flusso di valore attraverso un processo che utilizza un
sistema “pull” visuale, limitato nel work-in-progress.

Kanban con la Teoria Scrum

Flusso ed empirismo
Centrale per la definizione di Kanban è il concetto di Flusso (Flow). Il flusso è il movimento di
valore attraverso il sistema di sviluppo del prodotto. Kanban ottimizza il flusso migliorando
l'efficienza complessiva, l'efficacia e la prevedibilità di un processo.
L'ottimizzazione del flusso in un contesto Scrum richiede la definizione di cosa significa flusso in
Scrum. Scrum si basa sulla teoria empirica del controllo di processo, o empirismo. La chiave per il
controllo empirico del processo è la frequenza del ciclo di trasparenza, ispezione e adattamento -
che possiamo anche descrivere come il Cycle Time attraverso il ciclo di feedback.
Quando le pratiche Kanban vengono applicate a Scrum, esse forniscono un focus sul
miglioramento del flusso attraverso il ciclo di feedback, ottimizzando la trasparenza e la frequenza
di ispezione e adattamento sia per il prodotto che per il processo.

Le Metriche di base del flusso
Le quattro metriche di base del flusso che i Team Scrum che utilizzano Kanban devono tracciare
sono le seguenti:
• Work in Progress (WIP): Il numero di elementi di lavoro iniziati ma non completati. Notare
la differenza tra la metrica WIP e le politiche che un Team Scrum utilizza per limitare il
WIP. Il team può utilizzare la metrica WIP per fornire trasparenza sui suoi progressi
attraverso la riduzione del WIP e il miglioramento del flusso.
• Cycle Time: La quantità di tempo trascorso tra l'inizio di un elemento di lavoro e la fine di
un elemento di lavoro.
• Work Item Age: La quantità di tempo che intercorre tra quando un elemento di lavoro
viene iniziato e l'ora corrente. Questa vale solo per gli elementi che sono ancora in corso.
• Throughput: Il numero di elementi di lavoro finiti per unità di tempo.

Legge di Little – La chiave per governare il Flusso
Un principio chiave che governa la teoria del flusso è la Legge di Little, che è una linea guida che
stabilisce la seguente relazione:

=
ℎ ℎ

La Legge di Little rivela che, in generale, per un dato processo con un dato throughput, su più cose
si lavora in un dato momento (in media), più tempo ci vorrà per finire quelle cose (in media). Se i
cycle time sono troppo lunghi, la prima azione che i Team Scrum dovrebbero considerare è
abbassare il WIP. La maggior parte degli altri elementi del Kanban sono costruiti sulla relazione
tra WIP e Cycle Time.
La Legge di Little ci mostra anche come la teoria del flusso si basi sull'empirismo, usando le
metriche di flusso e i dati per ottenere trasparenza nel flusso storico e poi usando quei dati per
informare l'ispezione dei flussi e gli esperimenti di adattamento.

Le Pratiche di Kanban
I Team Scrum possono raggiungere l'ottimizzazione del flusso utilizzando le seguenti quattro
pratiche:
• Visualizzare il workflow
• Limitare il Work in Progress (WIP)
• Gestire attivamente i lavori in corso (Work item in progress)
• Ispezionare ed adattare la definizione del team di “Workflow”

Definizione di “Workflow”
Le quattro pratiche Kanban sono favorite dalla definizione di "Workflow" data dal Team Scrum.
Questa definizione rappresenta l'esplicita comprensione da parte dei membri del Team Scrum di
quali siano le loro politiche per seguire le pratiche Kanban. Questa comprensione condivisa
migliora la trasparenza e consente l'auto-organizzazione.
Si noti che l'ambito della definizione di "Workflow" può andare oltre lo Sprint e lo Sprint Backlog.
Per esempio, la definizione di "Workflow" di un Team Scrum può comprendere il flusso all'interno
e/o all'esterno dello Sprint.
La creazione e l'adattamento della definizione di "Workflow" è la responsabilità dei ruoli rilevanti
nel Team Scrum, come descritto in La Guida a Scrum. Nessuno al di fuori del Team Scrum
dovrebbe dire al Team Scrum come definire il proprio "Workflow". Allo stesso modo, nessuno al
di fuori del Team di Sviluppo, incluso il Product Owner o lo Scrum Master, dovrebbe dire al team
come definire gli aspetti del flusso di lavoro che sono interni al lavoro del Team di Sviluppo.

Visualizzare il Workflow – la Kanban Board
La visualizzazione tramite la Kanban board è il modo in cui il Team Scrum rende trasparente il
proprio flusso di lavoro. La configurazione della board dovrebbe stimolare le giuste conversazioni
al momento giusto e suggerire proattivamente le opportunità di miglioramento.
La visualizzazione dovrebbe includere quanto segue:
• Punti definiti in cui il Team Scrum considera il lavoro iniziato e finito.
• Una definizione degli elementi di lavoro - le singole unità di valore (valore per gli
stakeholder, valore della conoscenza, valore del miglioramento del processo) che
fluiscono attraverso il sistema dello Scrum Team (molto probabilmente Product Backlog
Item (PBI)).
• Una definizione del flusso di lavoro stabilisce che gli elementi di lavoro scorrono dall'inizio
alla fine (di cui deve esserci almeno uno stato attivo).
• Politiche esplicite su come il lavoro scorre attraverso ogni stato (che possono includere
elementi della definizione di "Fatto" di un Team di Scrum e politiche di pull tra le fasi)
• Politiche per limitare il Work In Progress (WIP).

Limitare il Work in Progress (WIP)
Work in Progress (WIP) si riferisce agli elementi di lavoro che il Team Scrum ha iniziato ma non ha
ancora terminato.
I Team Scrum che utilizzano Kanban devono limitare esplicitamente il numero di questi lavori in
corso. Un Team Scrum può limitare esplicitamente il WIP come meglio crede, ma dovrebbe
attenersi a tale limite una volta stabilito.

L'effetto principale della limitazione del WIP è che crea un sistema pull. Si chiama sistema pull
perché il team inizia a lavorare (cioè “tira") su un oggetto solo quando è chiaro che ha la capacità
per farlo. Quando il WIP scende al di sotto del limite definito, questo è il segnale per iniziare un
nuovo lavoro. Si noti che questo è diverso da un sistema push, che richiede che il lavoro inizi su
un oggetto ogni volta che venga richiesto.
Limitare il WIP aiuta il flusso e migliora l'auto-organizzazione, l'attenzione, l'impegno e la
collaborazione del Team Scrum.

Gestire attivamente i Work Item in Progress
Limitare il WIP è necessario per ottenere il flusso, ma da solo non è sufficiente. La terza pratica
per raggiungere il flusso è la gestione attiva dei lavori in corso. All'interno dello Sprint, questa
gestione da parte del Team di Sviluppo può assumere diverse forme, tra cui, ma non solo, le
seguenti:
• Assicurarsi che gli elementi di lavoro siano inseriti nel workflow solo alla stessa velocità
con cui escono dal workflow.
• Assicurarsi che gli elementi di lavoro non siano lasciati invecchiare inutilmente.
• Rispondere rapidamente agli elementi di lavoro bloccati o in coda, nonché a quelli che
superano il livello di cycle time atteso del team (Vedere Service Level Expectation – SLE).

Aspettativa sui Livelli di Servizio (Service Level Expectation - SLE)
Un'aspettativa sui livelli di servizio (SLE) prevede quanto tempo dovrebbe essere necessario ad
un dato elemento per fluire dall'inizio alla fine del flusso di lavoro del Team Scrum. Il Team Scrum
utilizza il suo SLE per trovare problemi di flusso attivo e per ispezionare e adattare nei casi di
scendere al di sotto di tali aspettative.
Lo stesso SLE ha due parti: un periodo di giorni trascorsi e una probabilità associata a tale periodo
(ad esempio, l'85% degli elementi di lavoro dovrebbe essere terminato in otto giorni o meno). Lo
SLE dovrebbe essere basato sul cycle time storico del Team Scrum e, una volta calcolato, lo Scrum
Team dovrebbe renderlo trasparente. Se non esistono dati storici sul cycle time, il Team Scrum
dovrebbe fare la sua migliore ipotesi e poi ispezionare e adattare una volta che ci sono abbastanza
dati storici per fare un corretto calcolo dello SLE.

Ispezionare ed Adattare la Definizione di “Workflow”
Il Team Scrum utilizza gli eventi Scrum esistenti per ispezionare e adattare la sua definizione di
"Workflow", contribuendo così a migliorare l'empirismo e ad ottimizzare il valore che il Team
Scrum produce. Quanto segue sono gli aspetti della definizione di "Workflow" che il Team Scrum
potrebbe adottare:

• Politiche di visualizzazione - ad esempio, stati del flusso di lavoro (Workflow) - sia
modificando il flusso di lavoro effettivo che portando maggiore trasparenza in un'area in
cui il team vuole ispezionare e adattare.
• Politiche del lavoro - queste possono indirizzare direttamente un ostacolo. Ad esempio,
l'adeguamento dei limiti WIP e SLE, la modifica delle dimensioni dei batch o la frequenza
con cui gli elementi vengono “tirati” da uno stato all'altro possono avere un impatto
drammatico.

Eventi basati sul Flusso
Kanban in un contesto Scrum non richiede eventi aggiuntivi rispetto a quelli descritti in La Guida
a Scrum. Tuttavia, l'utilizzo di una prospettiva basata sui flussi e l'uso di metriche di flusso negli
eventi di Scrum rafforza l'approccio empirico di Scrum.

Lo Sprint
Le pratiche complementari di Kanban non sostituiscono lo Sprint di Scrum. Anche in ambienti in
cui il flusso continuo è desiderabile/raggiunto, lo Sprint è ancora una cadenza o un battito
cardiaco regolare per ispezione e adattamento sia del prodotto che del processo. I team che
utilizzano Scrum con Kanban utilizzano gli eventi dello Sprint come un ciclo di miglioramento del
feedback, ispezionando e adattando in modo collaborativo la loro definizione di "Workflow" e
metriche di flusso.
Le pratiche Kanban possono aiutare i Team di Sviluppo a migliorare il flusso e creare un ambiente
in cui le decisioni vengono prese “just-in-time” durante lo Sprint sulla base di ispezione e
adattamento. In questo ambiente, i Team di Sviluppo si affidano allo Sprint Goal e alla stretta
collaborazione con il Product Owner per ottimizzare il valore aggiunto dello Sprint.

Sprint Planning
Uno Sprint Planning basato sul flusso utilizza le metriche di flusso come ausilio per lo sviluppo
dello Sprint Backlog. Ad esempio, utilizzando il flusso storico per capire la capacità del Team Scrum
per lo Sprint successivo.

Daily Scrum
Un Daily Scrum basato sul flusso si concentra sull'assicurare che il Team Scrum stia facendo tutto
il possibile per mantenere un flusso costante. Mentre l'obiettivo del Daily Scrum rimane lo stesso
come descritto in The Scrum Guide, la riunione stessa si svolge intorno alla Kanban board e si
concentra su dove il flusso è insufficiente e su quali azioni il Team Scrum può intraprendere per
ripristinarlo.
Ulteriori cose da considerare durante un Daily Scrum basato sul flusso includono quanto segue:

• Quali elementi di lavoro sono bloccati e cosa può fare il Team di Sviluppo per sbloccarli?
• Quale lavoro scorre più lentamente del previsto? Qual è il Work Item Age di ogni
elemento in corso di lavorazione? Quali elementi di lavoro hanno violato o stanno per
violare il loro SLE e cosa può fare il Team Scrum per completare quel lavoro?
• Ci sono fattori che possono influenzare la capacità del Team Scrum di completare il lavoro
di oggi che non sono rappresentati sulla board?
• Abbiamo imparato qualcosa di nuovo che potrebbe cambiare ciò su cui il Team Scrum ha
pianificato il prossimo lavoro?
• Abbiamo infranto il nostro limite di WIP? E cosa possiamo fare per assicurarci di poter
completare il lavoro in corso?

Sprint Review
La Guida a Scrum fornisce una descrizione dettagliata dello Sprint Review. L'ispezione delle
metriche di flusso Kanban come parte della Review può creare opportunità per nuove
conversazioni sul monitoraggio dei progressi verso un obiettivo. La verifica del Throughput può
fornire ulteriori informazioni quando il Product Owner discute le probabili date di rilascio.

Sprint Retrospective
Una Sprint Retrospective basata sul flusso aggiunge l'ispezione delle metriche e delle analisi di
flusso per aiutare a determinare quali miglioramenti può apportare il Team Scrum ai suoi processi.
Il Team Scrum che utilizza Kanban ispeziona e adatta anche la definizione di "Workflow" per
ottimizzare il flusso nel prossimo Sprint. Utilizzando un diagramma di flusso cumulativo (CFD) per
visualizzare il WIP di un Team Scrum, il Cycle Time approssimativo medio e il Throughput medio
possono essere preziosi.
Oltre alla Sprint Retrospective, il Team Scrum dovrebbe considerare la possibilità di sfruttare le
opportunità di ispezione e adattamento dei processi che emergono durante lo Sprint.
Allo stesso modo, le modifiche alla definizione di "Workflow" di un Team Scrum possono avvenire
in qualsiasi momento. Poiché questi cambiamenti avranno un impatto materiale sulle prestazioni
del Team Scrum, le modifiche apportate durante la regolare cadenza fornita dalla Sprint
Retrospective ridurranno la complessità e miglioreranno l'attenzione, l'impegno e la trasparenza.

Incremento
Scrum richiede che il team crei (come minimo) un incremento potenzialmente rilasciabile del
prodotto "Fatto" ad ogni Sprint. L'empirismo di Scrum incoraggia la creazione di più incrementi
rilasciabili durante lo Sprint per consentire una rapida ispezione e adattare i cicli di feedback.
Kanban aiuta a gestire il flusso di questi cicli di feedback in modo più esplicito e permette allo
Scrum Team di identificare colli di bottiglia, vincoli e impedimenti per una consegna più rapida e
continua di valore.

Nota finale
Scrum non è un processo o una tecnica. È un framework all'interno del quale le persone possono
affrontare problemi complessi e adattivi e allo stesso tempo fornire prodotti del massimo valore
possibile in modo produttivo e creativo. Come sottolinea La Guida a Scrum, funziona bene come
contenitore per altre tecniche, metodologie e pratiche.
Le pratiche di Kanban per l'ottimizzazione del flusso forniscono ai Team Scrum ulteriori
opportunità di ispezionare la cosa giusta, al momento giusto, e poi, sulla base di tale ispezione,
adattarla in base alle necessità. La super focalizzazione di Kanban sulla trasparenza, la
visualizzazione e il flusso massimizza il feedback, l'empirismo e, in ultima analisi, la consegna di
valore.

Storia e Riconoscimenti
L'insieme di pratiche comunemente denominate Kanban è nato principalmente nel 2006 in un
team di Corbis, una società di licenze per i media di proprietà di Bill Gates. Tali pratiche si sono
rapidamente diffuse fino a comprendere una vasta e diversificata comunità internazionale che nel
corso degli anni ha continuato a migliorare ed evolvere l'approccio.
Questa guida è stata sviluppata in collaborazione da Scrum.org, dalla sua Community di
Professional Scrum Trainer, Steve Porter, Yuval Yeret e Daniel Vacanti.
Un ringraziamento speciale a Louis-Philippe Carignan, Charles Bradley, Jose Casal, Andy Hiles e
Jesse Houwing per il loro contributo. Abbiamo anche un debito di gratitudine a tutti quei
professionisti che in passato hanno contribuito a rendere il Kanban una strategia lean-agile
praticabile e di successo.

Ringraziamento dei traduttori
Questa guida è stata tradotta a partire dalla versione originale inglese fornita dagli sviluppatori
sopra citati. Tra i collaboratori alla traduzione ci sono Massimo Sarti (traduzione) e Fabio
Panzavolta (revisione).

Puoi anche leggere