Agile Life

gennaio 2014 - Post

ALM, Little’s Law

La legge di J. Little (Little’s Law) è un caposaldo nella gestione delle code e dei processi, ed è espressa come segue:

         Wq = Lq / λ

dove:

  • Wq = tempo medio di attesa nella coda di un processo (lead time);
  • Lq = numero medio di processi in coda (wip);
  • λ = tempo medio necessario al completamento del processo (throughput).

Il senso di questa legge è la formalizzazione di come se si vuole ridurre quanto più possibile il tempo di attesa nella coda, sia necessario intervenire su due fronti: ridurre il numero medio dei processi in coda (Lq) e/o aumentare il tempo medio di esecuzione di un processo (λ). Ma cosa centra tutto questo con la gestione di un progetto software? Ebbene, il nostro Backlog (di Team o di Program che sia), può essere assimilato facilmente ad una coda priorizzata, così come il numero dei processi diventa il numero dei WorkItem in essa presenti e il tempo medio di completamento diventa il numero di WorkItem che vengono completati in una singola iterazione.

Facciamo un esempio:

  • User Story presenti nel Backlog = 100;
  • N. User Story completati in una iterazione (2 settimane) = 15;
  • Wq = numero di iterazioni medie di attesa per una nuova funzionalità.

applicando la formula ottengo che Wq = 100/15 = 6,66 + il tempo dell'iterazione stessa per lo sviluppo. Ciò significa che, in media, per ottenere una nuova funzionalità devo aspettare quasi 8 iterazioni, circa 3 mesi!
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.

 

[FELICEPESCATORE.IT]

ALM, uno sguardo alle Feature

Dopo aver dedicato un post alla priorizzazione delle User Story, facciamo un salto nel “Program Level” (cit. SAFe) e soffermiamoci sul Program Backlog e, in particolare, sulle feature.

E’ possibile pensare alle feature come un aggregato di User Story, ovvero una vista ad alto livello di un gruppo di funzionalità affini che vengono realizzate per assolvere uno specifico compito.

In realtà, inizialmente, nel contesto Agile, si è cercato di introdurre la gerarchia Temi->Epic->User Story, ma questa, per motivi storici di utilizzo di termini analoghi largamente diffusi, è spesso sostituita da Epic->Feature->Work Item. Lo stesso TFS contempla esplicitamente le “feature”.

>tfs2013 feature

Feature in TFS 2013


Le feature sono un elemento fondamentale del processo di relazione tra committente-produttore, trasformando la Vision del Prodotto nelle macro-funzionalità che il sistema andrà ad offrire. In tal modo, si dota il Product Manager di uno strumento che gli permette di “dialogare” agevolmente con i Key Stakeholder, mentre il Product Ownerdiventa responsabile di un set di funzionalità da affidare al proprio Team.

Tipicamente, le feature vengono formalizzate dagli attori coinvolti nella definizione degli obiettivi di business (cosa che in DAD avviene nella fase di Inception), espressi nella classica User Voice Form:

Essendo un Utente telefonico, voglio poter ricevere notifiche automatiche da parte del mio operatore, così da attivarmi in caso di promozioni o problemi

Ma le feature non condividono con le User Story solo la forma descrittiva, in quanto anche la stima dell’effort viene tipicamente effettuata (con la dovuta valutazione della maggiore incertezza e l’occhio rivolto principalmente al business) in Story Point (Ideal Day). Il tutto è affidato al team di Product Management in congiunzione ai Product Owner.

Quello che invece si differenzia sensibilmente è l’attività di priorizzazione.

Di primo acchito si potrebbe ipotizzare di priorizzare la feature in base al ROI (Return of Investments), calcolato come il rapporto tra Valore (prezzo) e Costo di sviluppo. Il punto è che tale stima non tiene conto di un fattore che D. Reinertsen ha dimostrato essere fondamentale: il Cost of Dealy (CoD), ovvero il costo associato al ritardo dello sviluppo di una specifica funzionalità, calcolabile come aggregato di tre valori fondamentali: User value, Time value e Risk Reduction value.

Senza voler entrare troppo nella descrizione di dettaglio (per approfondimenti: The Principles of Product Development Flow: Second Generation Lean Product Development), Reinertsen propone alcune regole pratiche di priorizzazione:

  • Se due feature hanno lo stesso CoD, è opportuno sviluppare prima quella che richiede meno effort;
  • Se due feature richiedono lo stesso effort di sviluppo, è opportuno realizzare prima quella con il maggior CoD.

Il problema è che, nella maggior parte dei casi, è difficile effettuare una comparazione diretta tra l’effort e il CoD di due feature (ciò è vero soprattutto nell’ambito del software). Per questo è opportuno ricorrere ad una terza tattica:

  • Se due feature hanno effort realizzativo e CoD differenti, è opportuno realizzare quella che minimizza il rapporto tra i due valori CoD/Effort. Tale tattica è definita come Weighted Shorted Job First (WSJF).

Facciamo un esempio pratico (scala dei valori da 1:10, con 10 valore massimo):


 

Cost of Delay

   
 

User Value

Time Value

Risk R. Value

Totale

Effort

WSJF (Tot/Effort)

Feauture A

4

9

8

21

4

5.3

Feauture B

8

4

3

15

6

2.5

Feauture C

6

6

6

18

5

3.6


Dalla tabella si evince che la feature con maggiore priorità è la “A”, anche non avendo il maggior Valore per l’utente. Questo è assolutamente in linea con un approccio che non tiene solo conto del Valore, ma che armonizza vari aspetti (Valore, Tempo e Rischio), al fine di produrre il maggior Valore complessivo.

L’approccio appena presentato, seppur considerando fattori diversi orientati al business, è in linea con quello già proposto per il calcolo della priorità delle User Story, ottenendo, così, una soluzione più analitica e rigorosa rispetto alla semplice assegnazione di un valore basato esclusivamente sull’esperienza di chi effettua la stima stessa.

[FELICEPESCATORE.IT]
ALM, torniamo sulla priorizzazione dei Work Item

Nel precedente post “ALM, priorizzare le User Story per Valore… ma non solo”, abbiamo definito l’Iteration Value di una User Story, ovvero una stima più profonda (deep estimation) del principale Work Item a livello Team (rif. SAFe, Leffingwell, in DAD siamo nella fase di Construction).

In breve, con uno scope più esteso, non legato esclusivamente alle User Story, abbiamo:

Iteration Value = Business Value + Risk Value + Team Engagement Value.

Quello che non abbiamo completamente esplicitato è l’Estimation Timing, ovvero in quale momento avviene la stima dell’Iteration Value. Ebbene, possiamo considerare l’Iteration Value come la somma di due stime che avvengono in momenti differenti:

Iteration Value = [Work Item Value]T0 + [Team Engagement]Ti

riconoscendo due metriche diverse:

  • Il Work Item Value (Business + Risk Value) è la stima che viene effettuata all’atto della priorizzazione del Team Backlog. Tale stima viene tipicamente effettuata con discreta profondità dal Product Owner (e se presente dal Product Manager), con il supporto del Team, ad inizio del nuovo ciclo di iterazioni. E’ utile chiarire che con “Team Backlog” si intende l’insieme dei Work Item relativi alle feauture presenti nel Release Backlog (derivato a sua volta dal Program Backlog) affidati al Team specifico, nel caso in cui più Team sono coinvolti nello sviluppo. Se siamo in presenza di un unico Team, è possibile ricondurre il tutto all’uguaglianza: Release Backlog = Team Backlog;
  • Team Engagement Value è la stima che viene associata al Work Item al momento in cui viene creato il Backlog di Iterazione.

In sostanza, i Work Item possono essere rivalorizzati just-in-time all’avvio di una nuova iterazione, seguendo più velocemente l’evoluzione del team.

Facciamo un rapido esempio: il Product Owner (e il Product Manager se presente), con il supporto del Team, a T0 definisce il Work Item Value per ogni elemento presente nel Team Backlog. Dopo 4 iterazioni (T4), lo stato del Team Backlog è il seguente:

#Work Item

Business Value

Risk Value

Work Item Value

3

1

8

9

4

6

2

8

1

4

3

7

….

….

….

….

Team Backlog a T4

Ipotizziamo che la nostra Velocity sia di 20 story point, cosa che ci consente di realizzare, nella nuova iterazione (5), la WI3 e WI4.

Ma siamo sicuri che la priorità associata inizialmente ai Work Item del Team Backlog non vada rivista per tener conto della storia delle iterazioni completate? La risposta è senza ombra di dubbio no! Anzi, è sicuramente l’opposto.

A questo punto qualcuno potrebbe chiedersi: “perché non ripriorizziamo l’intero Team Backlog?” L’osservazione è corretta, ma se l’approccio può essere proficuo per un Team Backlog non particolarmente ampio (20-25 Work Item), cosa accade se abbiamo un Team Backlog di 100 Work Item? (ok, non è il massimo, come dimostreremo con la Little’s Law, ma rende l’idea J). Inoltre, se il Team Backlog è un sottoinsieme del più ampio Release Backlog, le modifiche che vado ad apportare come influenzano, direttamente o indirettamente, quest’ultimo, più vicino agli obiettivi di business?

Ebbene, proprio per coniugare le diverse esigenze ci viene in soccorso il Team Engagement Value:

#Work Item

Work Item Value

Team E. Value

Iteration Value

3

9

2

11

4

8

4

12

Team Backlog rifattorizzato

In questo caso, l’Iteration Value del WI4 è superiore a quello del WI3, sovvertendo, di fatto, l’ordinamento in funzione alla storia del Team. In linea di massima è possibile anche decidere di ignorare del tutto il Team Engagement Value, considerando il relativo valore pari a 0, e utilizzando un Iteration Value = Work Item Value.

Per tener traccia di tutte queste informazioni, sfruttando TFS on premises (purtroppo non Visual Studio Online che ancora non permette le modifiche ai process template), possiamo modificare la definizione del Work Item, aggiungendo i campi relativi, in modo più strutturato rispetto a quanto presentato sempre nel post citato all’inizio.

Per fare le modifiche necessarie, è possibile ricorrere ai Microsoft Visual Studio Team Foundation Server 2013 Power Tools e operare da Visual Studio 2013 connettendosi direttamente a TFS. In alternativa si può scegliere di editare manualmente il file xml del Process Template in uso.

Il risultato dovrebbe essere simile al seguente:

iteration value2

La cosa importante è che, in questo modo, si riduce l’impatto della stima UP-Front (Work Item Value) che, per quanto minima, comunque non è in grado di predire l’evoluzione del Team, soprattutto in contesti nuovi.

Nei prossimi post torneremo su questi argomenti, introducendo il concetto di Weighted Shorted Job First, associato alla priorizzazione delle feature, elemento fondante del Program e Release Backlog (SAFe, Leffingwell - in DAD siamo nella fase di Inception), e parleremo della già citata Little’s Law.

We must INVEST on our User Story!

Una delle domande tipiche che vengono poste nell’adozione dell’Agile, soprattutto da parte di nuovi Team e nell’introduzione in contesti non-agili, è:

“Quanto deve essere dettagliata una User Story al fine di poterla considerare una buona User Story”?

Come abbiamo sempre evidenziato (e come non smetteremo mai di dire) per adottare pratiche e metodologie Agili, nel proprio contesto, non esiste una formula magica e, di conseguenza, non esiste una risposta univoca a tale domanda, anche se, anni di esperienza sul campo, hanno portato Bill Wake ad individuare 6 caratteristiche fondamentali di cui tener conto:

  • Independent: le User Story devono essere quanto più indipendenti tra loro, in modo da rappresentare un segmento di VALORE ben identificato;
  • Negotiable: finché la User Story non entra a far parte di uno specifico backlog di iterazione, deve sempre essere possibile intervenire su di essa, riscrivendola o, al limite, cancellandola dal backlog di release;
  • Valuable: le User Story devono sempre produrre del VALORE direttamente percepibile dai key stakeholder;
  • Estimable: deve sempre essere possibile stimare la complessità (dimensione) della User Story;
  • Small: una User Story deve essere sufficientemente piccola da poter essere inserita in una iterazione e, possibilmente, non saturarla;
  • Testable: deve essere oggettivamente verificabile.

In sintesi I.N.V.E.S.T.


[FELICEPESCATORE.IT]

Posted: 3 gen 2014 20:21 da felice.pescatore | con no comments
Inserito sotto: , , ,