Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il Primo Sito Web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il Primo Sito Web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

190 dicembre
, anno 2013

Kanban: agile o no?

Qualche riflessione su una questione dibattuta

Francesco Saliola

Francesco Saliola

A MokaByte mi occupo dei processi legati alla gestione degli autori e della redazione degli articoli. Collateralmente, svolgo attività di consulenza e formazione nell‘ambito dell‘editoria "tradizionale" e digitale, della scrittura professionale e della comunicazione sulle diverse piattaforme.

MokaByte

Kanban: agile o no?

Qualche riflessione su una questione dibattuta

Francesco Saliola

Francesco Saliola

  • Questo articolo parla di: Kanban, Lean/Agile, Processi di sviluppo

Una riflessione relativa a Kanban: possiamo considerarlo una metodologia agile, oppure è concettualmente sbagliato? In questo articolo analizzeremo tale questione: nel mondo degli agilisti è un tema dibattuto, anche ferocemente. Ma quali conseguenze pratiche può avere sul modo in cui gestiamo il processo di sviluppo del software?

È solo questione di parole?

In questo articolo affronteremo una questione solo apparentemente “nominale”. Kanban è una metodologia agile oppure no? Nell’ambito di coloro che adottano metodologie agili il dibattito è aperto e a volte anche feroce, poiche’, almeno da parte di alcuni importanti esponenti del movimento agile, si afferma chiaramente che Kanban non può essere considerato una metodologia agile, almeno in senso “ortodosso”.

Ciò non toglie che l’uso delle lavagne Kanban sia estremamente diffuso e, soprattutto, risulti estremamente utile a molti gruppi di lavoro, i cui membri non stanno tanto a porsi il dilemma “filosofico” sulla vera o presunta agilità di Kanban, ma si limitano a sfruttare tali strumenti per gli scopi della loro attività di sviluppo.

In pratica, semplificando al massimo, da un lato abbiamo gruppi di sviluppo e intere aziende che utilizzano le Kanban board con successo, dall’altro, alcune affermazioni che arrivano a definire Kanban come una metodologia waterfall. Vedremo di seguito i termini della questione, lasciando ai nostri lettori la possibilità di farsi un’idea motivata.

Maiuscole e minuscole

Per impostare il discorso, eliminando una serie di malintesi, cominciamo con una rapida definizione del termine kanban, facendo oltretutto una distinzione tra la parola scritta con la lettera iniziale minuscola (kanban) e quella scritta con l’iniziale maiuscola (Kanban). Il termine è il medesimo, di origine giapponese, e significa letteralmente “cartellino”; ma mentre con kanban ci si riferisce specificamente a un particolare cartellino utilizzato come segnalazione visuale nella produzione industriale basata sul metodo Toyota, la parola Kanban (con l’iniziale maiuscola) viene utilizzata per indicare una particolare metodologia di sviluppo del software basata sull’uso di Kanban board, cioè delle lavagne in grado di visualizzare il flusso di lavoro del processo con l’utilizzo di foglietti adesivi post-it, ma che non si limita a questo: si tratta infatti di una serie di principi e pratiche che vanno ben oltre l’utilizzo delle lavagne e dei post-it e che si basano sul metodo di produzione lean.

 

Figura 1 – Un esempio di kanban, il cartellino usato come segnalazione visuale nel sistema di produzione industriale messo a punto dalla Toyota.

 

Logica pull

Alla base dell’uso del kanban, cioè di un cartellino per segnalare la necessità di determinate materie o oggetti indispensabili alla linea produttiva per andare avanti con il lavoro, sta una logica organizzativa del processo di lavoro che viene definita di tipo pull, e che, storicamente, è stata sviluppata e messa a punto nel secondo dopoguerra in Giappone (il cosiddetto Toyota production system). La logica pull si contrappone a quella push, tipica della catena di montaggio delle industrie occidentali, e statunitensi in particolare (il metodo di produzione fordista).

Nella logica pull, avviene un “trascinamento” per cui l’attività a valle trascina quella a monte: si parte dai fabbisogni, che trascinano alla produzione di un determinato bene, in una specifica quantità, con precise caratteristiche. In questo modo, si riesce a migliorare la rapidità di consegna, e a rispondere in maniera adeguata alle variazioni nella domanda, purche’ si istituisca una ben precisa catena di fornitura logistica di tipo “just in time”.

Just in time

Per just in time (JIT) si intende una gestione delle scorte “a ripristino” in cui si alleggeriscono al massimo le quantità di materie prime e semilavorati presenti in magazzino, e si cerca invece di acquisire e avere a disposizione tali materiali solo “appena in tempo” rispetto a quando serviranno effettivamente sulla linea di produzione in fabbrica. Sostanzialmente: si ha a disposizione quel che serve quando serve, senza farne enormi scorte preventive, costose e potenzialmente destinate allo spreco nel caso la domanda cambi e certe materie e semilavorati non servano più. Nella produzione industriale ispirata al metodo Toyota, il kanban, il cartellino si segnalazione visuale, è un segnale identificativo che serve per rifornire di materiale una determinata stazione di lavoro.

In una stazione di lavoro si può procedere con la produzione solo se tutto quel che serve è disponibile, e il segnale identificativo consente appunto di gestire il flusso di materiali dalla stazione a monte a quella a valle. Uno degli aspetti più interessanti del sistema di flusso basato su questi cartellini kanban è che esso responsabilizza l’operaio e riconosce al lavoratore una conoscenza e una competenza specifica che cresce con l’esperienza e la riflessione e che si estrinseca nell’ambito della sua “postazione” e del suo team di lavoro. La funzione che ha, per quanto ripetitiva, richiede una notevole consapevolezza, un “saper fare” tutt’altro che superficiale e che non può essere ridotto a gesto meccanico.

Lean manufacturing

Dall’analisi del sistema Toyota, gli autori del libro “La macchina che ha cambiato il mondo” [1] hanno coniato il termine “produzione snella”. Il lean manufacturing è appunto l’applicazione di tali principi alla produzione industriale. Molti principi lean sono entrati oramai a far parte del bagaglio culturale di chi gestisce i processi di sviluppo software, tant’è che in certi casi, almeno fra coloro che non approfondiscono certe tematiche, i concetti di lean e agile finiscono, erroneamente, per confondersi.

Dalla fabbrica al software

I principi lean hanno, come detto, trovato ottimo terreno di sviluppo nel mondo della gestione dei processi di sviluppo software, tanto che l’autore David Anderson ha scritto un libro dedicato proprio a proporre il metodo nell’ambito delle aziende tecnologiche [2]: da questa esperienza si è diffuso l’uso della parola Kanban in ambito IT.

In questo testo viene messo in luce come sia possibile ispirarsi a certi principi e certe pratiche della “produzione snella” anche per quel che riguarda la produzione di software. In particolare, Kanban consente di

  • visualizzare, misurare e gestire il flusso di lavoro;
  • limitare i lavori lasciati a metà, concentrandosi sul portare a conclusione le varie attività;
  • rendere esplicite a tutti le “regole” alla base del processo che si segue;
  • individuare la possibilità di “aggiustare il tiro” continuamente, in un’ottica di miglioramento continuo.

Ma qui nascono anche i primi intoppi: possiamo considerare Kanban una metodologia agile? E, se sì o no, su quali basi?

Definire che cosa è agile

Per stabilire se Kanban sia propriamente agile o no, occorre anzitutto mettersi d’accordo su quel che consideriamo, appunto, “agile”. E occorre subito dirimere un’altra possibile interpretazione errata: per Kanban si intende tutto l’approccio ispirato alla “produzione snella” e non la sola Kanban board, che ne rappresenta lo strumento operativo, utilissimo e potente, ma che è solo un tool e non costituisce invece l’insieme di principi e pratiche che David Anderson ha descritto nel suo libro.

Figura 2 – Questa lavagna Kanban, invece, è quella usata nello sviluppo del software. Ma è solo uno strumento, per quanto importante e potente.

 

Una definizione “ampia” di Agile potrebbe essere basata su considerazioni quali:

  • la reale interazione tra azienda e clienti per decidere le priorità su cui lavorare nell’immediato;
  • la velocità con cui il lavoro può essere condotto a termine, una volta assunto l’impegno a farlo;
  • la frequenza con cui ogni nuovo “pezzo” completato può essere consegnato e reso operativo.

Si tratta, un po’ alla larga, dei concetti di gestione del “ripristino” delle scorte, di “tempo di attraversamento” o “di risposta” (lead time), e di consegna, presenti nella produzione snella, ma che sono tipici anche delle metodologie agili “ortodosse” come Scrum.

Ma ci sono anche definizioni più stingenti.

Kanban vs. manifesto agile

Se ci atteniamo a quanto riportato nel manifesto per lo sviluppo agile di software [3], però, la situazione si fa più complessa: a voler essere pignoli, Kanban può essere considerato perfettamente aderente all’Agile Manifesto solo per quanto riguarda la voce “rispondere al cambiamento più che seguire un piano”.

Ma non è che gli altri tre principi del manifesto siano poi così lontani da Kanban, specie se si vanno a guardare le declinazioni più ampie di tali principi, i cosiddetti “Dodici principi del software agile” [4].

Quello che, almeno apparentemente, rende Kanban lontano dalle pratiche agili strettamente definite è la mancanza di consegne fisse a tempi prestabiliti (time-boxed), vale a dire le cosiddette “iterazioni”, che invece sono presenti in tutte le pratiche che a quel manifesto si sono ispirate.

Kanban in azione

L’introduzione di Kanban, a partire dagli anni 2007-2008, ha avuto una ragione molto “pratica”, almeno stando a quanto dichiarato da David Anderson: si trattava di trovare una metodologia che potesse essere introdotta nelle aziende, anche complesse, con un impatto minore rispetto a quello che avrebbe richiesto l’adozione su larga scala di metodologie Agile tout-court. Questo ha anche creato degli attriti, poiche’ in certi casi Kanban è stato visto come una alternativa in contrapposizione all’Agile: forse anche da questo è derivato un atteggiamento “sprezzante” da parte di alcuni Agilisti ortodossi (“se non è Agile… allora deve essere Waterfall”).

L’altro atteggiamento è stato quello di vedere in Kanban solo lo strumento: la “lavagna con i post-it”. È chiaramente uno strumento potente, utilissimo, che può essere incorporato in altre metodologie propriamente agili, ma è solo una visione parziale, come già detto: all’inizio, per esempio, le primissime implementazioni di Kanban… addirittura non prevedevano ancora l’uso della Kanban board!

È solo un nome?

In definitiva, con un approccio molto “laico” al problema… ma a chi importa veramente stabilire se Kanban possa essere definito agile o meno? Non è forse più importante capire se i suoi principi e le sue pratiche possano avere un impatto positivo sulle attività produttive di una azienda? Non è meglio concentrarsi sul comprendere se e come possa migliorare la soddisfazione dei clienti e i risultati economici delle organizzazioni che la adottano?

È anche chiaro, a questo punto, che molto prosaicamente si possa far rientrare comunque Kanban nel novero delle metodologie agile, semplicemente per ragioni di marketing: lo si può proporre ad aziende interessate al passaggio all’Agile, senza doverle ulteriormente confondere con una serie di distinzioni e differenziazioni utili nella riflessione metodologica, ma meno utili nel proporsi al cliente. La cosa che conta, in definitiva, è se Kanban migliori o no l’organizzazione del processo di lavoro nelle aziende tecnologiche. E la risposta è affermativa.

Qualche punto di forza

Kanban ha il merito di mettere in luce l’andamento del flusso di lavoro, in maniera chiara e comprensibile: questo permette di capire che i “lavori ancora a metà”, i work in progress (WIP), devono essere ridotti al minimo. Un sistema di produzione che funziona si basa sull’assioma “stop starting, start finishing!”: piuttosto che cominciare sempre nuove attività, è fondamentale concluderne una per volta.

Non è quello che succede di solito: si tende infatti a mantenere in vita un gran numero di attività contemporanee, anche con l’illusione che allocare contemporaneamente una persona su più progetti diversi paralleli ne ottimizzi la produttività. In realtà, più WIP sono presenti nel flusso in un determinato momento, più le difficoltà di comunicazione e di gestione in parallelo finiscono per appesantire il sistema produttivo. Ne derivano multitasking, problemi di comunicazione, e code che finiscono inevitabilmente per fare aumentare il lead time. A questo punto, le aziende che se lo possono permettere, reagiscono impiegando più personale, che però va a gestire i Work In Progress spesso creando ulteriori WIP e finendo comunque per aumentare i tempi di consegna.

La forza di Kanban sta proprio qui: mettendo in evidenza le code nel flusso, indica chiaramente che la soluzione non sta nel “motivare” i lavoratori, o nel migliorare i tempi della singola attività (le “colonne” della lavagna Kanban). La soluzione sta nel migliorare nettamente il passaggio dei post-it da una colonna all’altro, vale a dire nel ridurre i ritardi nel passaggio da una stazione produttiva all’altra: si tratta in pratica di favorire il flusso, riducendo le ragioni di blocco o attesa che creano le code.

Il limite ai WIP che è possibile istituire per ogni colonna della lavagna mantiene a livelli gestibili il carico di attività svolte contemporaneamente, limitando la complessità e le code che derivano da un eccesso di “contemporaneità” nello svolgere le attività (multitasking, “spezzettameno” del personale su tanti progetti diversi etc.).

Conclusioni

Kanban è un sistema che affonda le sue radici nel sistema di produzione industriale lean, assumendone i principi e la logica pull. Discutere se la metodologia di sviluppo per il software messa a punto da David Anderson, e denominata appunto Kanban, sia o no una metodologia agile è senza dubbio logico e sensato, da un punto di vista “accademico”, visto che in molti casi essa è stata adottata in alternativa a metodologie agili più ortodosse e usate in precedenza, specie in grandi aziende.

Se però passiamo a una visione pragmatica, più che alle differenze di ispirazione e filosofia, occorre guardare al miglioramento e ai vantaggi che Kanban può portare a una organizzazione: in tal senso, sicuramente questo approccio apporta benefici indiscussi al contesto aziendale in cui si effettua sviluppo software, migliorandone “l’agilità” in senso lato.

Kanban può dimostrarsi più adatto a un’adozione in situazioni aziendali molto complesse, perche’ consente una transizione “morbida”, meno drastica di quella necessaria con metodologie agile più strutturate: da un lato c’è un processo di miglioramento continuo (kaizen), dall’altra una iniziativa di transizione gestita.

Per questo, conoscere Kanban come “filosofia” di lean manufacturing, e non solo come strumento rappresentato dalla lavagna, è un punto di forza, poiche’ consente di avere a disposizione una “via alternativa” all’agilità, che è possibile percorrere in quei casi e in quei particolari contesti in cui altre metodologie agili potrebbero incontrare grosse resistenze o non essere scalabili.
 

Riferimenti bibliografici

[1] Womack J.P. – Jones D.T. – Roos D., “The Machine That Changed the World: The Story of Lean Production”, Harper Business, 1991 (trad. it. “La macchina che ha cambiato il mondo”, Rizzoli 1999)

 

[2] David J. Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”, Blue Hole Press, 2010

 

[3] Agile Manifesto

http://agilemanifesto.org/iso/it/

 

[4] I dodici principi del software agile

http://agilemanifesto.org/iso/it/principles.html

 

 

Facebook
Twitter
LinkedIn
Francesco Saliola

Francesco Saliola

A MokaByte mi occupo dei processi legati alla gestione degli autori e della redazione degli articoli. Collateralmente, svolgo attività di consulenza e formazione nell‘ambito dell‘editoria "tradizionale" e digitale, della scrittura professionale e della comunicazione sulle diverse piattaforme.

Francesco Saliola

Francesco Saliola

A MokaByte mi occupo dei processi legati alla gestione degli autori e della redazione degli articoli. Collateralmente, svolgo attività di consulenza e formazione nell‘ambito dell‘editoria "tradizionale" e digitale, della scrittura professionale e della comunicazione sulle diverse piattaforme.
Tutti gli articoli
Nello stesso numero
Loading...

Open Data Institute

Divulgazione e promozione degli open data in UK

Guida galattica per scrummers

II parte: Introduzione al framework Scrum

Il teorema CAP… in Brewer

V parte: L'implementazione CP in MongoDB

Nella stessa serie
Loading...

Un sistema di monitoraggio del traffico veicolare “in tempo reale”

VI parte: Data processing e persistenza

WebAssembly, uno standard web per il presente e per il futuro

I parte: Panoramica e caratteristiche

Cos’è che fa di un DevOps un DevOps?

Principi, pratiche, ruolo

Quindici statistiche da conoscere per lavorare in UX design

Uno sguardo internazionale

Un sistema di monitoraggio del traffico veicolare “in tempo reale”

V parte: Data Ingestion & Computing

User Story Game

Capire l’importanza delle User Stories… giocando

Sbagliando si impara?

Elenco ragionato di alcuni errori tipici nella pratica Scrum

Cybersecurity e cloud computing

Le basi per mettere in sicurezza il cloud

Un sistema di monitoraggio del traffico veicolare “in tempo reale”

IV parte: L’invio dei dati al topic di Kafka

Verso #play14 Bologna 2022

Cosa era successo la volta precedente

Product Owner: chi è?

Perché non è un Project Manager agile?

Come monitorare l’avanzamento dei lavori in Agile

Misurare lo stato di avanzamento di un progetto in Agile

Contributors

Un sistema di monitoraggio del traffico veicolare “in tempo reale”

III parte: Il framework Spark

Kanban in pratica

Qualche suggerimento in azione

Comunicazione tra microservizi con Apache Kafka

Un esempio pratico

OKR, cadenze in Kanban e Flight Levels

Uscire dalla trappola dell’agilità locale

Un sistema di monitoraggio del traffico veicolare “in tempo reale”

II parte: Tecnologie di analisi

Big Data vs Fast Data

Estrarre valore dai dati in tempo reale

Lean Manufacturing e Agile

Esempi applicativi di integrazione possibile

Approccio Agile e pianificazione strategica

La coesistenza è possibile?

Impact Mapping e Liminal Thinking

II parte: Progettare gli impatti

Un sistema di monitoraggio del traffico veicolare “in tempo reale”

I parte: Introduzione e panoramica

Agile Coaching

Un modello operativo per l'agile coach

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte