Cumulative Flow Diagram

Nel precedente post abbiamo analizzato quelli che sono i principali parametri temporali che possiamo utilizzare per monitorare il nostro flusso di lavoro, facendo cenno, in chiusura, al Cumulative Flow Diagram (CFD). Vediamo in questo post come sfruttare adeguatamente il CFD per estrarre informazioni particolarmente utili a tracciare l’andamento delle attività in corso.

Il Cumulative Flow Diagram è uno strumento in pieno stile Agile/Lean, consentendo di avere rapidamente una visione di quanto sta accadendo nel proprio team (o se si preferisce nello sviluppo della propria soluzione) e anticipare azioni correttive a supporto. Non è uno strumento di precisione, nel senso che l’inidviduazione della causa puntuale del problema richiede specifiche indagini (root case analysis), e la sua lettura non è assoluta ma relativa, nel senso che è relazionata alla storia specifica del team.

Detto ciò, cominciamo a capire come leggere il nostro CFD:

cfd 01

Simple CFD

Il CFD è strutturato su due assi che rappresentano il numero delle feature (o dei task) da sviluppare e il tempo trascorso dall’inizio delle attività. Tra di essi, vengono riportate quattro diverse relazioni primarie:

  • I task completati
  • I task in test
  • I task in lavorazione
  • I task non ancora iniziati

Tali suddivisioni non sono generiche, ma rispecchiano il mondo in cui è organizzata la Kanban Board, ovvero in funzione delle sue colonne:

cfd kanban

CFD, Kanban Board

E’ quindi ovvio che le informazioni possano variare, ma di norma quelle presentate sono praticamente sempre presenti, potendo estrarre da esse le miusre temporali di cui abbiamo discusso nel post precedente:

cfd 02

“tempo”

Presentati gli aspetti salienti del CFD, vediamo ora una serie di casistiche (derivate da un post di Pawel Brodzinski @pawelbrodzinski) che possono essere particolarmente significative e che ci consentono di prendere maggiore confidenza con questo diagramma.

Caso ideale

cfd 01

CFD, Caso Ideale

In questo caso tutti gli elementi hanno un andamento ideale, ossia un incremento costante contraddistinto da un ritmo sostenibile dal team, in linea con quelle che sono le aspettative di deployment finale. Si tratta di una situzione di riferimento a cui tendere, che però raramente è raggiunta in modo completo.

Divergent

cfd 03

Divergent

In questo caso si ha un andamento divergente delle diverse linee di riferimento, ad esclusione del Product Backlog che, per propria natura, ha una variazione unitaria. Si tratta di una situazione estremamente pericolosa che porta ad un forte aumento del WIP e una drastica riduzione del cycle time, ovvero del numeo di task completati. E’ necessario capire quali sono gli impedimenti ed intervenire sul WIP-limit in modo da ridurre il carico di lavoro, ripristinare un adeguato cycle-time e ridurre anche il costo del multitasking associato alla singola risorsa che, sicuramente, è adanto crescendo.

Dev-Testing

cfd 04

Dev-Testing

In questo caso si nota una profonda distanza tra l’attività di Dev e quella di Testing. Ciò può indicare che non si riesce facilmente a completare i task e renderli disponibili per le attività di Test, così come il fatto che ques’ultima si è pericolsamente ridotta ai minimi termini.

Quality Smell

cfd 05

Quality Smell

In questo scenario troviamo un gap significativo tra il Test e i task in Done. Questa situazione è sintomo di una scarsa qualità e attenzione al testing stesso, indicando un team che è principalmente preoccupato di aprire nuovi task per il raggiungimento dell’obiettivo di deplyment finale. Da evidenziare anche l’andamento della Done-line che è tipica di un delivery con cadenza programmata (es: settimanale, mensile, ecc…).

Full Flatten out

cfd 06

Full Flatten out

In questo caso le linee risultando appiattite (flatten out) per uno specifico intervallo temporale. Le cause, in questo caso, possono dipendere da fattori legati alla specifica finestra temporale (es: chiusura aziendale) ma anche a problemi tencinci, come ad esempio l’indisponibilità degli ambienti di Test a causa di una rottura dei server.

Partial Flatten out

cfd 07

Partial Flatten out

Questo scenario è fratello del precedente, ma essendo legato a solo due dei valori di riferimento, esclude la causa dovuta a fattori come, ad esempio, la chiusura aziendale per ferie. Qui è più probabile che ci siano problemi sugli ambienti di Test, anche se sarebbe opportuno non avviare ulteriore attività ma collaborare in chiave DevOps per risolvere i problemi.

Skyrockets

cfd 08

Skyrockets

Questo scenario è inizialmente simile al Divergent anche se poi alla fine si ha una vera e propria impennata delle curve e magicamente le tempistiche sono rispettate. Scartando che il team sia diventato super veloce per magia, una delle possibili spiegazioni è che lo stesso si era precedentemente “rilassato” e che solo “sotto pressione” abbia dato il meglio di se.

Time Boxing

cfd 9

Time Boxing

Questo CFD può lasciare inizialmente interdetti, visto la presenza di molti dei problemi evidenziati in precedenza: gap tra Dev e Test, Done-line piatta, impennata finale. Tutto vero, ma approfondendo un attimo l’analisi, ci si accorge che la Done-line (come detto in precedenza per il caso Quality Smell) è tipica dei rilasci cadenzati, mentre l’impennata finale rappresenta un elemento di auto-organizzazione temporale: in sostanza siamo difronte ad un periodo di sviluppo Time Boxed, tipico ad esempio di Scrum. Questo implica che non sia presente un WIP-limit, giustificando l’incremento significativo del WIP già a metà del periodo di riferimento. Inoltre, il ragionamento è avvalorato dal fatto che la linea rappresentate il Product Backlog, a differenza degli altri casi, resta piatta fino alla fine, cosa tipica di una Iterazione/Sprint.

Fixed Price & Fixed Date Project

cfd 10

Fixed Price & Fixed Date Project

In questo diagramma cumulativo, sia gli aspetti di Dev che quelli di Test sembrano assolutamente in linea con un andamento ideale, ma la Done-Line resta praticamente piatta fino al Deployment finale, dove si impenna repentinamente. Si tratta, con molta probabilità, di una condizione in cui il progetto è Fixed Price e Fixed Data, prevedendo un unico deploy finale, con tutti i rischi del caso, visto che i problemi non vengono affrontati progressivamente durante la fase di sviluppo.

Change Scope

cfd 11

Change Scope

In questo CFD, sia ha un cambiamento di scope, ovvero di obiettivo del progetto, rappresentato dal forte gradino della Backlog-line. Se questo avviene in modo concordato con il cliente, che, ad esempio, chiede di passare alla versione 2.0 della nostra soluzione, nulla di preoccupante, anzi. Se, però, siamo in presenza di un contratto Fixed Price e il problema è dovuto al fatto, ad esempio, di non aver ben compreso le necessità del Cliente… beh, è tutta un’altra storia e la situazione si fa estremamente difficile. Resta il fatto che il problema, in questo caso, non è la governance del flusso di lavoro, bensì quella del Product Backlog.

Back Fast to Product Backlog

cfd 12

Back Fast to Product Backlog

In questo CFD, sia ha una condizione strana: a un certo punto (dopo il picco di discesa) il gap tra la Dev-Line e la Test-Line diminuisce, ma ciò non è imputabile ad un aumento degli elementi in Done che non subisce una variazione significativa corrispondente. Dove sono finiti i task precedentemente in Test? Per rispondere adeguatamente è necessario investigare sulla questione, ma una delle risposte potrebbe essere che “sono tornati” nel Product Backlog, anche in relazione alla corrispondente salita della linea relativa. Ciò può avvenire, ad esempio, in seguito ad un cambiamento dei requisiti o a una feature non proprio in linea con quanto richiesto.

Back Late to Product Backlog

cfd 13

Back Late to Product Backlog

Questo caso rispecchia quanto evidenziato nel caso precedente, solo che ci si accorge dei problemi all’atto dei Test di Accettazione, pagando uno scotto maggiore perché quanto realizzato e testato non è in linea con quanto atteso.

Jump out from the Product Backlog

cfd 14

Jump out from the Product Backlog

Questo CFD mostra il caso in cui alcune feature vengono rimosse volontariamente dal Product Backlog, in funzione degli aspetti emersi durante il Test. Infatti, la Done-line preserva un andamento costante, nonostante la variazione degli altri due elementi, caratterizzati prima da un picco e poi da un’inflessione che, sostanzialmente, annulla la prima.

I task relativi sono stati rimossi, in attesa, ad esempio, che la feature venga ri-discussa con il cliente o che si trovi una soluzione tecnica migliore per realizzarla.

Dai casi discussi è chiaro che il CFD è uno strumento estremamente utile per avere un quadro d’insieme dello stato di avanzamento del flusso di lavoro, consentendo di evidenziare eventuali situazioni anomale e individuare, a grosse linee, l’area di attenzione sui cui concentrarsi per la root case analysis.

Visual Studio Online (e TFS) genera automaticamente il CFD relativo al progetto in corso, in funzione dello stato corrente. In tal modo è possibile monitorare costantemente ciò che sta accadendo all’interno del nostro sistema.

cfd vso

VSO CFD

q

Comments are closed.