La legge di J. Little (Little’s Law) è un caposaldo nella gestione delle code e dei processi, ed è espressa nella forma:
L = λ* W, con:
- L = numero medio di elementi in coda (WIP);
- W = tempo medio speso nella coda/completamento (Lead Time);
- λ = tempo medio di arrivo di nuovi item nella coda.
Nel mondo dello sviluppo software, la coda (priorizzata) è assimilabile all’Iteration Backlog, e la legge di Little assume una forma leggermente differente:
Wq = Lq / λ
dove:
- Wq = tempo medio di attesa nella coda di un Work Item (Lead Time);
- Lq = numero medio di Work Item in lavorazione (WIP);
- λ = numero medio di Work Item completati nell'unità di tempo di riferimento (Throughput).
Il senso di questa legge è la formalizzazione di come se si vuole ridurre il tempo di attesa nella coda (Wq) è possibile intervenire su due fronti: ridurre il numero medio di Work Item in coda (Lq) e/o aumentare il tempo medio di esecuzione dei Work Item (λ).
Facciamo un esempio, prendendo come intervallo T di riferimento una Iterazione di due settimane:
- (Lq) User Story presenti nel Backlog = 100
- (λ) N. User Story completati in una iterazione (2 settimane) = 15
applicando la formula ottengo Wq = 100/15 = 6,66 iterazioni: ciò significa che, in media, per ottenere una nuova funzionalità devo aspettare quasi 8 iterazioni, circa 3 mesi!
E’ fondamentale evidenziare che il Lead Time (Wq) ha una quantizzazione leggermente se applicata al Program Backlog, ovvero:
Wq Program Backlog + Wq Iteration Backlog, con:
Wq Program Backlog = Lq / λ (N. User Story scelte per essere inserite nell’Iteration Backlog).
Visto così, il nostro approccio sembra tutt'altro che "Agile", ed è proprio questo il motivo per cui, nei post precedenti, abbiamo più volte ribadito che non è utile avere un Backlog troppo ampio e troppo elaborato, perché questo trasforma il nostro approccio Agile/Lean based in uno condizionato direttamente da una filosofia BigUpFront analysis, anche se applicata in modo inconsapevole.
Per ridurre al minimo il valore di Wq possiamo adottare delle tattiche che mirino a:
- Ridurre Lq
- Avere un numero sufficiente di User Story (o Feature) a comprendere la vision di ciò che si sta facendo, senza però generare un overhead confusionale;
- Incrementare λ
- INVEST in User Story;
- Aumentare la capacità del Team, spingendolo a diventare un High Performance Team;
Riuscendo a diminuire Wq, indipendentemente dalle tattiche adottate, si ottengono degli indubbi benefici nella gestione del progetto:
- Diminuire il Rischio associato alla User Story: più una User Story viene mantenuta in coda, più è alto il rischio che venga superata dall'evoluzione stessa del progetto;
- Diminuzione dell'Effort di popolamento del Backlog: l'inserimento di una User Story richiede lavoro e tale lavoro può risultare inutile se essa diventa superata per l'eccessiva lunghezza della coda;
- Riduzione della Qualità: un Backlog eccessivamente lungo ritarda la possibilità di avere feedback tempestivi, ritardando, quindi, la verifica dell'attinenza di quanto realizzato con quanto realmente atteso dagli stakeholder;
- Riduzione della Concentrazione: se i feedback arrivano troppo tardi, è fisiologico che il Team percepisca le attività annesse alla User Story come "non-urgenti", rilassando la propria attenzione.
