Kanban, dall'idea alla pratica

IV Parte: misurazioni e misure delle performancedi

Introdurre Kanban in una organizzazione è un processo che deve essere fatto tramite un approccio incrementale in cui ogni modifica va valutata in funzione degli effetti che produce. Per valutare si deve misurare, per misurare si deve prima stabilire cosa misurare. In questo articolo introduciamo alcune delle metriche più utilizzate per analizzare in modo oggettivo i miglioramenti che si possono ottenere applicando modifiche al processo di lavorazione.

Introduzione

Come abbiamo avuto modo di vedere negli articoli fin qui pubblicati, l'introduzione di una metodologia agile come Kanban, e la stessa progettazione della board, parte dalla applicazione di concetti di base dai quali si procede per miglioramenti successivi tramite un approccio empirico e retrospettivo. Per verificare le conseguenze di ogni variazione al processo, è necessario misurare le performance complessive per capire se e quanto il sistema sta migliorando.

Quando di parla di misurare le prestazioni di un sistema produttivo due sono le aree di intervento che è utile mettere in pratica: stabilizzare il processo e introdurre delle metriche o Key Performance Indicator (KPI). Il primo aspetto è necessario per poter disporre di un sistema dal comportamento costante in cui le variazioni delle prestazioni siano facilmente riconducibili alle modifiche apportate, rendendo quindi possibile identificare quelle funzionali al miglioramento.

Mappare, stabilizzare e misurare il processo

Gli articoli pubblicati fino a questo punto hanno fornito gli strumenti per costruire un modello basico su cui poi intervenire per raffinamenti successivi. In questo articolo proviamo a fornire gli strumenti per valutare se ogni modifica al modello di partenza introduce un miglioramento o un peggioramento del sistema.

Misurare i progressi che si riesce a compiere all'interno del percorso di miglioramento di una organizzazione è probabilmente uno dei compiti più difficili da svolgere: oltre alla individuazione delle metriche con cui misurare le variazioni delle performance, occorre applicarle con rigorosa precisione al fine di poter ricavare numeri utili e non solo cifre.

Più che la ricerca del KPI ottimale, è utile infatti eseguire le misurazioni con costanza e metodo, in modo da poter disporre di serie storiche affidabili e da poter quindi effettuare confronti, ipotesi, sperimentazioni.

Infine si dovrebbe sempre tener presente che l'utilizzo dei KPI è fondamentale per poter pianificare un piano evolutivo, ma che può essere errato se non pericoloso eleggere tali numeri a ruolo di guida indiscussa in una transizione agile. L'ambiente e il contesto, le persone, il prodotto sono tutti aspetti che spesso non è possibile misurare ma che rappresentano il baricentro di una organizzazione e della sua evoluzione.

Misurazioni e obiettivi

Ogni organizzazione ha un suo livello di performance realistico (ottimale?): spingere oltre tale limite oltre a non apportare alcun beneficio ulteriore, può anche essere fonte di un degrado delle prestazioni o peggio ancora avere conseguenze sia sulle persone (stress, peggioramento delle dinamiche di gruppo, abbassamento della qualità della comunicazione) che sul processo (aumento dei difetti, peggioramento della qualità, ritardi nella consegna e altro ancora).

Per questo motivo è importante tenere sotto controllo più che i numeri puntuali, l'andamento della serie storica, sia per enfatizzare i miglioramenti, sia soprattutto per individuare prontamente un peggioramento. La discesa da un picco di massimo rendimento dovrebbe mettere in guardia le persone dello staff: perch e' le cose stanno peggiorando? Cosa abbiamo fatto di diverso?. Questi andamenti al peggioramento dovrebbero poi essere di stimolo per attivare contromisure o soluzioni alternative: cosa potremmo fare di diverso? Quali altre opzioni possiamo provare?

La strategia dovrebbe essere sempre quella di agire e misurare, consci del fatto che non sempre le cose sul breve termine potrebbero migliorare immediatamente: si prenda ad esempio il caso relativo all'introduzione di nuove persone all'interno di un team che, sul breve periodo, peggiorerà le proprie performance (ne ha parlato tempo fa su queste pagine Pierluigi Pugliese illustrando il ciclo di Tuckman [1]).

Si noti che, dagli studi di analisi matematica, il picco di crescita rappresenta una posizione di instabilità: non è detto che sia possibile crescere indefinitamente e le performance potrebbero diminuire anche senza alcun intervento esterno. In tal caso è probabile che l'organizzazione stesse lavorando oltre le proprie reali possibilità (figura 1).

 

 

Figura 1 - A fronte di un qualsiasi intervento, le performance iniziano a diminuire: vuol dire che probabilmente si era giunti a un picco di massima crescita. In tal caso, per tornare a far crescere l'organizzazione, conviene trovare soluzioni alternative.

 

Metriche come strumento di allineamento

Le metriche sono quindi lo strumento per misurare gli effetti di una sperimentazione; è altresì vero che se non si nota alcun variazione del KPI scelto, è probabile che si stia misurando la cosa sbagliata.

Introdurre un KPI nel processo implica genericamente un costo sia diretto, il dover effettuare le misurazioni, che indiretto, legato per esempio alle conseguenze organizzative e politiche che si possono evincere dai risultati. Chiedere alle persone di misurare qualcosa legato al loro lavoro può essere a volte una richiesta scomoda, un jolly da giocare con attenzione. La scelta di una metrica dovrebbe quindi tenere in considerazione anche questi aspetti: è consigliabile sceglierne una compatibile con l'organizzazione, semplice da utilizzare e applicabile con costanza in maniera continuativa.

Molte sono quindi le raccomandazione che si potrebbero fornire quando si parla di introduzione delle metriche: è importante seguire il più possibile tali raccomandazioni, ma poi conta provare direttamente sul campo, lasciando anche da parte certe considerazioni teoriche inizialmente ritenute perfette. Solo sperimentando si potrà scoprire se quello che si sta provando a fare è utile.

In ultima battuta potremmo dire che le metriche dovrebbero essere strumenti di allineamento, più che un criterio di valutazione del successo: allineamento in modo che tutti possano essere informati dello stato delle cose.

Quali metriche scegliere?

Dopo questa doverosa premessa, resta da rispondere alla domanda principale: cosa si misura? Fra le varie opzioni possibili, un buon punto di partenza, potrebbe essere quello di scegliere una metrica fra quelle che sono utilizzate nella maggior parte dei casi: Cumulative Flow Diagram, Cycle Time/Lead Time, Defect Rate e Blocked Items.

Cumulative Flow Diagram (CFD)

Il Cumulative Flow Diagram (CFD) è un diagramma con il quale si rappresenta lo stato di avanzamento della lavorazione: in un certo senso è paragonabile al Burn Down Chart rispetto al quale viene spesso preferito a causa della capacità di rappresentare una visione aggregata di varie metriche; il CFD riesce in effetti a fornire efficacemente più informazioni e con un dettaglio maggiore. Per questi motivi, se da un lato il Burn Down Chart rappresenta lo strumento spesso utilizzato dai team alle prime armi, il CFD è invece adottato all'interno delle organizzazioni o dei team agili più maturi.

Come si può notare nella figura 2, il CFD mette a confronto nello stesso quadrante cartesiano la curva del backlog, ossia il diagramma del totale delle cose da fare, con i diagrammi corrispondenti alle varie sottoattività necessarie per completarle. L'ultima linea rappresenta l'ultima fase necessaria al completamento della attività, in questo caso il deploy finale. Quando la curva del deploy coincide con quella del backlog significa che tutte le cose da fare che erano in lista sono state completate.

Sull'asse orizzontale viene riportato il tempo espresso tipicamente in iterazioni (se si adotta Scrum) o semplicemente giorni (opzione tipicamente utilizzata se si lavora in Kanban). In verticale invece è riportato il numero di cose da fare.

 

 

Figura 2 - Il Cumulative Flow Diagram offre una visione di insieme dell'andamento del totale delle cose da fare e delle attività necessarie per completare tali attività.

 

L'inclinazione di queste linee è utile per comprendere come si comporta l'organizzazione o semplicemente come procede il progetto: per il backlog rappresenta la velocità con cui nuove cose sono messe nella lista delle cose da fare, mentre le altre curve indicano la performance puntuale delle varie sottoattività. Se l'inclinazione della curva del backlog è costantemente maggiore di quella del "done", significa che si stanno aggiungendo più cose da fare di quante il gruppo ne riesca realisticamente a realizzare.

La proiezione verticale (nel disegno indicata con vettore del WIP) fra la curva relativa alla prima fase della lavorazione (in questo caso la raccolta delle specifiche, curva grigia) e quella corrispondente all'ultima fase di lavorazione (in questo caso la celeste, deploy finale), rappresenta il numero di attività in lavorazione in ogni momento. Se il vettore del WIP aumenta, è probabile che sia in atto un rallentamento o, peggio ancora, un collo di bottiglia. Nella figura 2. per esempio. l'andamento del vettore del WIP è "sano", visto che esso diminuisce fino quasi ad azzerarsi, anche se dopo un aumento iniziale, il che è naturale, visto che spesso è necessario il completamento di molte attività tecniche per poter rilasciare in produzione.

La proiezione orizzontale rappresenta invece il tempo che impiega il team per completare la lavorazione di un elemento, ovvero il cosiddetto Cycle Time medio (nel diagramma: linea CT). Se invece si traccia una linea che parte dal tempo zero (nel diagramma: linea LT) si può calcolare il tempo complessivo che un elemento "spende" nel backlog prima che la sua lavorazione sia completata, ossia si ottiene il Lead Time medio (LT): da questo grafico si comprende meglio il concetto di questa grandezza, che è data da "tempo di attesa" più "tempo di lavorazione".

Il CT è una informazione interessante se si vuole capire come funziona il team, mentre il LT è interessante per comprendere il livello di servizio offerto, dato che rappresenta il tempo che un cliente attende prima che possa vedere evasa la sua richiesta.

È evidente che un diagramma di questo tipo offre numerose informazioni circa le performance del gruppo di lavoro; la sua compilazione è semplice dato che richiede che il gruppo di lavoro tenga traccia delle tempistiche di lavorazione (normalmente inizio e fine di un'attività) relativamente alle sotto attività.

Cycle Time

Il diagramma CFD permette di ricavare il Lead Time o il Cycle Time medio, due grandezze estremamente utili per capire come funziona il sistema. Come si è già avuto modo di accennare in precedenza, minore è il tempo di attraversamento di un elemento (Lead Time o Cycle Time: in questo caso il concetto non cambia), maggiore sarà la performance complessiva del sistema. Il teorema di Little e gli studi sulla teoria delle code confermano questo assunto.

Trattandosi di un valore medio riportato su un piano bidimensionale, la modalità di visualizzazione offerta dal CFD potrebbe non risultare sufficientemente efficace nel comunicare lo stato di salute dell'organizzazione. È per questo motivo che a volte si preferisce utilizzare strumenti più specifici come i diagrammi dei tempi di lavorazione (figura 3).

 

 

Figura 3 - Riportando i punti dei vari Cycle Time su un piano cartesiano, si può visualizzare in modo molto efficace sia il trend di tale grandezza che il grado di "sparpagliamento" ossia, usando un termine statistico, la varianza.

 

In questo caso si riportano su un piano cartesiano i valori di Lead Time o Cycle Time, in modo da poterne poi valutare l'andamento medio, dal quale si deduce se l'organizzazione sta migliorando le proprie performance, e la distribuzione dei valori rispetto alla media; questo secondo valore è utile per esempio per capire quanta è la "variabilità" in termini di effort necessario per completare le storie: in Scrum, parleremmo di peso delle storie.

Imparare a "confezionare" attività comparabili dal punto di vista dell'effort è un obiettivo comune a molte organizzazioni, dato che aiuta a stabilizzare il flusso e semplificare le attività di previsione; qualora il team sia in grado di controllare questo aspetto, per esempio come in Scrum dove è il Product Owner che prepara le storie, questo indicatore è quindi utile per valutare il grado di maturità del team. Anche quando il peso delle attività non dipende dal team, ad esempio quando le attività arrivano dall'esterno sotto forma di ticket di intervento da un help desk di primo livello, valutare la variabilità dei tempi di lavorazione è comunque utile per capire il grado di variabilità e quindi di difficoltà nel fare stime sulle attività future.

Da notare che il Cycle Time è un indicatore a posteriori e per questo dovrebbe essere utilizzato in combinazione con il CFD per avere una visione più completa.

Numero di elementi bloccati

Come più volte sottolineato, essendo il tempo di esecuzione di una attività (CT o LT) inversamente proporzionale alle performance complessive, appare chiaro che un elemento bloccato e bloccante può avere delle ripercussioni evidenti sulle prestazioni dell'intero ciclo produttivo. Il numero di elementi bloccati è spesso ricavabile da altri strumenti come il CFD o il CT, anche se spesso i team preferiscono evidenziarne numero e tempo di risoluzione in modo esplicito, tramite diagrammi appositi. Spesso il team utilizza per esempio icone dai colori vivaci e rappresentativi (rosso per i blocchi, arancione per gli impedimenti potenzialmente bloccanti) da attaccare sui cartellini della board: l'osservazione della board e della "macchia colore" permette di capire se ci sono problemi evidenti.

 

 

Figura 4 - Apporre dei simboli colorati alle attività in blocco o con impedimenti è un modo molto semplice ed efficace per evidenziare se c'è un problema da qualche parte. In alcuni casi invece si preferisce monitorare in modo più preciso questo aspetto, introducendo il KPI fra quelli di riferimento per la valutazione dello stato del sistema.

 

La figura 5 mostra un grafico dove sono riportati sia il numero di elementi bloccati che la media per la risoluzione del problema.

 

 

Figura 5 - Grafico degli elementi bloccati e del tempo medio di risoluzione

 

Defect rate

Misurare il numero di difetti prodotti, o meglio l'andamento del numero di difetti prodotti, permette di capire il livello di qualità del lavoro svolto. È un tipo di indagine particolarmente utile quando si introducono pratiche rivolte al miglioramento intrinseco del prodotto finito: dal pair programming, al test driven developement, dal miglioramento della raccolta dei requisiti al coinvolgimento degli utenti finali per la validazione del prodotto.

Come per tutte le grandezze viste fino ad ora non è tanto il numero assoluto di difetti a essere interessante quando il trend: se aumenta, perch e' aumenta? Si è cambiato qualcosa nel processo si lavorazione? Oppure i difetti aumentano perch e' semplicemente è aumentata la quantità totale di funzioni rilasciate e c'è quindi maggior probabilità che si creino problemi? E di che tipo sono gli errori che si presentano? Sono difetti puntuali o di interdipendenza fra le varie parti? Forse sta peggiorando la struttura complessiva? Forse non è stata fatta una opportuna scelta architetturale? È stata definita un'opportuna politica di governance delle parti rilasciate? È specificato cosa fare in caso di errore? Ci sono delle policy di versionamento?

Anche se le cose dovessero migliorare con la diminuzione del tasso di errori, è utile interrogarsi sul perch e': ci sono segni evidenti che il miglioramento sia dovuto a qualche azione o a elementi specifici, oppure è un caso? Dobbiamo aspettarci che possa peggiorare? Rispondere a queste domande può essere un ottimo punto di partenza per intraprendere le azioni opportune.

Oltre a tener traccia del numero di difetti prodotti ad ogni step di lavorazione (giorno, settimana, iterazione, sprint, o altro), può essere più efficace monitorare il trend del totale dei difetti aperti, vale a dire non ancora risolti. Un incidente può sempre accadere perch e' capita una iterazione "sfortunata" che produce un elevato numero di difetti a causa di un qualche problema che non si presenterà ulteriormente; ma il numero di difetti non risolti può essere più rappresentativo sia di una bassa qualità, sia di una inefficace policy di gestione degli errori.

Dalla misurazione alla previsione: definire gli SLA

L'introduzione di metriche come quelle viste fin qui, oltre a consentire di verificare gli effetti di qualsiasi tipo di intervento sul sistema, permette fare assunzioni sul tipo di output che potremo aspettarci dal sistema. Quando i numeri iniziano a prospettare una certa stabilità del sistema, si può pensare di impegnarsi in un certo livello di servizio (SLA, Service Level Agreement) nei confronti di clienti o stakeholder esterni.

Nella parte precedente abbiamo parlato di classi di servizio, vale a dire di un modo per classificare le differenti tipologie di attività in lavorazione. La definizione e l'applicazione di politiche di gestione coerenti in funzione delle differenti classi di servizio è spesso condizione abilitante al miglioramento delle prestazioni del sistema. Le metriche possono confermarlo a posteriori e, con il tempo consentono, di fare ipotesi sempre più affidabili su quello che ci si può aspettare.

Le classi di servizio e i corrispondenti SLA

Per esempio, riprendendo gli esempi fatti in precedenza, si erano identificate le seguenti classi di servizio:

  • Classe 1: bassa. Bassa priorità. Costo del delay non influente. Il trattamento specifico consiste nel mettere in fondo al backlog, lavorare se non c'è altro da fare. Quando la coda delle attività di questa classe supera le 5 unità, mettere in lavorazione quella più anziana.
  • Classe 2: standard. Media priorità. Costo del delay varia in base agli accordi contrattuali (rilasci ad ogni iterazione): è significativo ma non enorme. Trattamento specifico: lavorazione urgente ma non bloccante.
  • Classe 3: alta. Alta priorità. Costo del delay: ogni giorno passato in lavorazione costa 1000 €. Trattamento specifico: lavorazione urgente e bloccante; ogni altra attività deve essere interrotta. Se necessario, più persone possono mettersi a lavorare su un task di questo tipo.

Grazie alle informazioni che si sono potute ricavare dall'analisi dei numeri delle metriche, si potrebbero proporre dei livelli di servizio in questo modo:

  • Classe 1: bassa. Bassa priorità. SLA: tempo medio di risoluzione 20 gg; il 90% dei ticket chiusi in 25gg , tutti entro 30 gg.
  • Classe 2: standard. Media priorità. SLA: tempo medio di risoluzione 10 gg; il 90% dei ticket chiusi in 15 gg, tutti entro 20 gg.
  • Classe 3: alta. Alta priorità. SLA: tempo medio di risoluzione 5gg; il 90% dei ticket chiusi in 10 gg, tutti entro 12 gg.

Conclusione

Termina qui la trattazione su misurazioni e metriche da inserire all'interno di un processo Kanban. Ovviamente molte delle cose qui dette possono valere sia che si applichi una metodologia alternativa (per esempio Scrum) sia che si segua un processo non agile: sono concetti che valgono nella maggior parte dei casi, con i dovuti adattamenti. Nel prossimo articolo concluderemo questa serie affrontando un po' di teoria e di formule matematiche che possano dare una ulteriore giustificazione del come e del perch e' i concetti fin qui visti sono efficaci.

Riferimenti

[1] Pierluigi Pugliese, "Guida alla retrospettiva - IV parte: La dinamica di gruppo in una retrospettiva", MokaByte 197, luglio/agosto 2014

http://www2.mokabyte.it/cms/article.run?permalink=mb197_Retrospective-4

 

Condividi

Pubblicato nel numero
204 marzo 2015
Giovanni Puliti lavora come consulente nel settore dell’IT da oltre 20 anni. Nel 1996, insieme ad altri collaboratori crea MokaByte, la prima rivista italiana web dedicata a Java. Da allora ha svolto attività di formazione e consulenza su tecnologie JavaEE. Autore di numerosi articoli pubblicate sia su MokaByte.it che su…
Articoli nella stessa serie
Ti potrebbe interessare anche