Scrum: tempi e costi

Adottando la metodologia di sviluppo SCRUM gli obiettivi di progetto vengono raccolti nel Product Backlog, continuamente aggiornato e alimentato da tutti gli stakeholder. L’obiettivo generale del progetto è definito ma i dettagli possono cambiare al mutare delle condizioni di mercato e delle strategie del cliente per ottenere il massimo del valore.
Si pongono quindi due problemi:

  • come definire e rispettare una data di rilascio condivisa con il cliente?
  • come definire una strategia di controllo dei costi a fronte della variabilità delle specifiche?

Un primo passo è quello di definire un piano iniziale con una data di rilascio condivisa. Questo piano verrà aggiornato con il susseguirsi degli Sprint, ma permette di definire una scadenza sulla base dei requisiti iniziali. Questi vengono raccolti e, se necessario, discussi con il cliente al fine di comprendere al meglio i benefici di business correlati alle richieste ricevute.

I requisiti (User Story) vengono inseriti, ordinati per priorità, nel Product Backlog e sottoposti ad un processo di stima. La stima non viene effettuata sulla base di una valutazione del tempo e delle modalità di implementazione, ma per confronti successivi rispetto ad un requisito di riferimento. In questa fase, infatti, non è stata ancora effettuata un’analisi.
Tra le User story nel Product Backlog ne viene selezionata una minore, ma non la più piccola, e viene attribuito un valore Story Point di tre. Questo valore è un numero puro, senza nessun riferimento al numero di ore di lavoro necessarie. Fissato questo punto di riferimento, il team attribuisce il valore degli Story Point alle altre attività. In questo modo un’attività con una complessità doppia rispetto a quella di riferimento avrà un valore pari a 6 o una, davvero molto complessa, un valore pari a 100.
La valutazione del numero di Story Point non sempre è immediata e pertanto esistono varie metodologie per agevolare la stima. Una tra queste è il cosiddetto Planning Poker.

Completata la stima degli Story Points è necessario valutare la “capacità produttiva” del team di sviluppo. E’ necessario misurare la cosiddetta Velocity, ovvero il numero di Story point che il team può completare in un singolo Sprint. E’ chiaro che, conoscendo questo valore, è possibile conoscere il tempo necessario per realizzare tutte le User Story nel Product Backlog: Tempo di completamento = Totale Story Point/Velocity * Durata Sprint. Non si tratta di una stima ma di una misura.
Studi dimostrano che per avere una misura del valore di Velocity di un team è tipicamente necessaria l’esecuzione di tre Sprint. Il valore di Velocity è costante se vengono mantenute invariate le tecnologie, l’ambiente di lavoro e la composizione del team. E’ quindi possibile che si disponga già di questo valore. In caso contrario, per un progetto di sufficienti dimensioni, potrebbe essere addirittura conveniente realizzare tre Sprint da una settimana per avere una misura di questo valore.

A questo punto abbiamo una indicazione del tempo di realizzazione, condivisibile con il cliente. Ma i cambiamenti in corsa avranno un impatto sul tempo di completamento del progetto? Le variazioni ai requisiti iniziali come incideranno sui costi? A queste domande risponde il contratto sottoscritto con il cliente. Esistono, infatti delle tipologie di contratto che permettono una gestione chiara dei costi, anche in contesti caratterizzati da variabilità come quelli in cui vengono applicate metodologie agili di sviluppo. A titolo di esempio ne citerò alcuni:

Per tempo e materiali
E’ un classico. Il cliente paga per il tempo di sviluppo richiesto e, di conseguenza si assume anche il rischio di eventuali scelte errate che aumentano la durata del lavoro. L’ambito del progetto non è definito a priori e il progetto viene chiuso appena il cliente raggiunge i suoi obiettivi o decide di non voler spendere di più.

Per tempo e materiali con tetto di spesa
E’ simile al precedente, ma un tetto di spesa limita il rischio finanziario per il cliente. Ovviamente, essendoci un limite di budget, è fondamentale che ci sia una collaborazione tra fornitore e cliente affinché quest’ultimo ottenga il massimo del valore per il suo business rispettando il limite di budget.

Profitto fisso
Permette di condividere il rischio: se il progetto viene chiuso in anticipo il cliente paga di meno ed il fornitore ottiene il profitto per quel periodo, se il progetto supera la data di consegna prevista o se viene superato il budget massimo concordato, il fornitore lavora a prezzo di costo.

“Money for Nothing, Changes for Free”
Il modello di base è per tempo e materiali, con una data di rilascio prevista. Durante il processo di sviluppo, vengono realizzate le funzionalità in ordine di valore per il cliente. Ad un certo punto quest’ultimo può valutare sufficiente il valore ottenuto e decidere di non proseguire con lo sviluppo. In questo caso il cliente deve versare una fee di cancellazione pari al profitto mancante per il fornitore (money for nothing). Le funzionalità non implementate possono essere sostituite con altre con un numero di story point uguale (changes for free). Le funzionalità aggiuntive comportano costi aggiuntivi.

Questa voce è stata pubblicata in Project management e contrassegnata con , , , , , . Contrassegna il permalink.

2 risposte a Scrum: tempi e costi

  1. Laura García ha detto:

    Do you have this article in english?
    Thanks in advance.

    Mi piace

  2. Vittorio Polizzi ha detto:

    Hi Laura, I am evaluating the opportunity of translating this post. It only depends on how many people asks for it.
    If you subscribe to the blog you’ll be notified when the English version will be available.

    Mi piace

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...