Nella gestione dello sviluppo del software, per mitigare il rischio derivante dalla scarsa completezza delle specifiche funzionali, ci si potrebbe affidare a una serie di prototipi. Essi andrebbero sottoposti agli utenti, in modo tale da poter ricevere i loro feedback. Operando in questa maniera, anziché navigare a vista, si avrebbe una buona bussola, con cui sarebbe possibile tracciare una rotta ben precisa. Per prototipo intendiamo un’applicazione funzionante ma lungi dall’essere definitiva, in quanto capace di erogare soltanto alcune delle funzionalità richieste, che vanno sottoposte a verifica un po’ alla volta, a mano a mano che si procede con lo sviluppo del software. Spesso, oltre a presentare dei limiti funzionali, i prototipi sono anche tecnologicamente abbastanza semplici, soprattutto se confrontati con le applicazioni finali. In questo modo diventa possibile contenere al massimo i costi e i tempi necessari per la loro realizzazione, al fine di evitare che possano incidere pesantemente sull’at completion total cost di ciascun progetto, oltre che sulla sua durata. Il ricorso ai prototipi permette di controllare che si stia facendo la cosa giusta. Con un investimento spesso abbastanza modesto e noto a priori, infatti, si può evitare di correre il rischio di rilasciare un’applicazione incompleta o del tutto inutile. Sebbene, in alcuni casi, i programmi sviluppati con questo approccio possano essere rilasciati come applicazioni finali, di solito non soddisfano i requisiti di performance, robustezza e sicurezza imposti dalla clientela.
Il problema dell’orizzonte temporale
In ambito IT, l’innovazione tecnologica procede a un ritmo a dir poco vertiginoso. Questo pone dei problemi soprattutto nel caso dei progetti di maggiori dimensioni, nei quali l’at completion duration può essere anche di alcuni anni. In questi casi, infatti, le tecnologie inizialmente scelte potrebbero diventare obsolete ben prima della completion date. Qualora si verificasse questa evenienza, ci si troverebbe di fronte a una scelta tanto dolorosa quanto importante: converrebbe abbandonare lo sviluppo del software a metà, ripartendo da zero e affidandosi alle ultime tecnologie disponibili, oppure sarebbe preferibile proseguire con quelle vecchie, nonostante siano obsolete? Potrebbe anche accadere che una profonda rivisitazione dell’ambito e/o del contesto in cui s’inserisce il progetto ne renda il prodotto finale inutile o del tutto superato, magari perfino prima che si entri nella fase di rilascio. Tutte queste considerazioni valgono non solo per lo sviluppo del software ma anche per tutti i progetti/programmi/portfolio che lo comprendono. I modelli iterativi, che hanno affiancato prima e sostituito poi il waterfall model, si basano sulla scomposizione di ciascun progetto in un certo numero di porzioni, opportunamente interagenti.
Il modello incrementale e quello a spirale
Una possibile soluzione, spesso definita incrementale, prevede la divisione del progetto in una pluralità di sottosistemi. A ciascuna di queste parti si applica il modello a cascata e ciò viene fatto in maniera rigidamente sequenziale: in altre parole, l’output di ogni porzione rappresenta l’input di quella successiva. In genere, in tutti i vari sottosistemi sono presenti queste quattro fasi: analisi dei requisiti; progettazione; codifica; collaudo/test. L’ultima fase assicura il raccordo fra ciascuna parte e quella che la segue. Dopo la fase di collaudo/test, infatti, l’intera sequenza viene ripetuta per la porzione successiva (e così via, fino alla fine). Operando in questo modo, diventa possibile anticipare la consegna di un sottosistema, rappresentante una parte del prodotto finale, che diviene rilasciabile in un tempo ridotto. Ciò permette di anticipare i feedback degli utenti, necessari per migliorare il project control; ricorrere agli interventi correttivi giudicati indispensabili, prima che i costi del cambiamento diventino insostenibili; utilizzare subito alcune funzionalità, relative alla porzione di software già rilasciata. Questo modello non consente di liberarsi del tutto dalle principali limitazioni del waterfall model. Infatti, la scomposizione di ciascun progetto richiede sempre un’attenta analisi preliminare, atta all’individuazione dei vari sottoprogetti. Poiché questi devono incastrarsi come i pezzi di un puzzle, la struttura che si ottiene continua a essere assai rigida e statica, dunque poco incline al cambiamento: sebbene sia possibile, esso continua a essere percepito come un’anomalia, che si oppone al corso naturale dei progetti. Rispetto al modello incrementale, quello a spirale assicura una flessibilità ben più elevata. Esso prevede che lo sviluppo del software sia diviso in un certo numero di cicli/giri, ciascuno dei quali è caratterizzato dalla ripetizione dei medesimi step: identificazione degli obiettivi, delle alternative e dei vincoli; valutazione delle alternative, evidenziando tutti i potenziali rischi; sviluppo e verifica del prodotto; revisione dei risultati dei tre step precedenti, per procedere alla pianificazione del ciclo/giro successivo. Ogni step rappresenta un settore della spirale, costituita da una pluralità di cicli/giri. Al crescere della distanza dall’origine e, quindi, del numero di cicli/giri, aumentano i costi e i rischi. Questo riflette il fatto che il costo del cambiamento è tanto maggiore quanto più ci si avvicina alla fine dei progetti. Adottare il modello a spirale significa rinunciare all’analisi e alla formulazione di un’esaustiva pianificazione iniziale, con riferimento ai costi e ai tempi di sviluppo dell’intero progetto. Il vantaggio consiste nella maggior flessibilità, che si traduce nella capacità di adattarsi meglio ai cambiamenti, contenendo i rischi. Quando il software è realizzato su commessa, occorre avere alcune stime riguardanti i costi e i tempi delle varie attività da svolgere. Tali stime possono essere ottenute per mezzo di tecniche tanto raffinate quanto gelosamente custodite, capaci di rappresentare un vero e proprio fattore critico per il successo di ciascun progetto di sviluppo del software. Le statistiche dimostrano come il modello a spirale produca dei risultati in tempi solitamente più rapidi di quelli tipici del waterfall model o del modello incrementale.
Flessibilità, chiave del successo
Per mitigare il rischio derivante dalla scarsa completezza delle specifiche funzionali, gli utenti andrebbero sempre coinvolti in tutte le varie fasi dello sviluppo del software. Ma il loro coinvolgimento non è sufficiente per mettersi completamente al riparo dal grave pericolo insito nel cambiamento delle specifiche funzionali. Per certi versi, esso sembra essere un elemento del tutto naturale, legato alle dinamiche tipiche dello sviluppo del software. A volte il cambiamento delle specifiche funzionali è soltanto apparente. Spesso si tratta di correggere gli errori originati da specifiche funzionali incomplete o mal recepite. Ciò nonostante, l’estremo dinamismo, tipico dello sviluppo del software, rende strutturale il cambiamento: esso deve essere accettato, poiché rappresenta una delle tante regole del gioco. Anzi, forse, fra tutte le regole, proprio questa è oggi la più importante. Infatti, accanto al cambiamento imposto dalla correzione/revisione delle specifiche funzionali, dovuto ad aspettative ed esigenze mal recepite, sempre più spesso ci si deve misurare con una cruda realtà: le specifiche funzionali non sono costanti, ma cambiano nel tempo. Tale mutazione è indotta dalle variazioni ambientali e del contesto in cui s’inserisce lo sviluppo del software. Stando così le cose, la flessibilità diventa la vera chiave del successo.
Fondamentale dominare la complessità
Un altro serio problema è costituito dalle dimensioni dei progetti da gestire. Per cercare di far fronte alla complessità e all’estensione dei progetti più grandi, gli approcci tradizionali porterebbero ad analizzare il problema nel suo complesso, dividendo il sistema in un gran numero di parti, ciascuna delle quali andrebbe pianificata e realizzata in parallelo alle altre. Alla fine, per arrivare al risultato finale, bisognerebbe integrare le singole soluzioni. Per avere successo, i vari sottosistemi dovrebbero incastrarsi come i pezzi di un puzzle. Purtroppo in molti casi ciò non avviene. La scomposizione iniziale è un’operazione estremamente delicata, durante la quale c’è il rischio concreto di lasciare ai singoli sviluppatori fin troppi gradi di libertà, con conseguenze a dir poco disastrose proprio dal punto di vista dell’integrazione dei sistemi. Tali gradi di libertà sono per lo più legati alla mancata esplicitazione di alcuni requisiti o di certi vincoli, unitamente all’assenza di un’adeguata visione d’insieme: ogni sviluppatore, infatti, vede soltanto la porzione che gli compete. Poiché, in genere, l’integrazione ha luogo prima della fase di test o fra questa e quella di rilascio, dunque verso la fine del progetto, il costo di ogni cambiamento si rivela sempre particolarmente elevato. Insomma, per avere successo non basta essere flessibili: occorre anche imparare a dominare la complessità.
Talvolta, i miglioramenti nella gestione dello sviluppo del software possono anche essere trainati dall’innovazione tecnologica. Ciò avviene quando la risposta alle esigenze di flessibilità, in relazione ai cambiamenti delle specifiche funzionali/tecniche e di dominio della complessità, è fornita da una o più tecnologie, adottate per lo sviluppo del software. Un importante esempio in tal senso è costituito dall’aumento del livello di astrazione, verificatosi nel passaggio alla programmazione strutturata prima e a quella orientata agli oggetti poi. In questo modo il software diventa più facile da manutenere e anche da modificare. Ciò permette di spendere meno e risparmiare tempo prezioso. Sviluppo per componenti, unit testing e service oriented architecture sono tutte soluzioni che favoriscono la modularizzazione dei sistemi maggiormente complessi, minimizzando il rischio d’incompatibilità fra le parti che li costituiscono. Nonostante l’importante ruolo svolto dalla tecnologia, per una migliore gestione dei progetti di sviluppo del software serve un approccio nuovo e, per certi aspetti, rivoluzionario, capace di far fronte alle tante peculiarità tipiche di questo mondo complesso.
La metodologia Agile
Chi ha familiarità con l’organizzazione della produzione potrebbe osservare come l’Agile Project Management ricordi vagamente la celebre lean production tanto in voga negli ultimi decenni. Essere agili significa privilegiare le persone e le interazioni, che sono più importanti sia dei processi sia degli strumenti utilizzati o utilizzabili: l’uomo al centro, dunque. Analogamente, il funzionamento del software è prioritario, se confrontato con l’esaustività della documentazione, spesso sopravvalutata. Fra il cliente e il contractor dovrebbe instaurarsi un clima collaborativo e propositivo (insomma, un rapporto di partnership vera e propria), anziché uno scontro basato sul potere contrattuale delle singole parti. Infine, la rapidità di risposta (ecco un’altra analogia con il mondo della lean production) deve soppiantare la capacità di seguire pedissequamente la pianificazione iniziale, che potrebbe anche rivelarsi del tutto inadeguata o perfino sbagliata. Per essere agili occorre dividere l’intero progetto in una successione di piccole iterazioni, ciascuna delle quali può essere vista come un micro-progetto, comprendente al suo interno le fasi di analisi, progettazione, sviluppo e test. La novità è costituita dal fatto che ogni iterazione deve iniziare con la definizione delle funzionalità aggiuntive da rilasciare, dando vita a una versione funzionante del software. Essa deve rivelarsi capace di aggiungere la nuova funzionalità, che rappresenta lo scope of work dell’iterazione in questione, a tutte quelle preesistenti e già rilasciate. Nell’Agile Software Development le iterazioni sono molto brevi: da due settimane (casi più estremi) fino a un paio di mesi (al massimo). Una caratteristica che contraddistingue le metodologie agili è che questo intervallo di tempo viene considerato fisso: la durata della singola iterazione viene decisa a priori, dopo di che ci si preoccupa di quante funzionalità possano essere implementate nell’intervallo di tempo assegnato. Inoltre, ogni iterazione non viene mai prolungata, per fronteggiare eventuali ritardi nell’implementazione: se questo accade, alcune funzionalità vengono depennate, ma l’iterazione deve comunque concludersi nel tempo stabilito. L’estrema agilità, tipica di questa moderna metodologia, si riflette anche nelle dimensioni ideali dei vari team di sviluppo del software, che dovrebbero essere tutti davvero molto piccoli e snelli, comprendendo, in genere, dalle dieci alle quindici persone per ogni squadra. Ciò nonostante, ogni team dovrebbe avere, al suo interno, tutte le figure chiave, dando vita a un gruppo piccolo ma completo e fortemente coeso. Le ridotte dimensioni agevolano il coordinamento, l’interazione e lo scambio d’informazioni all’interno dei vari team, rendendo quasi impossibile la perdita di vista dello scope of work. I benefici, dal punto di vista del project control, non si limitano a questo, poiché le ridotte dimensioni agevolano i feedback e aumentano la reattività. Insomma, volendo sintetizzare al massimo, si potrebbe anche affermare che, grazie all’introduzione delle moderne metodologie agili, lo sviluppo del software viene reinventato e trasformato da un progetto a un processo continuo, in evoluzione costante e in equilibrio dinamico con l’ambiente esterno.
