L’Enciclopedia Treccani ci dice che stima è un s. f. [der. di stimare] e significa ‘Valutazione approssimata del valore numerico di una grandezza, e anche il valore numerico medesimo: s. per eccesso o per difetto, a seconda che si tratti di una valutazione per eccesso o per difetto’. Vediamo come il concetto di stima si applichi nelle metodologie agili.

Introduzione

Stimare un progetto software significa provare a fare un’ipotesi sul costo (espresso in termini di tempo, di risorse o genericamente di impegno) necessario per la sua realizzazione: tale ipotesi normalmente è soggetta a una serie di fattori di indeterminazione che ci impediscono di fornire una risposta precisa.

Molte sono le variabili in gioco, alcune delle quali calcolabili o ricavabili, mentre altre sono del tutto ignote e imprevedibili. Nel corso degli anni sono state inventate alcune tecniche per semplificare questo mestiere che è di per se’ molto difficile: dai functional o use case points, agli story points usati in ambito agile; da non sottovalutare, poi, tecniche meno rigorose, ma piuttosto diffuse, come l’utilizzo di fogli di Excel, indipendentemente dal loro contenuto, la lettura dei fondi di caffe’, l’osservazione e interpretazione simbolica del volo degli uccelli al tramonto e così via… queste ultime tra le preferite da molti project manager, abituati a chiedere, con tono minaccioso, “quanto tempo ci vuole per fare questo software?”.

Stime agili?

In questo articolo vedremo come il problema è affrontato nell’ambito di un progetto agile: si vedranno sia le tecniche e le procedure di stima agile, sia il modo in cui si deve comportare un team agile quando qualcosa cambia o non va come ipotizzato all’inizio del progetto. Ogni agilista sa che il cambiamento è benvenuto: il modo migliore per dimostrarlo è nell’ambito della gestione delle stime, che è il contesto più sensibile al cambiamento.

Per motivi di spazio tralasceremo di entrare nel merito del fatto se e quando sia sensato o utile fare la stima di un progetto: a tal proposito è possibile leggere un interessante e per certi versi illuminante articolo di Martin Fowler [1].

Stimare in modo relativo

Una tecnica molto usata, quando si deve svolgere un compito difficile o lungo, è quella di scomporre tale lavoro in sottoparti in modo da affrontare i singoli pezzi isolatamente. Quando abbiamo parlato di complessità [2] abbiamo visto che non sempre questo approccio permette di trovare la soluzione del problema. Parlando di stime, purtroppo la scomposizione è solo una parte del lavoro, che non risolve il problema di fondo: la nostra mente non è fatta per misurare puntualmente qualcosa, anche smontandola in piccole parti.

Sistemi di riferimento

Se per esempio ci trovassimo di fronte a un palazzo, un unico palazzo costruito nel mezzo di una pianura o nel deserto, sarebbe veramente difficile provare a dedurne l’altezza: escludendo valori evidentemente non coerenti (non può essere 5 metri, ma nemmeno 2 kilometri), non resterebbe che fare qualche ipotesi, magari contando il numero di piani e provando a immaginarne l’altezza di ognuno.

Molto più semplice se fosse possibile fare qualche paragone con eventuali costruzioni situate accanto o nei pressi del palazzo o con altri palazzi noti di cui si conoscessero le dimensioni.

Per il cervello umano infatti è difficile misurare “a occhio” mentre è più semplice confrontare: è sicuramente più facile dire che “il palazzo A è più basso del palazzo B di circa la metà ed è una volta e mezzo più alto del palazzo C”.

Nel software ci si imbatte nello stesso tipo di problema: non è facile stimare il tempo necessario per implementare un pezzo di un progetto, ma è certamente più fattibile, quasi facile, capire quale sia il rapporto in termini di impegno che sussiste fra realizzare la parte A e la parte B.

Questo è l’approccio tipico alla stima di un progetto quando si decide di applicare una metodologia agile: stimare in modo comparativo.

Ancora storie utente

In questo caso si parte per prima cosa da una scomposizione di massima del progetto in storie che tramite il raffinamento, o grooming, possano diventare sempre più piccole e gestibili (ossia misurabili per comparazione): quando si arriva a una dimensione compatibile con lo svolgimento all’interno di uno sprint, le storie cominciano a essere piuttosto piccole, tanto da consentire di fornire una valutazione comparativa.

Per poterle confrontare, si deve per prima cosa individuare la cosiddetta storia campione o storia di riferimento: per questa storia si devono avere le informazioni che ci permettano di poter esprimere un grado di complessità (o peso).

Il peso assegnato alla storia campione deve essere considerato il valore di riferimento con il quale calcolare il peso delle altre storie moltiplicando o dividendo; tali valutazioni sono totalmente slegate da considerazioni temporali: per questo motivo si stima in punti, ma potrebbero essere palline gialle, orsetti di gomma o una qualsiasi unità di misura immaginaria (vedremo meglio fra poco il motivo di questa scelta).

Il gruppo procede quindi stimando tutte le altre storie, ipotizzando per ognuna il rapporto che sussiste con quella di riferimento: è più grande? Molto più grande? Il doppio? Il triplo?

Inizialmente questo modo di misurare può apparire molto “bizzarro” e poco professionale se confrontato con i metodi basati sull’uso di coloratissimi fogli di Excel gestiti da persone con la cravatta. Certamente inizialmente è poco preciso, come tutte le tecniche di stima. Ma rispetto a ogni altro sistema di stima, la cosa veramente importante e potente di questo approccio è che si tratta di un metodo adattivo: se inizialmente il cono dell’incertezza è molto ampio e le stime in punti possono non tornare e la velocità stimata non viene rispettata, dopo poche iterazioni le due grandezze (punti assegnati e velocity) si bilanciano portando il sistema in equilibrio.

Figura 1 – Diagramma detto del “cono dell‘incertezza”: partendo da uno stato iniziale in cui la variabilità delle stime passa da -1/4 al quadruplo, man mano che il tempo passa e le informazioni arrivano, si può ridurre questa forbice.

Unità di misura: perche’ i punti?

In questo senso, sebbene sia certamente possibile effettuare la comparazione fra due storie anche usando unità temporali, usare una misura astratta e a-dimensionale come i punti è una condizione estremamente importante. Per esempio è certamente più difficile dare una valutazione oggettiva in giorni-uomo a quella che viene identificata come la storia campione; non è detto che sia semplice indicare il tempo necessario per implementare tale storia. Se per esempio il team assegnasse il peso di 3 giorni-uomo per la realizzazione di tale storia, potrebbero sorgere dubbi o ripensamenti quando si provasse a stimare un’altra storia che si dimostrasse palesemente più grande: “no non posso chiedere al capo 9 giorni per fare questa cosa, è sicuramente più semplice”. Usando i punti questi scrupoli non sorgerebbero.

C’è anche un altro importante motivo per stimare in punti e non in ore: si immagini di prendere in esame una storia A di dimensione media che, tramite il raffronto con la storia campione, si sia pesata 8 punti. Il team inconsciamente associa 8 punti = storia più o meno semplice.

Se durante l’esecuzione dello sprint il team scoprisse che tale storia in realtà era tutt’altro che semplice, non sarebbe necessario rivedere le stime o cambiare il metro di punteggio. Dallo sprint successivo, o meglio dal planning dello sprint successivo, il team ragionando per similitudine, assegna il punteggio 8 per quelle storie di complessità simile alla A cambiando però metro di giudizio: adesso 8 punti equivalgono a storie mediamente difficili. In questo caso la velocity si adatta alla nuova consapevolezza del team, e probabilmnte in questo caso diminuisce, perche’ adesso vi è la consapevolezza che prendere in carico una storia da 8 punti equivale a impegnare una quota parte del tempo complessivo maggiore rispetto a prima. Semplice, automatico, senza la necessità di stravolgere l’impostazione del lavoro.

Una nota: per procedere all’assegnazione del peso di una storia, normalmente si possono usare diverse tecniche. La più usata è quella del planning poker, di cui abbiamo parlato nella III parte di questa stessa serie, attività che si svolge, come ormai dovrebbe essere noto, durante la “cerimonia” dello sprint planning.

Valutazione sulla durata del progetto

Quando si parla di stima delle attività di un progetto, quello che si è visto fino a questo punto, ossia  pesare le storie per capire quante ne potranno essere implementate all’interno dello sprint, è solo una parte del lavoro, parte che tipicamente viene dopo un’altra attività molto importante: stimare la durata o il costo dell’intero progetto.

Per capire cosa significhi stimare un progetto secondo un approccio agile, prenderemo in esame un caso tipico: si parte con il cliente che richiede la realizzazione di un prodotto con un set più o meno prefissato di funzionalità; in partenza quindi un progetto è quasi sempre a scope fisso. Il fornitore analizza cosa deve essere fatto e, se richiesta, propone una data: a questo punto il progetto diventa a scope fisso e data fissa. Il “quanto” scope o data siano fissi o modificabili dipende dagli accordi fra cliente e fornitore. Per complicare le cose normalmente interviene una terza grandezza, il budget.

Nel prosieguo di questo articolo vediamo come queste tre grandezze (tempo, costo, budget) possono interagire fra loro.

Primo step: extended planning poker

Partendo dal presupposto che un progetto si compone di un insieme di cose da fare (insieme che potrebbe essere aumentato o ridotto), possiamo semplificare il ragionamento ipotizzando il progetto a scope fisso, ossia  tutto quello che ci è richiesto deve esser fatto. Vedremo più avanti come gestire le eventuali alternative o variazioni dovute a imprevisti.

La prima cosa da fare è cercare di avere un’idea dell’impegno necessario per la realizzazione di tutte le funzionalità richieste: per questo, invece di effettuare il raffinamento del backlog un po’ per volta a ogni inizio sprint durante il planning, si può organizzare un sessione estesa di planning poker in modo da analizzare tutto il backlog in una sola volta. In questo caso si dovrà prima lavorare per smontare le storie grosse (epiche e features) in storie più piccole e, successivamente, votarle. Se non fosse possibile smontare epiche o feature, perche’ per esempio l’operazione porterebbe via troppo tempo, si può assegnare a tale storie un punteggio grezzo (p.e.: 100 o 200 punti) ragionando per analogia: per esempio, se dopo aver smontato la epica A si sono ottenute 30 storie il cui punteggio cumulativo è di 300 punti, allora assegneremo alla epica B, che abbiamo valutato dimensionalmente comparabile con la A, un punteggio analogo.

In questa fase, maggiore è la grana delle storie, maggiore è l’aleatorietà del risultato finale. Dopo aver votato tutte le storie del backlog si sommano tutti i punteggi in modo da avere il peso o punteggio P del Product Backlog.

A questo punto, supponendo di conoscere la velocity V di sprint del team di sviluppo, si potrà calcolare il numero N di sprint necessari per realizzare il progetto, tramite il semplice calcolo:

N = P / V

Essendo poi G il numero di giorni di cui si compone uno sprint, allora si potrà calcolare il tempo (in giorni) necessario per sviluppare il progetto tramite la seguente moltiplicazione:

T = N * G

Il valore ottenuto al termine di questa prima fase di lavoro è molto approssimativo.

Qualora non si conosca la velocity di sprint, (p.e.: il team si è appena costituito o è alla prima esperienza con Scrum), si potrà chiedere al cliente di rimandare la risposta sulla data di consegna. Se ciò non fosse possibile, la cosa migliore che si potrà fare è provare con delle ipotesi per analogia con altri gruppi o altri progetti.

Raffinare e rivedere i calcoli… continuamente

Per come funziona Scrum, appare evidente che durante l’evoluzione del progetto i valori coinvolti in questi calcoli cambieranno continuamente. La velocity cambierà di sprint in sprint assumendo di volta in volta valori sempre più stabili. Anche il punteggio di backlog potrà cambiare: per esempio, sebbene durante la sessione estesa di planning poker sia stata assegnata una stima di massima a tutte le storie del backlog, durante i vari sprint planning si potranno rivedere le stime fatte in precedenza.

Il contenuto stesso del backlog potrebbe cambiare a causa dell’aggiunta o della rimozione di storie.

Secondo step: facciamoci un’idea di cosa dobbiamo aspettarci

Dopo aver calcolato il punteggio totale del product backlog e quindi aver fissato o proposto una data di termine dei lavori, si può provare a visualizzare quello che dovrà essere il trend necessario per terminare il lavoro entro tale data.

Uno strumento molto utile in tal caso è il Burndown Chart, il quale consente di visualizzare l’andamento del progetto; tale diagramma, qualora uno o più parametri non dovesse rientrare nei valori prefissati, fornisce indicazioni sulle implicazioni delle singole azioni intraprese per correggere il trend. Per esempio il burndown permette di calcolare la nuova data di termine, qualora la velocity dovesse diminuire drasticamente; o, viceversa, consente di capire di quanto si deve ridurre lo scope per rientrare nella data prevista.

Come funziona il Burndown Chart

Il diagramma riporta sull’asse orizzontale il numero di iterazioni (ogni step rappresenta uno sprint), mentre in verticale si riporta il totale dei punti che, sprint dopo sprint dovranno essere ancora realizzati.

Per realizzare un Burndown Chart si comincia segnando sull’asse verticale il totale dei punti di partenza (A) e sull’asse orizzontale la data (B) di termine dei lavori, sia essa calcolata, come nel caso precedente o prefissata come in un progetto date-fixed, che avremo modo di vedere fra poco.

Tracciando la retta discendente che unisce A e B si può avere un’idea, iterazione per iterazione, della tendenza dell‘implementazione delle storie affinche’ si possa completare il progetto nel tempo prefissato. Possiamo chiamare tale retta trend a zero.

Figura 2 – Il Burndown Chart.

Al termine di ogni iterazione si disegna una nuova colonna, il cui valore è ottenuto sottraendo dalla colonna precedente la somma delle storie completate con successo nello sprint appena terminato. Dopo alcune interazioni si ottiene quindi un istogramma che rappresenta l’andamento della serie storica dei punti delle storie da completare.

Figura 3 – Dopo qualche iterazione, si forma un istogramma che permette di capire il trend dell‘implementazione delle varie storie e quindi se la data ipotizzata sarà rispettata.

Se la serie storica del totale punti non scende come previsto, il diagramma ci avverte immediatamente, dato che l’istogramma supera la retta del trend a zero.

Se questo rallentamento avviene per una iterazione, ma poi l’istogramma ritorna subito sotto la linea di trend a zero, probabilmente non è il caso di allarmarsi. Se invece il superamento si dovesse manifestare per un periodo più lungo, allora è evidente che non si tratta di un caso isolato, ma anzi è probabile che la velocity del team non sia compatibile con la data di termine che si era ipotizzata.

Figura 4 – Il diagramma del burndown visualizza in modo molto efficace se l‘attuale trend non permette di rientrare nella data inizialmente stimata.

Anche in questo caso il Burndown ci è utile perche’ ci consente di capire immediatamente quale potrebbe essere la nuova consegna: tracciando il nuovo trend a zero, intersecando i punteggi parziali degli ultimi due o tre sprint per avere una media affidabile, si otterrà la nuova data all’intersezione con le ascisse.

Figura 5 – Se la velocità rallenta, si può calcolare la nuova data di consegna semplicemente tracciando un nuovo trend a zero, ottenuto intersecando i punteggi degli ultimi due o tre sprint.

Quando le cose non vanno come dovrebbero: gestire gli imprevisti e le variazioni

I tre parametri fondamentali di un progetto (tempo, costo e portata) non sono del tutto indipendenti, ma sono collegati fra loro e vincolati da accordi fra le parti, contratti, regolamenti, strategie aziendali, delicati equilibri “politici”.

In questo paragrafo vediamo come l’argomento stime si declini in un progetto in cui si decide di fissare uno o più di questi parametri.

Prima di procedere, però, vediamo di fare chiarezza sul significato di alcuni concetti, primo fra tutti quello di tempo di progetto. Per tempo di progetto si può intendere il tempo necessario per fare una cosa (p.e.: in giorni-uomo equivalenti) o la data di consegna del progetto. Nel primo caso il tempo è assimilabile al budget (aumentare le persone sul progetto di fatto aumenta il costo), per cui nel nostro caso considereremo il tempo come la data di consegna. La filosofia agile, inoltre, è piuttosto contraria al concetto di giorni-uomo.

Alcune ragioni per l’imprevisto

Riprendiamo in considerazione il caso in cui la serie storica dei punti non scende verso zero come previsto: per un team agile questo non è mai un problema, anzi normalmente il concetto di “previsto” potrebbe essere inteso come “quell’insieme di condizioni che abbiamo ipotizzato a inizio progetto ma che sappiamo potrebbero cambiare in ogni momento per le ragioni più disparate; e noi sappiamo come gestirle”.

I motivi di questa differenza potrebbero essere i più diversi: un caso tipico per esempio potrebbe essere quello della diminuzione della velocity per l’immissione di nuove persone nello staff o perche’ si scoprono difficoltà tecnologiche non previste. Oppure la causa potrebbe essere esterna al gruppo, per esempio l’arrivo di nuove richieste da parte del cliente.

Figura 6 – Il cliente, nel mezzo del progetto, chiede di aggiungere nuove funzionalità al prodotto finale.

I famosi vincoli

Le strategie di intervento sui parametri dipendono dal tipo di progetto, dai vincoli imposti ossia dai margini di libertà che si hanno a disposizione. Questi vincoli possono riguardare, come è noto, aspetti concernenti i tempi di consegna (date fixed), le cose da fare necessariamente (scope fixed) o i costi da rispettare rigidamente (budget fixed). Vediamo nei paragrafi seguenti le caratteristiche dei vari scenari.

Progetto date fixed, scope fixed e budget fixed

In un caso come questo si lavora nella massima rigidità possibile. Spesso questo viene sbandierato come il contesto più duro fatto per uomini forti e project manager d’acciaio. Più prosaicamente in progetti di questo genere si finisce comunque spesso per “rilassare” uno dei vincoli, se non addirittura tutti, pena il fallimento; in tal caso si rientra in uno di casi riportati più sotto.

Come abbiamo più volte visto, le metodologie agili sono state pensate proprio per gestire la variabilità, visto che il cambiamento capita più frequentemente e più pesantemente di quanto si possa o si voglia ipotizzare o imporre. Il contesto tutto fisso, semmai trovasse applicazione in un caso reale, potrebbe essere gestito anche con metodologie tradizionali stile waterfall: in un contesto di questo tipo, Scrum probabilmente non fornirebbe alcun valore aggiunto direttamente sul progetto, anche se forse darebbe comunque al team un ambiente di lavoro al tempo stesso più rilassato e più efficiente.

Progetto date fixed e scope fixed

In questo caso, il budget viene lasciato libero. Normalmente, nella realtà dei progetti software, ma anche in altri contesti produttivi, le risorse economiche così come le persone, sono allocate sulle attività all’inizio di un progetto: sebbene questo possa far storcere il naso ai puristi dell’Agile, di fatto le aziende devono, in un modo o nell’altro, organizzarsi.

Ritornare quindi un un secondo momento sul piano economico, per interventi o aggiunte successive, non sempre è possibile o visto di buon occhio, dal cliente e/o dal management). In ogni caso, se fosse disponibile budged a sufficienza, si assume di fissare due variabili (data di consegna e funzioni implementate) che in realtà sono le più ardue da prevedere e difficili da bloccare contemporaneamente: prima o poi una delle due salta.

Una soluzione a questo problema, avendo budget a disposizione, potrebbe essere quella di aumentare la dimensione del team di sviluppo: come già visto in precedenza, questa soluzione non porta quasi mai ai risultati sperati. Inserire una nuova persona all’interno del team può dare infatti effetti positivi sul lungo periodo, ma sul breve ci si deve aspettare un degrado delle prestazioni del gruppo.

La conferma teorica si può avere prendendo in esame il noto ciclo di Tuckman il quale descrive le fasi di crescita di un gruppo di lavoro in quattro passaggi di un ciclo vitale: forming (periodo della formazione), storming (periodo del conflitto e del disordine), norming (periodo normativo in cui si trova la coesione), performing (periodo della prestazione efficace). Secondo tale teoria, ogni perturbazione in genere implica un passo indietro nella processo di crescita: nei casi peggiori, si potrebbe osservare un azzeramento di tutti i progressi.

Pertanto, inserire nuove persone nel team può essere una mossa dalle ripercussioni positive solo se si opera quando la data di scadenza è ancora lontana: in questo caso infatti si può investire nel gruppo accettando nel breve periodo un rallentamento, confidando in un aumento delle performance sul lungo periodo. Oppure si può accettare il rischio perche’ si ritiene comunque importante poter far crescere il team.

Il caso del millenium bug è emblematico: allo scadere della data del 31 dicembre 1999 (che per ovvi motivi non poteva essere spostata…) molte applicazioni, specialmente quelle scritte in Cobol, avrebbero potenzialmente cessato di funzionare correttamente o del tutto. Era necessario un piano di intervento che verificasse e, ove necessario, correggesse il problema. Almeno sulla carta, aziende, banche, pubblica amministrazione si attivarono più o meno per tempo; nella pratica in molti si ridussero all’ultimo momento. Il problema potenzialmente poteva essere devastante, bloccando interi sistemi informativi, nonostante fossero stati stanziati budget senza limiti per correggere i problemi, cosa che avrebbe permesso di arruolare “eserciti” di programmatori Cobol.

Purtroppo presto ci si rese conto che non era possibile parallelizzare più di tanto il processo di bonifica dei sistemi informativi: sia perche’ i programmatori Cobol, in piena esplosione del web, erano ormai una merce rara, sia perche’ spesso i controlli non potevano essere fatti in parallelo proprio per la interdipendenza di queste procedure, delle quali spesso si ignorava se fossero ancora in funzione e quale fosse la loro funzione. Nella pratica in molti casi casi fu rilassato il vincolo scope: molti programmi furono semplicemente messi in stato “speriamo che funzioni, lo controlleremo da gennaio”.

Il motivo per il quale non è possibile aumentare la potenza produttiva di gruppo semplicemente aggiungendo persone è legato alla difficoltà intrinseca che deriva da far lavorare insieme le persone. Non è assolutamente detto che, aumentando le persone su un team o creando nuovi team appositamente, l’outcome cresca di pari passo in maniera proporzionale. Di queste cose abbiamo parlato in modo esaustivo durante questa serie dedicata a Scrum. Volendo aggiungere una nota di colore a conferma di questo concetto si può tirare in ballo la nota Legge di Brooks [3] che recita più o meno così: “con nove donne incinte non è possibile avere un bambino in un solo mese”.

Invece di incrementare il numero di persone in un team, una soluzione più semplice è quella di aumentare il numero di ore lavorate per ogni membro del gruppo (si investe del denaro per compare del tempo, ossia  ore di straordinario). Senza entrare in discussioni sull’efficacia e sull’etica di questa soluzione, ricorderemo che le molte statistiche e le migliaia di report su casi reali confermano che aumentare le ore lavorate, in genere, abbassa la qualità del prodotto finito e introduce un certo numero di errori in più.

Progetto scope fixed

Il fine di un progetto di questo tipo è quello di realizzare tutte le funzionalità comprese senza possibilità di deroga. In questo caso si procede alla pianificazione tramite una stima della data di consegna, ma essendo prioritario il cosa deve essere fatto, piuttosto del quando debba essere consegnato, si accetta che tale data sia spostabile.

In questo caso il burndown chart diviene uno strumento molto utile proprio per seguire gli spostamenti della data, senza modificare il numero delle storie da implementare. Il caso è analogo a quello raffigurato in figura 5. Ovviamente spostare in avanti la data di consegna di un progetto implica il dover aumentare il budget allocato per le giornate in più di lavoro. Quindi il caso scope fisso e budget fisso è impossibile da realizzare.

Progetto date fixed

Questo caso può essere visto come l’opposto di quello a scope fisso: la data in questo caso non può essere modificata. Se ci si rende conto che il trend attuale non permette di rispettare tale data, le soluzioni su cui intervenire possono essere tre: aumentare il numero delle persone, far lavorare più velocemente le persone o ridurre il numero di cose da fare.

Per quanto concerne l’aumento delle dimensioni del team abbiamo avuto già modo di vedere come sia una soluzione poco praticabile. Le strade percorribili restano quindi aumentare la velocity e ridurre lo scope.

Aumentare la velocity significa trovare un modo per spingere il gruppo, in genere tramite il classico approccio push: il management, o chi per lui, con la speranza o la convinzione che questo magicamente aumenti la produttività del gruppo, inizia a far pressione sulle persone perche’ inizino a lavorare più velocemente.

Purtroppo, o per fortuna, aumentare la pressione psicologica sul gruppo di lavoro, nella maggior parte dei casi, non sortisce alcun effetto benefico sulla produzione; anzi spesso si ottiene un abbassamento della qualità. Molto spesso invece aumentano lo stress e l’ansia delle persone che, in genere, iniziano a lavorare peggio e con minor efficienza: stress, burn out, demotivazione, abbandono, abbassamento delle prestazioni, bassa qualità dell’outcome sono solo alcuni degli effetti negativi sul lungo periodo.

Figura 7 – Se l‘attuale trend non permette di rientrare nella data inizialmente stimata, una soluzione potrebbe essere quella aumentare la velocity di sprint. Nella maggior parte dei casi, però, questo approccio non funziona o comunque è molto rischioso.

Una strategia per consentire l’aumento della velocity potrebbe essere quello di rilassare un po’ di vincoli, per esempio eliminando alcuni requisiti dalla DoD. Anche se spesso si finge che questo non sia vero, di fatto questa soluzione corrisponde al ridurre lo scope di progetto, che è la tecnica che vedremo più avanti.

Tale opzione, andando a modificare o eliminare alcuni requisiti non funzionali (performance del prodotto, qualità, sicurezza, etc.), dovrebbe sempre essere concordata con tutti gli stakeholder di progetto, in particolare il cliente.

Normalmente la velocity di sprint, espressa in punti implementati per sprint, potrebbe non subire alcuna variazione: rilassare dei requisiti non funzionali infatti riduce la complessità delle storie che quindi finiscono per “pesare” meno. Per ogni sprint, quindi, quello che aumenta quindi è il numero di storie fatte, non il numero di punti realizzati per sprint. Il risultato finale è comunque quello di riuscire a rientrare nella scadenza prefissata.

Come altra strategia per cercare di rientrare nella data, e quindi nel budget stanziato, si può procedere alla riduzione delle cose da fare. Questa strategia è quella che viene messa in atto nella maggior parte dei casi: in Scrum abbiamo il grosso vantaggio di aver iniziato a lavorare dal primo giorno con un ordinamento del backlog in base al valore del prodotto.

Quindi, se al giorno X si dovesse decidere di interrompere il progetto, pur non avendo implementato ancora alcune funzioni, avremmo  comunque la certezza che quello che rimane è meno importante di quello già fatto. Interessante notare come, quando si propone tale soluzione al cliente, egli si trovi in genere d’accordo, probabilmente perche’ constata che ciò che è stato rilasciato fino a quel momento è la parte realmente importante del progetto.

Figura 8 – Ridurre il numero di cose da fare è probabilmente la soluzione migliore: in genere non si hanno ripercussioni sul team ne’ sulla qualità del progetto.

Conclusione

Con questa puntata sulle stime in un progetto agile, termina questa parte del viaggio nella galassia agile. Abbiamo affrontato la maggior parte degli aspetti della teoria di Scrum. In questa lunga serie di articoli abbiamo visto molti aspetti in cui Scrum si può mettere in pratica. Vorrei ricordare, ove questo non fosse stato sufficientemente chiarito, che le possibili soluzioni offerte sono frutto dell’esperienza personale e sono un modo per mettere in pratica i principi agili e le regole di Scrum. Fondamentale è rispettare i principi e le regole di Scrum, ma poi ogni contesto sarà diverso da un altro e quindi niente deve essere preso e applicato rigidamente alla lettera.

Riferimenti

[1] Martin Fowler, “PurposeOfEstimation”

http://martinfowler.com/bliki/PurposeOfEstimation.html

[2] Giovanni Puliti, “Management dal semplice al complesso – III parte: Verso il paradigma Lean/Agile”, MokaByte 187, settembre 2013

https://www.mokabyte.it/cms/article.run?articleId=L8M-KIY-HKB-GVL_7f000001_11231952_1b2a5073

[3] Legge di Brooks

http://en.wikipedia.org/wiki/Brooks’s_law