Alla ricerca del valore tra i pomodori nell’orto
All’interno della comunità IT, impieghiamo moltissimo tempo nel discutere circa la valutazione del “Ritorno sugli investimenti”, dimenticando spesso che, in realtà, stiamo parlando di un’intera gerarchia di attività:
– Strategia dell’impresa – Selezione dei mercati cui partecipare e formulazione delle strategie adatte per risultare competitivi;
– Valutazione – Analisi del valore economico dei progetti derivanti dall’attuazione di questa strategia;
– Analisi costi-benefici – Espressione, in termini monetari, dei dati misurati o stimati (per esempio, i costi del lavoro), per fornire le basi per la valutazione economica;
– Metriche -Misurazione dei parametri (come, per esempio, il tempo impiegato da un programmatore) che costituiscono la base per l’analisi dei costi e dei benefici.
– Valutazione – Analisi del valore economico dei progetti derivanti dall’attuazione di questa strategia;
– Analisi costi-benefici – Espressione, in termini monetari, dei dati misurati o stimati (per esempio, i costi del lavoro), per fornire le basi per la valutazione economica;
– Metriche -Misurazione dei parametri (come, per esempio, il tempo impiegato da un programmatore) che costituiscono la base per l’analisi dei costi e dei benefici.
Esaminando la letteratura sull’argomento, appare evidente che la comunità dei realizzatori di software ha effettuato sempre una quantità di lavoro enorme nelle ultime due aree indicate, ma ha praticamente ignorato le prime due. Perché?
Perché siamo specialisti del software e ci troviamo a nostro agio nel raccogliere e interpretare numeri, per loro natura “simili a una codifica”, mentre pochi fra di noi hanno familiarità con gli indici più elementari della valutazione economica, come il valore attuale e il costo del capitale.
Ancora di meno sono quelli che hanno la percezione delle relazioni con altri termini che utilizziamo in maniera informale, come il Ritorno sugli investimenti e il Tempo di ammortamento. Ma la valutazione costituisce la base per il vero ragionamento disciplinato, necessario per ogni seria stima di valore economico.
Un esempio: all’interno della comunità IT, siamo interessati non solo al valore economico dei nostri prodotti, ma anche al valore dei nostri processi di sviluppo del software. Considerate la nuova generazione di metodologie che adesso vengono definite “agili”; il più conosciuto tra questi ultimi è denominato Extreme Programming.
È stato sempre un compito difficile attribuire un valore economico ai processi di sviluppo, in parte perché la maggior parte degli scenari interessanti comprendono astrazioni come qualità, portabilità o estensibilità.
Gli scenari che comprendono metodi agili sembrano essere quelli più problematici, perché alla fine la maggior parte tra questi comprendono l’obiettivo della flessibilità. E che cosa, più della flessibilità, può risultare più astratto e più elusivo da valutare?
In effetti, sono trascorsi esattamente trent’anni da quando è stato fatto un tentativo che ha fornito una qualche speranza reale di progresso nella valutazione economica della flessibilità. Si tratta della pubblicazione, nel 1973, della formula per attribuire un prezzo alle opzioni finanziarie da parte degli economisti Black, Merton e Scholes (un risultato che valse loro il premio Nobel nel 1977). Ancora nel 1977, Stephan Myers, un altro grande economista, intuì che la teoria del prezzo delle opzioni nel mondo finanziario poteva applicarsi a progetti nel mondo reale.
Poiché le opzioni implicano alternative e queste, a loro volta, implicano flessibilità, le “opzioni reali” divennero presto oggetto di studio per la valutazione economica di progetti che comprendevano flessibilità. A partire dagli anni ’90 fu chiaro che la natura malleabile del software lo rendeva un candidato ideale per questo approccio.
Lo stile iterativo di sviluppo mediante approcci agili rende possibile il cambiamento delle priorità, l1introduzione di nuove funzionalità, la gestione dei ritardi e così via. Si può affermare che un team di sviluppo agile crea e gestisce continuamente “opzioni”, adattandosi in ogni momento al cambiamento delle condizioni esterne. Questa prospettiva verso processi agili “options-driven” è stata introdotta contemporaneamente alla pubblicazione del primo libro sull’Extreme Programming.
Questo spiega la nascita della metafora dei pomodori nell’orto, sviluppata originariamente del professore di Scienza delle Finanze Timothy Luehrman per illustrare l’idea della gestione attiva di un portafoglio di opzioni strategiche.
La metafora dei pomodori nell’orto risulta anche sorprendentemente efficace per illustrare un processo di sviluppo del software, flessibile e iterativo, oltre che in condizioni di incertezza. Luehrman introduce la metafora in questo modo: -Camminate all’interno dell’orto in un giorno qualsiasi del mese di agosto e vi accorgerete che alcuni pomodori sono maturi e perfetti. Qualunque giardiniere saprebbe riconoscerli e potrebbe raccoglierli per mangiarli immediatamente.
Altri pomodori, invece, sono marciti e nessuno si piglierebbe la briga di raccoglierli. Questi due casi estremi (adesso o mai più) rappresentano decisioni facili da prendere per il giardiniere. Nell’intero arco delle possibilità esistono però pomodori che si presentano con aspetto molto diverso l’uno dall’altro?.
Questa situazione è analoga a quella dei processi di sviluppo iterativo, che implementano il software in termini di pacchetti con funzionalità ben delimitate, come gli “use cases”, o casi d’uso, del Rational Unified Process, oppure le “stories” dell’Extreme Programming. In un giorno qualsiasi di un progetto agile, troverete storie con aspetto e prospettive diverse. Alcuni componenti sono pronti per essere implementati, mentre per altri questo appare impossibile tecnicamente, oppure è giudicato troppo costoso.
Continuando con la metafora: “Alcuni pomodori sono commestibili ma, anche se si possono cogliere immediatamente, miglioreranno lasciandoli ancora sulla pianta”.
Continuando con la metafora: “Alcuni pomodori sono commestibili ma, anche se si possono cogliere immediatamente, miglioreranno lasciandoli ancora sulla pianta”.
Questo fa riferimento a quanto è conosciuto nella terminologia delle opzioni reali come opzioni da differire, che hanno un valore economico dimostrabile in molti tipi di situazioni, dalle esplorazioni petrolifere all’edilizia. Anche i processi agili creano questo valore economico mediante il differimento dell’implementazione di componenti nel corso di iterazioni successive (per esempio, allo scopo di verificare le esigenze reali prima di prendere una decisione finale).
Proseguendo ancora con la metafora: “Un giardiniere puramente passivo” raccoglie i pomodori maturi e torna a casa. I giardinieri attivi [ma non solo] osservano l’orto e, in base a quello che vedono, si impegnano nel coltivarlo: annaffiano, concimano, estirpano le erbacce e così via?. In molti ambienti tradizionali di sviluppo del software, ciò che è finito è finito – si ritorna su quanto è stato fatto solamente in caso di assoluta necessità (motivata parzialmente dalla paura di un “blocco” del sistema).
In ambiente agile, al contrario, il sistema viene coltivato con continuità: la codifica completata viene rivista, i test “rompono” il sistema in maniera routinaria e l’integrazione è continua. Il sistema non è mai in riposo, per cui, come risultato, viene massimizzato il numero delle opzioni disponibili in ogni momento.
Luehrman: “Naturalmente, esiste sempre l’incognita meteorologica e non tutti i pomodori arriveranno alla maturazione. Tuttavia, possiamo aspettarci che il giardiere attivo produca raccolti migliori nella maggior parte degli anni, a differenza di quello passivo”. Tutti abbiamo imparato dalle nostre amare esperienze che, malgrado tutti gli sforzi, alcune condizioni esterne possono pregiudicare il successo dei nostri progetti ? che sia un cambiamento radicale nelle necessità, oppure una decisione del top management, o ancora un improvviso taglio dei fondi.
Ma la disciplina delle opzioni reali, unitamente ad altri concetti della finanza, sta iniziando a fornire un supporto concreto per l’argomentazione intuitiva che una gestione attiva e agile di un progetto ne incrementerà il valore economico, che sia la raccolta dei pomodori per l?estate o il sistema dei servizi web da attivare durante l’inverno.
Sarà la disciplina emergente delle opzioni reali a fornire definitivamente la bacchetta magica per comprendere il valore economico delle best practices del nostro gruppo di sviluppo software?
Certamente no – è chiaro che non esistono bacchette magiche, ma solamente duro lavoro e ragionamenti disciplinati. Ma più impariamo circa i principi fondamentali della finanza e la loro moderna evoluzione e più diventerà disciplinato il nostro modo di pensare e, quindi, il nostro duro lavoro risulterà ancora più proficuo.