Tecniche di stima agile

Abstract

La stima dello sforzo lavorativo nei progetti agili è fondamentalmente diversa dai metodi tradizionali di stima. L’approccio tradizionale è quello di stimare usando una tecnica “bottom-up”: dettagliare tutti i requisiti e stimare ogni attività per completare quei requisiti in ore/giorni, poi usare questi dati per sviluppare la schedulazione del progetto. I progetti agili, al contrario, usano un approccio “dall’alto verso il basso”, usando tecniche di stima a livello grossolano sui set di feature, quindi impiegando l’elaborazione progressiva e metodi di pianificazione a ondate per scendere al livello di attività su una base just-in-time, scoprendo iterativamente sempre più dettagli ad ogni livello inferiore. Questo articolo elaborerà due tecniche comuni per la stima agile (planning poker e affinity grouping), così come toccherà il modo in cui i risultati di questi esercizi forniscono un input nella previsione del programma e del budget.

Top-down vs. Bottom-up

Il metodo tradizionale per stimare i progetti consiste nel passare diverse settimane o mesi all’inizio di un progetto per definire i requisiti dettagliati del prodotto da costruire. Una volta che tutti i requisiti conosciuti sono stati elicitati e documentati, un diagramma di Gantt può essere prodotto mostrando tutti i compiti necessari per completare i requisiti, insieme alla stima di ogni compito. Le risorse possono quindi essere assegnate ai compiti, e azioni come il caricamento e il livellamento aiutano a determinare la data di consegna finale e il budget. Questo processo è conosciuto come un metodo bottom-up, poiché tutti i dettagli riguardanti il prodotto devono essere definiti prima che il programma e il costo del progetto possano essere stimati.

Nell’industria del software, l’uso del metodo bottom-up ha gravi svantaggi a causa della velocità di cambiamento di oggi. La velocità di cambiamento significa che la velocità dei nuovi strumenti di sviluppo e la velocità di accesso alle nuove conoscenze è così grande che qualsiasi ritardo nella consegna lascia aperto ad alternative competitive e in pericolo di consegnare un prodotto obsoleto (Sliger, 2010).

Il metodo top-down affronta questo problema chiave, usando le informazioni attualmente disponibili per fornire stime di livello lordo. La pianificazione a ondate viene poi usata per incorporare nuove informazioni man mano che vengono apprese, affinando ulteriormente le stime ed elaborando iterativamente con più dettagli man mano che il progetto procede. Questo metodo di imparare quanto basta per iniziare, con un piano per incorporare più conoscenze man mano che i risultati del lavoro si evolvono, permette al team del progetto di reagire rapidamente alle avversità e ai cambiamenti della domanda del mercato.

Tecniche di stima

Le tecniche di stima a livello lordo sono in uso nei team che usano approcci agili come Scrum e Extreme Programming, e questo articolo tratterà due delle tecniche più popolari: Planning Poker e Affinity Grouping. Verranno anche esaminate le unità di stima usate, poiché queste unità dovrebbero essere tali da non poter essere confuse con il tempo.

Planning Poker

La tecnica più popolare di stima a livello lordo è il Planning Poker, o l’uso della sequenza di Fibonacci per assegnare un valore di punto ad una caratteristica o elemento (Grenning, 2002). La sequenza di Fibonacci è una serie matematica di numeri che fu introdotta nel 13° secolo e usata per spiegare certi aspetti formativi della natura, come la ramificazione degli alberi. La serie è generata sommando i due numeri precedenti per ottenere il valore successivo nella sequenza: 0, 1, 1, 2, 3, 5, 8, 13, 21, e così via. Per scopi di stima agile, alcuni dei numeri sono stati cambiati, ottenendo la seguente serie: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Questi numeri sono rappresentati in una serie di carte da gioco (vedi allegato 1). I membri della squadra giocano a “Planning Poker” (allegato 2) per fornire una stima sotto forma di un valore di punto per ogni elemento. Ecco i passi:

• Ogni membro del team riceve un set di carte.
• Il proprietario dell’azienda (che NON deve stimare) presenta l’elemento da stimare.
• L’elemento viene discusso.
• Ogni membro del team seleziona privatamente una carta che rappresenta la sua stima.
• Quando tutti sono pronti, tutte le carte selezionate sono rivelate allo stesso tempo.
• Se tutti i membri del team hanno selezionato la stessa carta, allora quel valore è la stima.
• Se le carte non sono uguali, il team discute la stima con enfasi sui valori fuori scala:
  • Il membro che ha selezionato il valore più basso spiega perché ha selezionato quel valore.
  • Il membro che ha selezionato il valore più alto spiega perché ha selezionato quel valore.
• Seleziona ancora fino a quando le stime convergono.
• Se dovessero risultare conversazioni lunghe o “in-the-weeds”, i membri del team possono usare un timer di due minuti per cronometrare la discussione, selezionando di nuovo ogni volta che il timer scade, fino alla conversione.
• Ripetere per ogni elemento (Cohn, 2006, pp. 56-57).

Ci sono diverse ragioni per cui i numeri di Fibonacci sono usati, e usati in questo formato. La prima è la nozione che una volta che le squadre eliminano il tempo come base della stima, è meno probabile che chiedano più dettagli e gonfino le stime. Questi numeri invece rappresentano la dimensione relativa, non il tempo. Come risultato, l’esercizio di stima va abbastanza velocemente. Le squadre generalmente spendono circa due minuti su ogni elemento, permettendo di stimare un backlog di 30 elementi in un’ora. Il fatto che i team sono limitati a solo 9 scelte (cioè, valori di punti o carte) aiuta anche ad accelerare il processo.

La sequenza fornisce anche il giusto livello di dettaglio per le caratteristiche più piccole e meglio comprese, mentre evita un falso senso di precisione per stime più alte. Per esempio, una voce con una stima alta (20 o superiore) significa che la voce è grande e non ancora ben compresa. Discutere se l’elemento sia un 20 o un 19 o un 22 sarebbe una perdita di tempo perché semplicemente non ci sono abbastanza dati disponibili. Una volta che l’item si avvicina all’iterazione in cui sarà lavorato, può essere suddiviso in pezzi più piccoli e stimato in numeri più granulari (1-13). Gli elementi con stime di punti da 1-13 possono generalmente essere completati entro una singola iterazione (1-4 settimane).

È importante notare che i punti non hanno lo stesso significato nei vari team; per esempio, il “cinque” di un team non è uguale al “cinque” di un altro team. Quindi la velocità della squadra, che è derivata dai punti, non dovrebbe essere usata per confrontare la produttività tra le squadre.

Raggruppamento di affinità

Un modo ancora più veloce per stimare, e uno usato quando il numero di elementi da stimare è grande, è il raggruppamento di affinità. I membri del team raggruppano semplicemente gli articoli che sono di dimensioni simili, ottenendo una configurazione simile a quella dell’allegato 3. Il metodo è semplice e veloce:

• Il primo elemento viene letto ai membri della squadra e messo sul muro.
• Il secondo elemento viene letto e viene chiesto alla squadra se è più piccolo o più grande del primo elemento; il posizionamento sul muro corrisponde alla risposta della squadra (più grande è a destra, più piccolo è a sinistra).
• Si legge il terzo elemento e si chiede alla squadra se è più piccolo o più grande del primo e/o del secondo; l’elemento viene posizionato sul muro di conseguenza.
• Il controllo viene poi girato alla squadra per finire il raggruppamento di affinità per il resto degli elementi.

Le squadre possono scegliere di continuare nello stesso modo, mettendo un elemento alla volta sul muro dopo la discussione di gruppo. Tuttavia, un modo più veloce è quello di avere ogni membro della squadra che seleziona un elemento e lo colloca in base alla propria migliore comprensione. Questo viene fatto con tutti i membri della squadra che lavorano in parallelo fino a quando tutti gli elementi sono stati valutati e messi sul muro. Diverse centinaia di elementi possono essere stimati in un tempo relativamente breve. Una volta che tutti gli elementi sono sul muro, la squadra rivede i raggruppamenti. Gli elementi che un membro del team crede di essere nel gruppo sbagliato sono discussi e spostati se appropriato.

Una volta che il raggruppamento per affinità è completo, possono essere assegnati i valori delle unità di stima come i punti. Nell’allegato 3, il primo gruppo all’estrema sinistra sarebbe etichettato come avente un valore di 1 punto, il secondo gruppo sarebbe di 2 punti, il terzo gruppo di 3 punti, il quarto gruppo di 5 punti, e l’ultimo gruppo di 8 punti.

Il raggruppamento di affinità può essere fatto anche per altre unità di stima, come le dimensioni delle magliette. L’articolo 4 mostra un esempio di raggruppamento di affinità etichettato con le dimensioni delle magliette invece che con i punti.

Estimation Units

L’uso delle dimensioni delle magliette (Extra Small, Small, Medium, Large, Extra Large) è un altro modo di pensare alle dimensioni relative delle caratteristiche. Questo è un allontanamento ancora maggiore dal sistema numerico, e come tutte le buone unità di stima a livello lordo non può in alcun modo essere associato ad una specifica lunghezza di tempo.

Altri gettoni arbitrari di misura includono gli Orsetti Gummi, le NUTS (Nebulous Units of Time), e i piedi-libbra. Le squadre possono creare le proprie unità di stima, e come potete vedere, spesso si divertono un po’ nel farlo.

Questo documento non copre l’uso di unità basate sul tempo come giorni e/o ore di sviluppo ideali. Queste sono già comuni e ben comprese, quindi le loro spiegazioni non sono state incluse. Vale la pena notare comunque che la stima a livello lordo ha il potenziale per avere più successo quando è disaccoppiata dalla nozione di tempo. Poiché le stime di tempo sono spesso trasformate in impegni dal management e dal business, i membri del team sentono più pressione per essere il più precisi possibile. Di conseguenza richiedono sempre più dettagli sull’elemento da stimare. Questo trasforma la stima a livello lordo in una stima a livello di dettaglio che richiede più tempo e sconfigge l’intento e lo scopo originale.

Forecasting Schedule and Budget

Una volta che le stime a livello lordo e la velocità del team sono determinate, la pianificazione e il budget possono essere previsti. I team determinano la loro velocità sommando il numero totale di punti per tutti gli elementi che hanno completato in un’iterazione. Per esempio, una squadra può aver selezionato cinque articoli con un valore totale di 23 punti (vedi Esposizione 5). Alla fine della loro iterazione di due settimane, sono stati in grado di completare solo quattro dei cinque elementi. La loro velocità è 15, o la somma dei valori dei punti degli elementi 1-4. Le squadre non ottengono “credito parziale” per il completamento di porzioni di un elemento, quindi anche se avessero iniziato l’elemento 5, non conterebbe, poiché non è stato completato.

Determinazione del programma

La velocità media di un team è usata nella previsione di un programma a lungo termine. La velocità media è calcolata sommando le misure di velocità delle ultime tre iterazioni della squadra e dividendo il totale per tre. Così se una squadra ha completato 15 punti nella sua prima iterazione, e 20 punti in ciascuna delle due iterazioni successive, la velocità media della squadra è 18 (15+20+20 / 3). Se una squadra può fare in media 18 punti in un’iterazione, e ci sono 144 punti di lavoro da completare nel progetto, ci vorranno otto iterazioni per completare il lavoro (144 / 18). Se ogni iterazione è di due settimane, allora la previsione di completamento è di 16 settimane. Questo metodo ci permette di rispondere alla domanda: “Quando avremo finito tutto questo lavoro?”

Se la squadra ha un track record di dati di velocità, è possibile determinare la data di completamento più ottimistica, la più pessimistica e la più probabile. Il numero medio di velocità del team è usato per calcolare lo scenario più probabile, mentre i numeri di velocità dalle peggiori iterazioni del team sono usati per calcolare la data di completamento prevista più pessimistica. Usando la velocità dalle iterazioni in cui il team è stato in grado di completare più del previsto si ottiene la previsione più ottimistica.

Possiamo anche usare questi numeri per rispondere alla domanda, “Dobbiamo consegnare qualcosa entro questa data – di queste caratteristiche, quante ne avremo fatte per allora? Vedere l’Esposizione 6 per un esempio della previsione della quantità più probabile da completare, la previsione pessimistica e la previsione ottimistica. Questo esempio è per una squadra la cui velocità media è 20, e che ha una velocità di rendimento peggiore di 12 e una velocità di rendimento migliore di 25. Dato questo e solo sei settimane (tre iterazioni), quanto può essere completato? La previsione pessimistica è che solo gli elementi 1-8 saranno completati in sei settimane. La previsione ottimistica è che gli elementi 1-18 saranno completati. E la previsione più probabile, basata sulla velocità media del team di 20, è che gli elementi 1-13 saranno completati in sei settimane.

Se i team stavano usando unità di stima non numeriche come le dimensioni delle magliette, gli algoritmi di previsione saranno più complessi. Si raccomanda di convertire le taglie in un sistema numerico per generare più facilmente dati simili. Per esempio, una Small potrebbe essere convertita in una NUT di 3, una Medium in una NUT di 5, e così via. Questi possono anche essere convertiti in intervalli di tempo (un Piccolo potrebbe essere 1-3 giorni, per esempio) ma questo è intrinsecamente rischioso, a causa dei problemi già citati nella sezione Unità di stima.

Determinazione del budget

In questa sezione cerchiamo di rispondere: “Abbiamo solo questo denaro – quanto durerà e quanto avremo fatto prima di finire? Per prima cosa, si usa una semplice formula per determinare il costo per punto:

Σ (stipendi della squadra caricati per il periodo n) / punti completati nel periodo n

Prendi la somma degli stipendi della squadra (caricati) per un periodo di tempo, diciamo tre iterazioni di due settimane, e dividila per il numero di punti che la squadra ha completato nello stesso arco di tempo. Così una squadra i cui stipendi totali caricati sono 240.000 dollari in sei settimane, e ha completato 60 punti di lavoro in quelle tre iterazioni, avrebbe un costo per punto di 4.000 dollari. Ora usa la seguente formula per determinare il budget:

(Costo per punto x valore totale dei punti da completare) + altre spese = budget previsto

Spesso non tutte le caratteristiche di un prodotto sono definite all’inizio di un progetto, il che è come ci si aspetta per i progetti agili. Quindi le stime del budget si basano su ciò che sappiamo oggi, più un algoritmo di previsione che si basa su dati storici o sulla guida di esperti. Per esempio, diciamo che ci sono solo 20 caratteristiche elencate finora, ma l’azienda non sarà in grado di fornire ulteriori richieste di caratteristiche o perfezionamenti fino a quando non si vedrà come la prima release viene ricevuta dal cliente. Il budget per il progetto, che è previsto per tre release, avrebbe solo i dati di previsione disponibili per la prima release e non per l’intero progetto. Il team potrebbe usare l’algoritmo di cui sopra per prevedere il budget per la prima release, poi assumere un ulteriore 20% per la seconda release e un ulteriore 5% per l’ultima release, sulla base dell’esperienza passata.

Come la velocità, le previsioni di budget e di schedulazione sono riviste ad ogni iterazione. Questo fa parte del processo di pianificazione rolling-wave che i progetti agili seguono.

Parole finali

In particolare non è stata trattata in questo documento la mancanza di tecniche di stima strutturate usate negli approcci lean come Kanban. Piuttosto che spendere (sprecare) tempo per stimare gli articoli, il ciclo medio e i tempi di consegna sono calcolati sulla base dei tassi di rendimento effettivi del team. Kanban usa il teorema matematico Legge di Little come base per le sue formule. Usando i calcoli dei tempi di consegna derivati dai diagrammi di flusso cumulativi, i team prevedono le scadenze dei progetti senza spendere del tempo in anticipo per preparare le stime. Il lettore è incoraggiato a fare una ricerca indipendente su questo argomento, che potrebbe essere un articolo separato da solo.

I progetti Agile sono destinati a consegnare un prodotto o incrementi di prodotto presto e spesso, al fine di incorporare il feedback dei clienti e altri apprendimenti nel rilascio successivo. Dedicando più tempo alla sperimentazione, all’esecuzione e all’apprendimento, e meno tempo alla speculazione, il tempo del ciclo di consegna si riduce. I team agili sono meglio in grado di competere sul mercato e tenere il passo con la sempre crescente velocità del cambiamento.