Uno dei principi più importanti di XP, nonché uno dei valori fondanti, è: scegli la via più semplice.

Ad esempio, se ci si trova a dover scegliere tra due soluzioni, una che prevede un’infrastruttura più ampia, utile anche in futuro, ed una invece con un’infrastruttura ad uso esclusivo della business story attuale, XP guida nella scelta con l’euristica:

“scegli la soluzione più semplice, che non fa assunzioni sulle necessità future e che presuppone lo sviluppo solo dell’infrastruttura necessaria adesso, così da minimizzare il time-to-market e da non precludere alcuna strada futura”.

E’ l’essenza dello sviluppo iterativo.

La domanda ora è: scegliere in base a questa euristica, ottimizza il ritorno di investimento finale?

Nel corso di questo post per mezzo di un’analisi finanziaria comprenderemo in quali situazioni l’euristica XP è vincente rispetto ad una scelta con architettura up-front.

Supponiamo di dover costruire un online document management system, nel quali gli utenti possono accedere e scaricare articoli di riviste. Possono anche iscriversi ai giornali on-line, e richiedere notifiche alla pubblicazione di particolari articoli.

Scomponiamo le funzionalità in tre gruppi (detti Minimum Marketable Features):

• Iscriversi al sistema (A)
• Ricevere la rivista in formato elettronico (B)
• Ricevere la notifica di articoli appartenenti a certe categorie (C)

Supponiamo che per motivi di business, esista una relazione di dipendenza tra queste funzionalità tale per cui non è possibile rilasciare B o C, se prima non è stata rilasciata A.

Da un punto di vista più tecnico invece, la macro-funzionalità B può essere gestita in modo molto semplice con una singola classe di sottoscrizioni, che si interfaccia con una tabella di iscritti.

C, al contrario, ha bisogno di maggiore infrastruttura, quale ad esempio un meccanismo di publish-subscribe per permettere una gestione indipendente di chi si iscrive a cosa.

A questo punto è chiaro che se si sviluppa prima B di C, si implementa una semplice infrastruttura che sarebbe da rifattorizzare se e quando si implementerebbe C. Questo vorrebbe dire un time-to-market minimo, e quindi feedback subito, e potenzialmente anche ricavi “subito”. Sviluppando prima C, ci si ritroverebbe invece con la parte di infrastruttura già pronta per B.

In un ambiente non agile, si preferirebbe costruire prima tutta l’infrastruttura e poi sviluppare C e B. In un ambiente XP, si svilupperebbe prima B con il minimo di infrastruttura necessaria. In sostanza le opzioni sono 4 (assumendo due release):

1. MMFs A e B e l’elemento architetturale 1 (AE1) per supportare A e B sono sviluppati durante il periodo 1. MMF C non è necessario.
2. MMF A e AE3 (architettura per supportare C up-front) sono sviluppati durante il periodo 1 e MMF B è sviluppato nel periodo 2. Poiché C non è sviluppata, AE 3 rappresenta “un overkill„ architettonico (cioè, sforzo sprecato).
3. MMFs A e B e AE1 è sviluppato nel periodo 1 e MMF C e AE2 nel periodo 2. AE2 rappresenta il refactoring di MMF B che è necessario per sostenere MMF C.
4. MMF A e AE3 sono sviluppati durante il periodo 1 e il MMF B e C nel periodo 2. In questo caso, MMF C è aggiunto senza l’esigenza del refactoring perché AE 3 fornisce i relativi componenti architettonici necessari.

Ma se volessimo analizzare da un punto di vista finanziario le alternative, quale approccio sarebbe migliore in questo caso? Proviamo a scrivere qualche numero, sulla base di quanto imparato nella seconda parte della rubrica “Business words”. Iniziamo con una semplice tabella con costi e ricavi su una finestra di 16 periodi, assumendo che tutti gli MMF e gli AE richiedano un periodo ciascuno per lo sviluppo:

Passiamo quindi ad analizzare i costi delle 4 soluzioni possibili, confrontandole in termini di flusso di cassa e soprattutto in termini di Present Value, assumendo un tasso dello 0,8%. Il campo NET delle tabelle, indica la somma dei Present Value sui 16 periodi (Net Present Value).

Opzione 1:

Opzione 2:

Opzione 3:

Opzione 4:

Ricapitolando in un’unica tabella, possiamo confrontare le quattro opzioni, dividendole in:

• “opzioni per le quali il gruppo di funzionalità C non viene mai sviluppato“
• “opzioni per le quali il gruppo C viene sviluppato nel periodo 2“.

Abbiamo, a seconda della scelta architetturale (semplice o up-front) la seguente tabellina riassuntiva:

Questo significa che la scelta di adottare una soluzione architetturale semplice, non solo paga nel caso in cui C non venga mai sviluppato, ma anche nel caso in cui C verrà sviluppato e quindi bisognerà rifattorizzare B, la scelta non causerà perdite rispetto all’architettura up-front. In questo caso è quindi chiaro che scegliere l’approccio iterativo sull’infrastruttura sia la scelta migliore.

Tipicamente la scelta non è così chiara. Supponiamo infatti di avere un costo di refactoring AE2 più alto (nell’opzione 3), ad esempio pari a 25. La situazione cambierebbe in questo modo:

Confrontiamo ora le due opzioni, calcolando il rischio su entrambe, assumendo che la probabilità di sviluppare C sia del 70%:

1. Rischio NPV di sviluppare la soluzione semplice, quando non avremmo dovuto =
• 70% * (232-217) = 10.500$
2. Rischio NPV di sviluppare la soluzione estesa, quando non avremmo dovuto =
• 30% * (135-125) = 3.000$

Quindi in quest’altro scenario, da un punto di vista esclusivamente finanziario, converrebbe sviluppare l’infrastruttura up-front, visto il minor rischio.

Considerazioni finali.

Abbiamo analizzato su un semplice esempio quali sono i fattori che rendono vincente una scelta Agile su una scelta Up-Front. Questi tipi di analisi finanziarie permettono di prendere decisioni consapevoli nella scelta degli elementi architetturali e delle funzionalità di business da implementare a seconda del contesto. In particolare, oltre al tasso di sconto con il quale calcoliamo le proiezioni del Present Value, riveste un’importanza fondamentale il costo del refactoring. Se tale costo viene tenuto basso, l’euristica agile “non sviluppare più infrastruttura di quanta ne sia necessaria adesso“, si rivela vincente. Se al contrario il costo di refactoring diviene alto, un’analisi finanziaria dei costi e dei benefici ci indica di perseguire la strada up-front.

Questo è un aspetto fondamentale: un approccio iterativo avrà successo solo se l’attenzione al refactoring sarà tenuta molto alta e soprattutto se costante. E’ stato infatti dimostrato che il modo migliore per abbattere i costi dell’attività di refactoring è di praticarlo su base regolare, con cicli brevissimi di codice-refactoring (magari ala TDD). In questo modo si minimizzano i lunghi e quindi costosi periodi durante i quali effettuare grandi attività di refactoring. Si veda ad esempio questo grafico per avere un’idea dell’andamento dei costi in caso di refactoring costante e con refactoring big-bang.

A margine delle analisi finanziarie contestualizzate caso per caso, l’euristica agile ed il metodo che essa presuppone ha una serie di punti di forza che si ripercuotono anche sul business:

• Non necessita di alcuna assunzione sugli sviluppi delle release future: in questo modo minimizza il rischio di previsioni non corrette (finanziarie e di tempo)
• Il feedback derivante dalla messa in produzione della soluzione più semplice sarà utile non solo per la parte di business, ma anche per l’estensione dell’infrastruttura, lasciando che l’architettura più sofisticata emerga in modo iterativo, evitando per costruzione l’overengineering.
• Il refactoring continuo che l’euristica richiede per essere efficace, si porta come side-effect (molto) virtuoso l’abbattimento dei costi di manutenzione (si veda ad esempio questo articolo) e di cambiamento, grazie alla maggiore semplicità del sistema
• “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”