Inizio con un post pro-kanban, o meglio in difesa di kanban (anche se so bene che c'è chi può farlo molto meglio di me …)
PS un paio di link per chi vuole approfondire la conoscenza di kanban:
http://agilemanagement.net/index.php
http://www.limitedwipsociety.org/
Premetto che ho usato con successo Scrum e continuerò a farlo quando appropriato. Ho tuttavia iniziato in alcune situazioni ad applicare kanban e i primi ritorni sono molto incoraggianti. La capacità di rendere trasparente stato del progetto e del processo costituisce già di per sé un valore enorme...
Una certa avversione a kanban da parte di una fetta della comunità Agile non è una novità:
Ken Schwaber: Telling It Like It Is
Tobias Mayer: Scrum and Kanban - different animals (vedere però i commenti di Liz Keogh e Ron Jeffries)
Entrambi gli interventi sono stati discussi da David Anderson: Reflections on Scrum compared to Kanban
Lo spunto "italiano" me lo danno questi due post di Gabriele Lana che ho notato solo di recente:
Comincio dall'uso un pò improprio che a volte viene fatto della parola fase, che ha una certa connotazione seriale/waterfall, in linea di principio quanto di più lontano possa esistere da kanban.
In realtà più che fasi le colonne di una kanban board rappresentano gli stati in cui possono trovarsi i singoli task. La differenza può sembrare sottile ma non è così: fase si associa facilmente a un gruppo/blocco di task che procedono raggruppati da uno step al successivo come ad esempio nel waterfall, stato invece no e infatti kanban non prescrive "fasi" o iterazioni.
Riprendo dai post:
"chi sviluppa non fa deploy di quello che ha sviluppato? Evidentemente [no], altrimenti non si spiega perchè la fase dello sviluppo è dimensionato a 5 user story e il deployment a 1"
Più che fase dello sviluppo dimensionata a 5, quel limite sta a significare che possono esistere al massimo 5 task nello stato "in sviluppo". Ogni task vive di vita propria e procede, anzi è tirato (pull), indipendentemente verso gli stati successivi. E' una differenza sostanziale a mio avviso (tra l'altro il limite non è in genere collegato linearmente al numero di persone coinvolte).
Posto che esistono molte realtà in cui deployment e sviluppo sono a carico di persone diverse, in generale il WIP (Work In Process) non viene limitato "a piacere", ma con un fine preciso: è probabile che nel caso citato quei valori siano i migliori in termini di ottimizzazione del flusso e distribuzione del carico di lavoro.
"chi sviluppa non fa deploy di quello che ha sviluppato? Evidentemente [no], altrimenti non si spiega perchè la fase dello sviluppo è dimensionato a 5 user story e il deployment a 1"
Più che fase dello sviluppo dimensionata a 5, quel limite sta a significare che possono esistere al massimo 5 task nello stato "in sviluppo". Ogni task vive di vita propria e procede, anzi è tirato (pull), indipendentemente verso gli stati successivi. E' una differenza sostanziale a mio avviso (tra l'altro il limite non è in genere collegato linearmente al numero di persone coinvolte).
Posto che esistono molte realtà in cui deployment e sviluppo sono a carico di persone diverse, in generale il WIP (Work In Process) non viene limitato "a piacere", ma con un fine preciso: è probabile che nel caso citato quei valori siano i migliori in termini di ottimizzazione del flusso e distribuzione del carico di lavoro.
Kanban prescrive molto poco, in particolare non prescrive che i team siano specializzati, generalisti o altro:
"Nel nostro team siamo in 5, non possiamo essere nella fase di test tutti e 5?" . Certo che si.
Si possono avere persone dedicate solo al test oppure no.
Quindi va bene anche avere un team in cui tutte le persone si occupano di analisi, di sviluppo e di test (se però fanno tutti insieme analisi e poi tutti insieme sviluppo e poi tutti insieme test, la cosa comincia ad avere un waterfall-smell per niente bello …).
Si possono quindi adattare i limiti WIP alle situazioni più varie: si può anche arrivare all'estremo di avere un unico limite WIP globale per l'intero board: siete in 5, mettete limite 5, o 10, o X al numero totale di task in lavorazione, in qualsiasi stato essi siano (lasciando senza limiti le singole colonne, god help us :) ).
L'importante è limitarlo questo benedetto WIP (il Lean, David Anderson e molti altri hanno spiegato molto bene perché):
"stop starting, start finishing"
"stop starting, start finishing"
Perché mai tutto questo non dovrebbe essere agile non lo capisco. Vogliamo produrre valore rapidamente -> allora completiamoli questi benedetti task invece di prenderne in carico tonnellate senza finirne uno.
Individuals and interactions over processes and tools: infatti in kanban è (dovrebbe essere) il team, per di più potenzialmente allargato rispetto a Scrum, che decide le policies: quali colonne, quali limiti, se e quali buffer, la definizione di "done" e di tutti gli altri criteri di passaggio da uno stato all'altro. E sempre il team dovrebbe poi modificarli tali limiti e se opportuno anche quante e quali colonne utilizzare -> miglioramento continuo -> responding to change (anche a livello di processo).
La kanban board rende evidenti i problemi ed è in genere semplice raggiungere il consenso sugli interventi necessari.
La kanban board rende evidenti i problemi ed è in genere semplice raggiungere il consenso sugli interventi necessari.
Responding to change -> mantenere la mente aperta e pronta a cogliere nuovi spunti e opportunità (anche questo è Agile).
kanban non è la ricetta magica.
kanban aiuta a cambiare, in modo graduale e probabilmente più condiviso.
a volte è preferibile.
kanban non è la ricetta magica.
kanban aiuta a cambiare, in modo graduale e probabilmente più condiviso.
a volte è preferibile.
PS un paio di link per chi vuole approfondire la conoscenza di kanban:
http://agilemanagement.net/index.php
http://www.limitedwipsociety.org/
