Gabriele Lana

Prosegue la serie di articoli (tre in tutto) che hanno come obiettivo quello di rispondere a domande del tipo: “Perchè le metodologie tradizionali non funzionano?”. Il primo problema che abbiamo identificato è determinato dal parallelo che viene fatto fra le fasi della produzione di un artefatto ingegneristico e le fasi della produzione del software, in questo articolo analiziamo il perchè della divisione in “fasi” e le sue implicazioni

La divisione in fasi del lavoro è stata inizialmente concepita per le produzioni di tipo manifatturiero: spezzando la lavorazione in fasi discrete, organizzandole in una catena continua e isolandole le une dalle altre, è possibile semplificare il lavoro di ottimizzazione e di controllo della qualità. Perchè non applicare gli stessi concetti anche alla produzione del software? Ogni fase elabora l’intero progetto ad un determinato livello d’astrazione, ogni fase viene lavorata da persone che sviluppano competenze specifiche riducendo la probabilità di difetti, infine al termine di ogni fase possiamo controllare la qualità dei semilavorati e verificare l’andamento del progetto. Sembrerebbe filare tutto liscio, ma…

La divisione in fasi in ambito manifatturiero funziona solo se i semilavorati che vengono prodotti possiedono determinate proprietà, per esempio devono essere facilmente trasportabili e non devono degradarsi, se così non fosse quello che perderemmo durante il trasporto potrebbe avere un costo maggiore del valore del semilavorato stesso. A questo punto ci chiediamo: i deliverable (semilavorati) relativi alle fasi di produzione del software, di che natura sono? Sono artefatti di rappresentazione della conoscenza che abbiamo del progetto ad un determinato livello d’astrazione, ovvero qualcosa di molto degradabile

• Mai giocato a passaparola? In questo caso le cose sono ancora peggiori: quello che vuole il cliente è diverso da ciò che l’analista pensa che il cliente voglia, ciò che l’analista ha capito è diverso da ciò che l’analista scriverà nel documento d’analisi, che sarà diverso da ciò che capirà l’architetto leggendo il documento d’analisi, ecc… Più le fasi sono isolate, più le fasi sono numerose, più la pressione e l’urgenza aumentano, più questo effetto peggiora, esattamente come nel gioco, e nel gioco devi solo ripetere una frase, non interpretarne il significato
• Nella produzione manifatturiera la qualità del semilavorato è valutabile al di fuori di ogni contesto, la stessa cosa non può essere fatta anche con gli artefatti prodotti durante la realizzazione di un software, in quanto l’artefatto non è fine a se stesso, ma è la rappresentazione di qualcos’altro, la sua qualità può essere giudicata solo misurando l’accuratezza della rappresentazione stessa. Tutto questo per dire che il degrado nel tempo può essere causato anche da un cambiamento in ciò che si vuole rappresentare (alzi la mano chi non ha mai avuto un cliente che abbia cambiato idea durante un progetto)

Un’altra cosa che dobbiamo considerare è la probabilità d’errore: è vero che attraverso la specializzazione di ogni fase è possibile ridurre la probabilità d’errore al suo interno, ma è anche vero che la probabilità d’errore totale non è la somma delle probabilità nelle singole fasi, ma il loro prodotto, quindi non è detto che la riduzione della probabilità d’errore locale, dovuta all’introduzione di una fase specializzata, riduca la probabilità d’errore globale, che alla fine è l’unica cosa che ci dovrebbe interessare

Infine notiamo che non è possibile, come abbiamo accennato prima, valutare la qualità del singolo artefatto se non valutandone l’accuratezza, e questa valutazione non è possibile farla secondo parametri oggettivi (come nel caso della manifattureria), l’unico modo possibile è coinvolgere gli stessi meccanismi che portano alla realizzazione dell’artefatto e che quindi sono passibili degli stessi errori. Questo ci porta a concludere che non è possibile valutare l’andamento del progetto se non alla fine dello stesso, dove il cliente può provare ciò che è stato realizzato e verificare se effettivamente risolve le sue necessità

Tutti questi problemi sorgono per una ragione molto semplice: la produzione del software non c’entra niente con la manifattura. E’ la stessa differenza che c’è fra il lavoro di un cuoco che deve inventare una nuova ricetta, e una cucina che deve seguire una ricetta. Da una parte l’obiettivo è quello di soddisfare il palato del cliente, per farlo il cuoco farà molti esperimenti, proverà combinazioni di alimenti diversi, tempi di cottura diversi, ad ogni tentativo raccoglierà del feedback che guiderà il tentativo successivo; nel caso del cuoco l’errore è necessario per l’acquisizione di feedback, necessario per l’acquisizione di conoscenza, necessaria per raggiungere lo scopo. Dall’altra l’obiettivo è quello di riprodurre fedelmente la ricetta nel più breve tempo possibile, per farlo la cucina può dividere la realizzazione della ricetta in fasi, può ottimizzare ogni singola fase tenendo come parametro di confronto il piatto originale, nel caso della cucina lo scopo è quello di evitare gli errori

Se non siete ancora convinti, non perdetevi l’ultima parte, non ne rimmarete delusi :-)