|
L’AOSIS E LE NUOVE FRONTIERE
DELLA SICUREZZA
SETTORE IGNORATO DAL LEGISLATORE
ENTI
RESPONSABILI ANCHE IN SEDE PENALE
IL DECRETO LEGISLATIVO
231/01
AGILE
SOFTWARE DEVELOPMENT
LA CAPACITA' DI REAGIRE AL CAMBIAMENTO
AGILE SOFTWARE DEVELOPMENT
LA CAPACITA' DI REAGIRE AL CAMBIAMENTO
Rapidità con i nuovi metodi,
ma si affaccia il pericolo di "cowboy coding"
 Gerardo
Canfora e Corrado Aaron Visaggio
RCOST - Research Centre on Software Technology - Università degli
Studi del Sannio
gerardo.canfora@unisannio.it visaggio@unisannio.it
Sin dalla nascita l'industria del software è stata costantemente
alla ricerca di metodi e strumenti capaci di supportare la produzione
di sistemi di qualità nel rispetto dei tempi e dei costi pianificati.
Mutuando idee ed esperienze da altri settori produttivi, tale ricerca
si è subito indirizzata verso metodologie e processi rigorosamente
definiti, di natura prescrittiva, con grandi quantità di documentazione,
che fanno della possibilità di prevenire i cambiamenti, e i
rischi ad essi associati, il loro obiettivo principale. Fra le
caratteristiche fondamentali di tali processi vi sono:
- l'utilizzo di approcci top-down, che partono dall'analisi di
un'organizzazione per individuarne le pratiche correnti e le esigenze,
tradurle in modelli dei dati e dei processi di business, per poi passare
allo sviluppo delle applicazioni software;
- l'applicazione del metodo analitico, fondato sull'analisi e la
modellazione di tutti gli aspetti, sia relativi ai dati sia procedurali,
della realtà applicativa di interesse, nella convinzione che
con un adeguato sforzo di analisi sia sempre possibile comprendere
completamente le esigenze dell'utente e quindi costruire il sistema
giusto "al primo colpo";
- l'assunzione di una visione di lungo termine, resa necessaria,
fra l'altro, dagli ingenti investimenti sia economici che in termini
di tempo, richiesti dagli approcci analitici di tipo top-down.
Tale visione, che nel seguito chiameremo "plan-driven", è emersa
dalla rivoluzione dei cosiddetti metodi strutturati e, passando attraverso
l'epoca del CASE (Computer Aided Software Engineering), è poi
continuata con il movimento del "Software Process Improvement",
sino a giungere alla definizione di schemi standardizzati per l'assessment
e la certificazione dei processi di produzione del software, primi
fra tutti il modello CMM (Capability Maturity Model) del Software
Engineering Institute (http://www.sei.cmu.edu). Tuttavia, l'industria
del software presenta molti aspetti peculiari legati al contesto produttivo
e a quello di fruizione delle applicazioni. La risorsa umana, tramite
competenze e conoscenze, ma anche con la sua motivazione e le sue
emozioni, è il fulcro dell'intero processo di produzione del
software. A ciò va aggiunto che le applicazioni software, nella
maggior parte dei casi, si calano in contesti organizzativi e sociali
complessi, e quindi difficili da modellare in maniera esaustiva, nonché in
costante evoluzione, il che rende vano ogni sforzo di prevenzione
dei rischi. Tutto ciò ha portato spesso al fallimento dell'approccio "plan-driven",
soprattutto per sistemi di grandi dimensioni o relativi a domini applicativi
scarsamente compresi e ad alto tasso di cambiamento. Per capire la
portata di tali fallimenti, si pensi che l'ultimo rapporto dello Standish
Group (http://www.standishgroup.com), un primario gruppo di consulenza
del settore IT che sin dal 1995 raccoglie e analizza dati relativi
all'industria del software, riporta che il 23% dei progetti software
sono cancellati prima della conclusione, il 49% fa registrare ritardi
e lievitazione dei costi rispetto alla pianificazione originale, e
solo il 28% si conclude con successo. È questo lo scenario
in cui irrompono i cosiddetti metodi agili che, contrariamente a quelli "plan-driven" fanno
della capacità di reagire al cambiamento, piuttosto che di
prevenirlo, e del minimalismo dell'analisi in favore di cicli di sviluppo
brevi con il continuo coinvolgimento degli utenti, i loro punti di
forza. Sebbene siano stati proposti diversi metodi agili, fra i quali
citeremo ad esempio il più noto di tutti, l’eXtreme Programming,
XP (www.extreme- programming.org), oppure Crystal (alistair.cockburn.us/crystal/crystal.html),
e ancora Dynamic Systems Development Method (www.dsdm.org), Feature
Driven Development (all’indirizzo www.nebulon.com/articles/fdd/fddoverpres.html),
e Scrum (jeffsutherland.org/scrum), tutti implementano comunque i
quattro principi fondamentali raccolti nel manifesto del 2001 (agilemanifesto.org):
1. Individui e iterazioni piuttosto che processi e strumenti. Lo
sviluppo "plan-based" si basa sulla descrizione di processi
che definiscono rigorosamente le attività da realizzare e le
procedure da seguire. In opposizione a questi, i metodi agili propongono
iterazioni continue quale strumento per migliorare, in modo incrementale,
il software prodotto. Si preferisce fare affidamento sulle competenze
individuali e la capacità di comunicazione e cooperazione del
gruppo, piuttosto che sugli strumenti di supporto all'esecuzione del
processo.
2. Software funzionante al posto di una documentazione onnicomprensiva.
La filosofia agile ha come obiettivo principale quello di rilasciare
quanto prima possibile versioni del prodotto funzionante e rispondente
ai requisiti del committente. Questo comporta una riduzione molto
drastica della documentazione di progetto.
3. Collaborazione del committente piuttosto che negoziazione del
contratto. Anzichè negoziare con il committente l'architettura
del prodotto finale, il documento dei requisiti e il test d'accettazione
del prodotto, la filosofia agile suggerisce di rendere il committente
partecipe dell'attività di sviluppo.
4. Risposte ai cambiamenti piuttosto che rispetto dei piani. Lo
sviluppo del software guidato "plan-driven" non consente
di rispondere adeguatamente ai cambiamenti che alcuni contesti impongono
ai requisiti, già durante lo sviluppo del software. I modelli
di processo incrementali cercano di mediare tra la necessità di
rispondere a contesti instabili e quella di seguire un processo definito.
Indubbiamente i principi alla base dei metodi agili, e gli strumenti
che i diversi metodi hanno definito per la loro realizzazione pratica,
prime fra tutte le oramai famigerate dodici pratiche di XP, appaiono
molto invitanti e questo spiega il loro grande successo. Spesso, però,
dietro alla dichiarata adozione di un approccio agile si nasconde
semplicemente l'illusione che sia possibile fare a meno della sovrastruttura
prescrittiva tipica dei metodi "plan-driven", senza peraltro
comprendere e realizzare fino in fondo tutti i principi e le pratiche
dell'approccio e i cambiamenti organizzativi e culturali che ne conseguono.
Così, molte aziende vedono con favore la riduzione, se non
la totale eliminazione, della documentazione, ma ben poche sono disposte
a investire nelle pratiche del "pair programming" e della "ownership" collettiva
del codice.
Molte aziende sono felici di ridurre le attività di analisi
per passare subito allo sviluppo del codice, ma poche sono quelle
che fanno corrispondere a tale riduzione l'adozione di un approccio
di sviluppo "test driven", della pratica del "refactoring" e
dell'integrazione quotidiana. All'abolizione della pianificazione
di lungo periodo raramente fanno riscontro la pratica del "planning
gaim" quale strumento per la negoziazione e, cosa fondamentale,
la partecipazione attiva del committente al processo di sviluppo.
Per dirla in breve, spesso dietro alla dichiarata adozione di un approccio
agile si nasconde un salto indietro verso la vecchia pratica del "code
and fix", ossia della totale assenza di metodo. I metodi agili
hanno sicuramente la possibilità di rimuovere alcuni degli
aspetti deleteri dello sviluppo "plan-based".
Certo rimane da capire quali siano le tipologie e le dimensioni
progettuali cui si adattano meglio, e questo richiederà tempo
e indagini empiriche. Sin d'ora è però possibile mettere
in guardia le aziende a non confondere sviluppo agile con "cowboy
coding". |
