Che lo si evidenzi in modo più o meno esplicito è solo un dettaglio, il tempo è un fattore determinate di tutte le attività umane ed è quello predominante anche nell’ambito dello sviluppo di soluzioni software, soprattutto quelle legate a stringenti dinamiche di mercato.
Sappiamo bene che negli approcci “classici” come il waterfall la presunzione è quella di poter determinare in anticipo la durata delle varie fasi del processo di deployment, illudendosi che un Big Design Up Front (BDUF) estremamente dettagliato possa portare ad una stima accurata. Ricordiamolo: la stima deve essere attendibile, ma è impossibile che sia accurata, altrimenti si rischia di avere deadline estremamente discutibili.
In ambito Agile, il tempo è spesso suddiviso in intervalli limitati (time-boxed): decido di suddividere la mia attività di sviluppo in un numero stimato di iterazioni e, ad ognuna di esse, assegno una finestra temporale ben definita (tipo 2 settimane) all’interno della quale mi impegno a terminare gli elementi che compongono l’Iteration Backlog.
Questo approccio è largamente diffuso ed utilizzato e porta indubbi vantaggi, ma anche una situazione di “freeze” che durante l’iterazione non consente di rispondere sempre adeguatamente alle richieste di modifica del cliente, ragionando comunque a breve termine in funzione dell’Iteration Goal.
Nel mondo Lean (Kanban) il focus si sposta sul concetto di Value Stream, ossia un flusso costante e limitato di lavoro finalizzato a massimizzare il valore per il cliente. Non si parla di delivery o deployment dopo xGG o xSettimane, bensì lo si effettua nel momento in cui quello realizzato ha raggiunto uno o più goal concordati con il cliente o con gli stakeholder in generale.
Ma come facciamo in questo caso ad avere un’idea dell’efficienza del team e ad effettuare delle stime accurate in relazione a nuovi progetti richieste? Ebbene, come in Agile esiste la Velocity che è in grado di dirci quante User Story riusciamo a completare in una iterazione, tipicamente in Lean si ricorre ad una serie di “misure temporali”: Lead Time e Cycle Time in primis.
Il Lead Time è fondamentale soprattutto in ottica di management in quanto misura il tempo impiegato dalla richiesta del cliente alla sua evasione. Si immagini che venga richiesta l’aggiunta di una nuova pagina web alla nostra applicazione: ebbene il contatore del Lead Time scatta al momento della richiesta e si conclude quando il cliente può effettivamente utilizzarla, ovvero quando ne viene fatto il deployment.
Lead Time
Bisogna evidenziare un elemento di discussione: un po’ come avviene per la questione “Done-Done” vs “Done-Done-Done” in Agile, non tutti concordano che il Lead Time termini con il Deployment, affermando che invece termina con il Delivery, ovvero quando ciò che è stato realizzato è pronto per la fase di QA e Test di Accettazione. Da un punto di vista della Product Board, però, il Delivery è solo una fase di passaggio, mentre quello che conta realmente è il Time-to-Market, che rientra nella nostra ipotesi primaria.
La seconda misura temporale che abbiamo citato è il Cycle Time, che, invece, è il tempo che il development team impiega per realizzare la funzionalità specifica: il cronometro scatta quindi quando il task viene posto “In progress” e termina quando viene posto in “Done”.
Cycle Time
Possiamo leggere queste due misure da una prospettiva estremamente chiara e significativa:
- Il Lead Time medio è il tempo medio che il deployment team impiega per mettere in esercizio una funzionalità. Letta in modo diverso, è il tempo del Time-to-Market;
- Il Cycle Time medio è il tempo medio che il development team impiega per sviluppare una funzionalità.
In questo modo è possibile avere un quadro di quella che è la capacità del team di progetto e del team di sviluppo di rispondere alle esigenze dei clienti.
Esiste anche una terza misura, particolarmente interessante, che calcola il tempo di “reazione”, ovvero il tempo medio di permanenza nel Product Backlog di una richiesta prima di essere schedulata per la lavorazione. Tale tempo è il Reaction Time.
Reaction Time
Se ragioniamo in termini di DevOps (più Ops), il Lead Time è anche chiamato Resolution Time e insieme al Reaction Time sono due SLA che misurano la risposta in ambito maintance. E’ facilmente intuibile che lo scopo è sempre quello di ridurre quanto più possibile il valore che tali metriche assumono durante le attività di sviluppo, in modo da minimizzare l’effort generale e migliorare il Time-to-Market.
In VSO/TFS non esiste la misura diretta del Lead Time e del Cycle Time, ma è possibile utilizzare il Cumulative Flow Diagram per avere un’idea dell’andamento medio di essi e capire se il team è in fase di miglioramento o viceversa. In esso il Lead Time però fa riferimento al Delivery e non al Deployment della soluzione.
