Stima

Articolo
06/10/2015

Di Mitch Lacey. Proprietario, Mitch Lacey & Associates, Inc, un'azienda di consulenza che si specializza in adozioni e miglioramenti Agile e scrum.

Gennaio 2012

Mitch Lacey illustra le difficoltà della stima del progetto software e fornisce consigli e suggerimenti per l'utilizzo di due tecniche di stima del software Agile per la stima dei progetti.

Si applica a

Application Lifecycle Management; Team Foundation Server

Contenuto

Introduzione
Difficoltà della stima
Tecniche di stima
Punti della storia come unità di misura
Planning Poker
Wall Estimation
Stima
Priorità
Conclusione

La stima del lavoro che è qualcosa di creativo e non prevedibile è tuttavia difficile. La scelta di un metodo è ugualmente costosa. Fred Brooks lo dice molto bene: "È molto difficile difendere in modo vigoroso, plausibile e rischioso una stima derivata da nessun metodo quantitativo, supportata da pochi dati e certificata principalmente da dalle impressioni degli amministratori".

Eppure viene richiesto di fornire stime per i progetti software nelle prime fasi e, nonostante tutti gli sforzi per ricordare alla Dirigenza che tali stime sono approssimative, troppo spesso vengono convertite in impegni.

In questo articolo illustrerò perché è difficile effettuare una stima preliminare dei progetti, in che modo sono utili le tecniche di stima del software Agile e come stimare il backlog del prodotto utilizzando la tecnica planning poker e i punti della storia.

Difficoltà della stima

Nella maggior parte dei progetti, ci viene richiesto di effettuare una stima preliminare. Per comprendere il problema, è necessario esaminare il cono dell'incertezza, che Barry Boehm ha presentato nel 1981 e Steve McConnell ha reintrodotto nel 1997 nel suo libro Software Project Survival Guide.

Cono di incertezza

Il cono illustrato che è la maggior parte delle incertezze all'inizio del progetto (una varianza di 4x a 0,25x nell'intervallo). Questa varianza indica che ciò che si stima essere un progetto di un anno potrebbe alla fine richiedere da 3 a 48 mesi. L'inizio del progetto è il tempo in cui siamo meno il sicuro sul progetto, ma è anche quando è richiesto di fornire le stime che sono molto precise.

In Agile cerchiamo di passare dall'incertezza alla certezza in un ciclo più breve possibile. Per ottenere questo risultato si ottimizzano i primi studi del sistema e di come dovrebbe essere progettato. A questo scopo, viene creato un singolo percorso nel sistema, una storia completa e funzionante. In questo modo è possibile rimuovere i presupposti dei requisiti e di progettazione nelle prime fasi del progetto e ottenere certezze con più rapidità e sicurezza.

Tecniche di stima

È disponibile un'ampia varietà di tecniche valide di stima, inclusi il conteggio, l'intervento di esperti (utente e gruppo), la scomposizione, l'analogia, la stima del proxy, il planning poker e la wall estimation. È possibile utilizzare anche strumenti quali Cocomo II. Tutte queste tecniche richiedono la scelta di un'unità di stima (ore, giorni, settimane, mesi, giorni ideali, misura della maglietta, punti). Se non si comprende l'unità, la stima non ha alcun significato. Tenendo conto di tutto ciò, non c'è da meravigliarsi se si combatte con una stima.

Sebbene i team Agile gravitino attorno a una determinata versione di unità di stima e tecniche per la stima del backlog prodotto (punti della storia e planning poker), il team deve sentirsi libero si utilizzare il metodo più adatto alle proprie esigenze. Secondo la mia esperienza, esprimere le stime in termini di punti della storia, utilizzando la tecnica detta planning poker o wall estimation, produce i migliori risultati. Nei paragrafi seguenti verranno fornite informazioni sui punti della storia come unità di misura e due tecniche di stima che preferisco, denominate planning poker e wall estimation.

Punti della storia come unità di misura

Mike Cohn sintetizza ottimamente i punti della storia "i punti della storia sono un'unità di misura per esprimere le dimensioni complessive di una storia utente, una funzionalità o un altro elemento di lavoro". " I punti della storia indicano le dimensioni della storia agli altri, in termini di dimensioni o di complessità. Mike spesso si riferisce ai "punti cane" per aiutare i team a comprendere il concetto di ridimensionamento relativo. Un cane di 2 punti (piccolo) sarebbe un Chihuahua. Un cane di 13 punti (grande) sarebbe un Danese. Con queste due indicazioni di base, diventa abbastanza semplice classificare le altre razze rispetto a un Chihuahua o un Mastino tedesco. Un Beagle che è due volte più grande di un Chihuahua, potrebbe essere un 5. Un Labrador, che è più grande di un Beagle ma più grande di un Danese potrebbe essere un 8.

La prima volta che si utilizzano i punti della storia, il team dovrà stabilire dei punti di raffronto fissi. A tale scopo, scegliere una storia dal backlog del prodotto breve (in termini di dimensioni o complessità) e una storia grande. Preferisco che la mia piccola storia sia composta da due punti, perché se fosse necessario ridurla ulteriormente (se dovessi scoprire un chihuahua toy) posso farlo. Se limito la più piccola storia nota a un solo punto e ho l'esigenza di ridurla, avrò un problema. Le altre storie possono essere dimensionate in relazione a queste.

Quando si tratta di scegliere i numeri per rappresentare queste dimensioni, ritengo che la sequenza di Fibonacci sia la soluzione migliore. Fibonacci è la somma dei due numeri precedenti. Quindi 1 e 2, il successivo è 3. 3 e 2, il successivo è 5. 5 e 3, il successivo è 8, e così via. Preferisco Fibonacci rispetto, ad esempio, alle misure delle magliette o alla crescita esponenziale (4/8/16/32/64/128/256 e così via), in quanto gli esseri umani sono più inclini al calcolo decimale. Quando usciamo da questo intervallo, anche se ne rimaniamo all'interno, ad esempio, con XS, S, M, L, XL, tutto diventa confuso. I numeri di Fibonacci sono semplici, facilmente comprensibili e forniscono un'accuratezza sufficiente a raggiungere l'obiettivo (fornendo stime relative). È possibile scegliere un set diverso di numeri, ma è importante mantenere la coerenza.

I punti della storia sono valori relativi, non fissi. Non esiste una correlazione diretta tra le ore e i punti. Ad esempio, non è possibile comunicare con un livello di certezza che una storia di due punti è uguale a 12,2 ore perché le storie nell'intervallo di due punti variano notevolmente nel numero di ore necessario per completarle. Analogamente, non è possibile confrontare i punti della storia di un team con un altro con qualsiasi livello di certezza. I punti della storia sono creati e sono specifici del team che li ha stimati, probabilmente includeranno un grado di complessità comprensibile solo dal team e non sono assoluti.

Planning Poker

Dopo aver scelto la unità di misura e stabilito la scala, è il momento di iniziare la stima. La maggior parte dei team Agile utilizza la tecnica planning poker per stimare la dimensione relativa delle storie. È noto tra i team Agile poiché è una misura obiettiva che include varie tecniche soggettive di stima, incluso il giudizio di esperti e per analogia. La chiave del planning poker è la partecipazione. Ogni membro del team deve partecipare (sì, tutti). I tester funzionali stimeranno le attività di sviluppo e vice versa. I responsabili di progetto funzionali potrebbero inoltre stimare le attività di sviluppo. Con questa operazione si assicura che i numeri oggettivi includono una stima più soggettiva è possibile.

Iniziare con un set di carte di planning poker. Le carte di planning poker possono essere creare con carte di indice, rappresentate come le carte da gioco, o acquistate. Possono essere create anche con Visual Studio. Ogni scheda ha uno dei numeri nell'intervallo scelto dei punti della storia (1, 2, 5, 8, 13, e così via.). A ogni partecipante viene data una "mano" che contiene l'intervallo di punti della storia disponibili.

Carte di planning poker di esempio

Dopo aver distribuito le schede, il gioco inizia.

Lo Scrum Master presenta il primo elemento del backlog del prodotto al team.
Il team discute in merito alla storia.
Il proprietario del prodotto illustra le domande, i presupposti e i concetti sconosciuti, nonché i criteri di accettazione.
Ogni membro del team decide privatamente l'ampiezza della storia in relazione a una storia di riferimento, una serie di storie di riferimento, o a tutte le storie nel backlog prodotto.
Al tre, tutti mostrano contemporaneamente la scheda selezionata.

Se hanno utilizzato tutti la stessa carta, il team può registrare la stima e passare alla storia successiva.

Se è presente un'ampia varianza (ad esempio, i numeri visualizzati vanno da uno a otto), il team dovrà dedicare tempo alla discussione della storia. Per approfondire la discussione, le parti in disaccordo devono spiegare i motivi delle loro stime. La conversazione è utile in questo caso, non il numero, perché è il momento in cui si verifica l'apprendimento e viene rivelata qualsiasi supposizione. Dopo una breve discussione di circa un minuto, il team ripete i passaggi 4 e 5. Tale processo continua finché il team non raggiunge un accordo sulla stima della storia.

Ciò sembra relativamente semplice, ma è importante comprendere alcune regole di base. Innanzitutto, se il team non raggiunge una sorta di accordo, non si dovrebbe procedere. Si supponga, ad esempio, che sia presente una persona nel team che sceglie un otto mentre tutte le altre scelgono cinque. Se il facilitatore delle riunione dice, "Abbastanza vicino. si parte con il cinque e si prosegue", che cosa farà la persona che ha l'otto? Sulla base dell'esperienza, tale utente farà ciò che è stato deciso dal team ma non parteciperà più in modo completo. La pianificazione può procedere più rapidamente in questo modo, ma è stato perso qualcosa di importante. Non solo questa persona perde la comprensione del lavoro, ma il team perde l'input e la prospettiva di un membro. Più, è OK non essere d'accordo. Un insegnamento prezioso deriva dalla discussione sulle opinioni discordanti all'interno del gruppo. Se ci si trova a un punto morto, chiedere al facilitatore di provare la tecnica detta "da uno a cinque". È ottimo che le riunioni procedano senza alienare alcun partecipante.

Poiché planning poker indica le stime in punti, è idealmente adatto per stimare il backlog prodotto. Il backlog sprint, tuttavia, deve essere valutato in ore. Ciò detto, planning poker può essere ed è stato utilizzato correttamente per stimare i backlog dello sprint; i numeri sulle carte, tuttavia, sono diventati ore, anziché punti. Dunque, una regola semplice –

Le stime di backlog del prodotto sono in punti.
Le stime del backlog sprint sono espresse in ore.

È possibile utilizzare la tecnica del planning poker all'inizio del progetto e durante il ciclo di vita man mano che vengono alla luce nuove informazioni, cambiano le priorità e aumenta la chiarezza.

Wall Estimation

Planning poker è uno strumento fantastico per stimare le storie utente, ma richiederebbe una quantità di tempo smisurata per stimare centinaia di storie, una alla volta, tramite planning poker. Se si dispone di un backlog non elaborato contenente centinaia di storie che non sono state stimate o classificate in ordine di priorità, sarà necessario un modo più rapido per eseguire la stima.

La tecnica della wall estimation è studiata per consentire ai team di evitare discussioni del 2 su 3 e del 5 su 8 e di raggruppare invece, almeno all'inizio, le idee in un modo puramente relativo lungo un continuum. Consente inoltre alle parti interessate di assegnare una priorità generale a un ampio gruppo di storie senza bloccarsi sul fatto che una storia sia leggermente più importante di un'altra.

Per effettuare una wall estimation, è necessario innanzitutto stampare le storie utente su delle schede. Quindi riunire il team e le parti interessate nella stanza con una grande parete vuota (circa 14 piedi di lunghezza per 8-10 piedi di larghezza). È necessario comprendere due aspetti relativi alla parete:

L'altezza determina la priorità. Le storie nella parte superiore sono di alto livello, quelle storie nella parte inferiore sono di livello più basso. La priorità di una storia può essere basata sul ROI, sul valore aziendale, o su qualcosa di semplice come "è solo importante e non so perché".
La larghezza indica la dimensione. Le storie a sinistra sono più piccole, le storie a destra sono più grandi. (È possibile annullare questa operazione e spostarsi da destra a sinistra se, ad esempio, ci si trova in Giappone ed è più logico). È importante visualizzare una riga in direzione orizzontale e una in direzione verticale. I membri del team e le parti interessate devono chiedersi dove, rispetto alle altre storie, questa si inserisce?

Il team utilizzerà la parete per individuare le dimensioni di tutte le storie. Le parti interessate utilizzeranno la parete per classificare le storie in ordine di priorità. Così come per il planning poker, si utilizza il ridimensionamento relativo, ma anziché utilizzare due storie di riferimento per il confronto, il muro diventa la costante. Piccola storia? Spostare a sinistra. Grande storia? Spostare a destra. Storia importante? Collocarlo in posizione elevata. Una storia senza la quale non si può vivere? Collocarlo in posizione bassa.

Sebbene le parti interessate non devono essere presenti durante la valutazione delle storie, il team non deve trovarsi nella stanza mentre le storie vengono classificare in ordine di priorità. Lo Scrum Master e il proprietario del prodotto devono presenziare alle attività di valutazione e di assegnazione delle priorità.

Ora, se si dispone già di un backlog stimato, è possibile fare semplicemente la sezione di priorità di questo esercizio. Se i proprietari del prodotto e le parti interessate dispongono già di un backlog classificato in ordine di priorità, è possibile eseguire solo la sezione della stima di questo esercizio. (Il proprietario del prodotto probabilmente desidererà visitare nuovamente la priorità dopo aver completato le stime. Dopo tutto, il costo ha un notevole impatto sulla priorità.) Vediamo in dettaglio come funzionerebbe, a partire dal ruolo del team.

Stima

Assegnare al team il backlog prodotto non elaborato e iniziare con la stima. Indicare al team all'estrema sinistra della parete dovranno essere presenti le storie più piccole possibili e all'estrema destra le storie più grandi possibili, indipendentemente dai numeri. Il team colloca le storie in un punto della parete in base a questi due estremi. Il vantaggio di procedere in questo modo è che non esiste alcuna nozione preesistente di una storia con sue o tre punti; è veramente relativa in base alle dimensioni della parete, ragion per cui una parete veramente è molto pratica.

Se il team ha difficoltà a eseguire questa operazione, è possibile fornire una maggiore struttura alla parete immettendo storie di riferimento aggiuntive comprese nell'intervallo tra 1 e 8 punti. Non preoccuparsi di creare una storia di riferimento più grande; tutto ciò che sarà più ampio verrà suddiviso mano a mano che la priorità aumenta. Dopo che il team ha identificato le cinque storie, posizionarle sul muro in una posizione che correla le loro dimensioni (spostandosi da sinistra a destra). Lasciare spazio sul lato destro della parete per le storie più grandi di otto punti. Inserire queste storie su una parete e occorrerà indicare al team dio posizionare le storie rimanenti su una parete relative a queste storie di riferimento, tenendo presente che le storie minori vanno a sinistra e le storie più grandi a destra.

Una volta che tutte le storie sono appese alla parete, il team deve identificare le interruzioni logiche tra le dimensioni delle storie. Inserire una linea verticale con un nastro tra gruppi di storie per illustrare queste interruzioni. Presto si avrà una parete simile a quella raffigurata di seguito. Tutto ciò che è incluso nel primo gruppo potrebbe essere un 2, nel secondo un 3; nel terzo gruppo un 5; e un 8 nell'ultimo gruppo. I numeri non importano tanto quanto il fatto che tutte le storie sono ora valutate in relazione tra loro.

Stima parete di esempio - Ordinamento relativo

Dopo aver stimato le storie, sarà necessario coinvolgere le parti interessate in cui è possibile assegnare storie una priorità.

Priorità

Sebbene i clienti e le parti interessate desiderano sapere le dimensioni della storia per aiutarli a determinare la priorità, saranno molto più attenti a cercare le storie ad esse correlate e ad assicurarsi che tali storie vengono eseguite. Prevedere che le parti interessate non siano d'accordo sulla priorità (il proprietario del prodotto utilizzerà queste informazioni per riuscire a decidere la priorità finale).

Illustrare la parete alle parti interessate. Si supponga che le carte su una parete riflettono tutte le funzionalità che desiderano visualizzare nel prodotto finito. Spiegare che il team ha già stimato ogni storia e che può determinare la stima del punto per una storia basata sulla colonna che si trova sul muro. Ricordare a tutti che i membri del team non sono attivi partecipanti nell'assegnazione di priorità. Sono presenti per osservare, prendere nota dei comportamenti, delle interazioni e dei motivi per cui determinate storie aumentano o diminuiscono di priorità. Possono inoltre rispondere a tutte le domande delle parti interessate, se necessario. Se il team non è in grado di definire le dimensioni di una o più storie in modo sicuro perché sono necessarie le risposte di una particolare parte interessata, il team può anche porre domande su tali storie, se il tempo lo consente.

Richiedere alle parti interessate di determinare la priorità relativa di tutte le storie spostandole verso l'alto o verso il basso nelle colonne utilizzate. Ricordare che più in alto si trova una storia sulla parete, maggiore è la priorità business. Impostare le regole seguenti:

Se si inserisce una storia al livello superiore, prepararsi a giustificarne la posizione.
È possibile chiederti perché una storia è più importante di un altro. Chiedetevi: "Chi lo ha spostato in basso (o in alto)?" oppure dite ad alta voce: "Penso che andrebbe spostato. Chi non è d'accordo?". In questo modo viene stimolata la conversazione tra le parti interessate, senza rendere le cose troppo semplici.
Se si sposta una storia a un livello inferiore sulla parete creata da un altro utente, contrassegnarla con un punto colorato per avvisare gli altri.

Il massimo vantaggio per classificare in ordine di priorità come gruppo è che tutte le parti interessate possono comprendere meglio le priorità delle storie. Se una discussione continua troppo a lungo senza risoluzione, il proprietario del prodotto dovrà raccogliere la carta, identificare le due parti interessate che non possono essere d'accordo e prendere nota di organizzare un incontro privato successivamente.

L'esercizio potrebbe richiedere da 2 a 6 ore, a seconda del numero di storie e del numero di parti interessate. Al termine, la parete avrà un aspetto analogo al seguente.

Stima parete di esempio - Ordinamento prioritario

La parete ripartirà approssimativamente in quattro quadranti. Le storie nella parte superiore sinistra sono brevi e hanno una priorità elevata, quindi finiranno nella parte superiore del backlog del prodotto. Le storie nella parte destra superiore hanno una priorità elevata ma sono anche lunghe. Queste storie devono essere suddivise quanto prima in modo da essere trasformate in sprint successivi.

Stima parete - Quattro quadranti

Il quadrante inferiore sinistro è composto da piccole storie con priorità più bassa. Probabilmente finiranno in fondo al backlog. Il quadrante inferiore destro è composto da storie complesse anch'esse con priorità più bassa. Queste storie rappresentano i poemi epici o i temi. Devono essere suddivise in storie più piccole e più gestibili ma non finché non aumentano di priorità.

Dedicare tempo all'osservazione della parete complessivamente insieme al gruppo. Se una storia si trova nel quadrante errato, spostarla. Se una storia ad alta priorità deve essere suddivisa e il tempo lo consente, procedere mentre sono tutti presenti nella stanza.

Alla fine della stima di muro, sarà necessario iniziare un piano di rilascio. Se si conosce la velocità storica del team, è anche possibile fornire un intervallo approssimativo delle storie che verranno completate nel quadrante in alto a sinistra.

La stima è difficile poiché c'è molta incertezza all'inizio di un progetto. I proprietari del prodotto e i responsabili di progetto Agile tentano di ottimizzare il valore precedente che apprendere con interventi con i proprietari e parti interessate del prodotto, producendo feedback di integrazione e del software funzionante sul software per accedere a uno stato rilasciabile. Anche quando i progetti agile devono fornire una stima di quando un set di funzionalità sarà pronta per il rilascio.

Le due tecniche di valutazione consigliate sono il planning poker (adatto a set di storie più piccoli) o la wall estimation (ottima per gestire backlog del prodotto non elaborati di grandi dimensioni). Entrambe forniscono i dati necessari per avviare la definizione di un piano, ovvero l'obiettivo finale della valutazione.