Kanban, Scrum, Scrumban, …
In questo post andremo a proseguire l’esplorazione sulla metodologia AGILE, concludendo l’introduzione di questo argomento.
Definizioni preliminari
Per alcune definizioni preliminari, vi rimando al seguente link del sito Agileway.it, dove ho trovato delle indicazioni molto ben fatte.
Kanban
Per spiegare in cosa consiste Kanban, sfruttiuamo A brief introduction to kanban, di Dan Radigan, dove il lettore viene indirizzato in un percorso abbastanza chiaro e semplice (Si tratta di un articolo in inglese, ma stiamo lavorando per rendere disponibile queste documentazioni in italiano). Cercheremo di dare una spiegazione il più semplice, ma anche il più chiaro possibile.
L’approccio Kanban bene si adatta a quelle situazioni in cui si hanno sempre delle attività continue da svolgere.
Il Product Owner scompone il lavoro in tanti piccoli task, più o meno complessi, modificando l’ordine degli stessi e inserendo in cima quelli con maggiore priorità. In questo modo è sempre possibile rischedulare il lavoro del team senza dover bloccare il lavoro del team.
Il Team di sviluppo verifica i task da eseguire, seleziona quello in cima al backlog e lo porta a compimento. Quando lo seleziona, lo sposta dalla colonna To Do alla colonna Doing. Quando lo completa, lo sposta nella colonna Done.
Quando si ha a disposizione un insieme di task completati, si procede con un rilascio del nuovo software.
Questo approccio è molto più indicato nella manutenzione che nello sviluppo di nuove applicazioni.
Scrum
A differenza della precedente, la Scrum ben si adatta allo sviluppo di un nuovo progetto. Andiamo a capire meglio:
Scrum struttura il proprio sviluppo in cicli chiamati Sprint che durano da una a quattro settimane, al termine dei quali il team di sviluppo rilascia funzionalità immediatamente testabili.
In Scrum non abbiamo una figura di Project manager che coordina il team, ma possiamo dire che il team stesso è in qualche modo auto-organizzato. Tutte le competenze per la realizzazione del progetto sono presenti in tutti i membri del team stesso. Con questo non voglio dire che il project manager non esiste in tali organizzazioni, fa solo qualcosa di differente.
Prima di iniziare i lavori, il team si riunisce e definisce i task che saranno sviluppati definendo una Sprint. Nel definirli si impegna a completarli entro la fine della stessa. Una volta definiti, questi task sono inseriti nel backlog e si iniziano i lavori.
Ogni giorno il team si confronta nello Stand-up Meeting, che deve durare non più di 15 minuti, dove deve emergere lo stato di avanzamento, problemi e criticità. Obbiettivo è di identificare subito ciò che può bloccare il lavoro del team e rimuoverlo in modo da consentire il normale svolgimento delle attività.
Al termine della sprint si rilascia ciò che è stato completato, mettendo a disposizione una funzionalità completa e testata, testabile a sua volta dal cliente.
Scrumban
Si tratta di una composizione delle due tecniche, un cui abbiamo l’unione di quanto di meglio abbiamo dai due approcci precedentemente indicati. Ho trovato, facendo delle ricerche, il seguente link per una bella immagine che descrive abbastanza bene visivamente che cosa è Scrumban, che mi sembra molto chiara e precisa. Maggiori dettagli li ho identificati qui (in inglese).
Scrumban mette insieme l’interazione continua di Kanban, aggiungendo una limitazione agli slot di task che devono essere eseguiti contemporaneamente. In Scrumban, il gruppo di lavoro è organizzato in piccole interazioni e monitorato attraverso una board similare a Scrum e Kanban.
Si lavora solo su di un sottoinsieme di user story, che vengono scelte attraverso dei planning meeting, che hanno l’obbiettivo di predisporre delle vere e proprie Sprint. Per tenere le interazioni molto basse, Il WIP (Work in Progress) di ogni stato.
Kanban Vs Scrumban
La seguente immagine riassume le differenze tra Kanban e Scrumban.
Scrum Vs Scrumban
La seguente immagine riassume le differenze tra Scrum a Scrumban:
Conclusioni
In questo post abbiamo concluso l’introduzione alla programmazione Agile. Spero di aver fornito le basi per poter iniziare ad approfondire questi nuovi argomenti o quanto meno di aver introdotto degli argomenti interessanti.
Nei prossimi post iniziamo a calare questi concetti su JIRA SOFTWARE, verificando che cosa sia possibile realizzare e come.
Ringraziamenti
Ringraziamenti per l’aiuto a Michael Forni, che è stato un valido supporto ed aiuto nella redazione di questi articoli. Di seguito i suoi contatti:
Citazione
Alcune immagini ed indicazioni sono prese dal sito AgileWay.it e da altre fonti (che cito di seguito), dove ho trovato indicazioni molto utili. Lo cito con piacere e ne suggerisco la lettura dei vari articoli: ritengo siano una fonte molto importante di informazioni in italiano. Altre immagini e riferimenti sono stati presi dai seguenti siti, quali:
- kanbantool.com – per l’immagine che mette a disposizione per descrivere Scrumban e per le immagini
- www.solutionsiq.com – per le immagini di confronto tra Kanban e Scrumban e tra Scrum a Scrumban.
