Andy's Weblog

Metodologie RUP vs. Agile nello sviluppo del software martedì 12 gennaio 2010

Lo sviluppo del software vede sempre più il confronto tra metodologie altamente strutturate (RUP) e quelle che vorrebbero essere le più elastiche possibili (Agile).

Il conflitto è, in parte, tra coloro che vogliono assicurare la qualità formale rispetto alla qualità sostanziale.

Il giusto, o il meglio, ovviamente non sta né da una parte né dall’altra, ma più probabilmente nel mezzo.

Ma in che modo?

Non posso che condividere il pensiero che la programmazione sia un fatto artigianale, in quanto frutto di un’invenzione; tutto ciò che non è più artigianale si trasforma in software consolidato, librerie, componenti standard.

Da programmatore riesco perfettamente a capire quanto possa stare ‘stretto’ l’abito di colui che produce righe di codice secondo regole e schemi.

Da responsabile della Qualità, ritengo che la bellezza e le promesse della metodologia RUP siano il Santo Graal per la produzione del software.

Le metodologie di tipo Agile sono soltanto un compromesso, per venire incontro all’ingestibilità innata dei programmatori (quelli bravi, soprattutto), delle specifiche del cliente in eterno divenire, la documentazione (costosissima) che non riesce mai ad essere allineata allo stato dell’arte del progetto, dei budget di progetto per definizione sottodimensionati e dei tempi di consegna spesso irragionevoli.

In medio stat virtus, dicevano i latini, e già Aristotele era giunto a questa conclusione.

Il problema è riuscire a definire (e in qualche modo a formalizzare) quale sia questa via di mezzo.

L’eccessiva formalizzazione porta a spendere più tempo a ‘vestire’ il progetto (specifiche, documentazione, etc.) che a realizzare l’obiettivo finale.

L’eccessiva libertà porta in breve tempo a risultati vicini all’optimum, lasciando tuttavia dei lavorati (o semilavorati) con costi di manutenzione impredicibili.

L’arte sta, probabilmente, nel concentrarsi nel punto di incontro tra sviluppo ed utilizzo del software, tra fornitore e cliente.

È in questo punto che si scopre se il lavoro risponde ai requisiti o meno, ed in cui emergono i requisiti nascosti.

Sostanzialmente è il momento del collaudo che, da istante finale del lavoro, deve diluirsi nel tempo, affinando i punti e gli elementi di controllo.

Ad esempio, invece che lasciare al fornitore le attività di installazione, sarebbe molto più appropriato gestire internamente tale attività, o comunque delegarla ad una società terza: in questo modo qualsiasi mancanza in termini di documentazione dell’architettura e delle procedure di compilazione ed installazione apparirebbe in modo palese dal mancato funzionamento del sistema.

E lo stesso vale per la formazione agli utenti ed al personale incaricato di gestire il sistema: interponendo una figura terza, tutte le carenze documentali verrebbero immediatamente a galla.

Diviene quindi fondamentale che all’inizio non vengano posti requisiti troppo specifici, ma soltanto quelli sostanziali, quelli che discriminano tra l’usabilità o meno del prodotto finale, tra l’eseguibilità o meno, tra l’integrabilità o meno, nonché la sua affidabilità nel tempo.

Metodologia, strumenti, linguaggi, componenti software .. tutti elementi di fatto ininfluenti ai fini del risultato, se il controllo diviene sostanziale e non formale; se il prodotto viene verificato rispetto alle reali esigenze del cliente, e con continuità.

Ovviamente, e con questo concludo, occorre assolutamente sviluppare una nuova cultura (e ribadisco ‘cultura’, rispetto al termine ‘metodologia’) per l’identificazione e la definizione dei requisiti di progetto.