Gabriele Lana

Termina la serie di articoli che mi sono proposto di scrivere per riassumere (in tre parti) il perchè dell’inadeguatezza delle metodologie tradizionali (anche dette metodologie ingegneristiche). Terminerò facendo una grossa assunzione iniziale e la farò a danno della tesi che voglio sostenere… capirete fra poco il perchè (spero). Ammettiamo che le metodologie tradizionali siano delle macchine perfette, ovvero ammettiamo che seguendo una di queste metodologie un team abbia la certezza matematica di ottenere un prodotto finale conforme alle specifiche, nei tempi e nei modi stabiliti.

Fare questo tipo di assunzione significa però assumere che esista il concetto di “correttezza a priori”, ovvero che esista la possibilità di determinare all’inizio del progetto il concetto di “correttezza”, il che presuppone che ci debba essere “predicibilità”, altrimenti sarebbe impossibile “pianificare correttamente”. Quindi alla fine per far funzionare tutta questa sequenza di implicazioni logiche, abbiamo la necessità di fare un’ulteriore assunzione, ovvero quella di avere dei “requisiti stabili” che ci diano quella “predicibilità” di cui abbiamo bisogno. Chiunque abbia un po’ di esperienza nel campo dello sviluppo del software sa quanto questo sia difficile, ma sapete una cosa? Mi voglio rovinare e vi regalo anche questa!

Ricapitolando: ho concesso (per ipotesi) alle metodologie tradizionali la certezza matematica di riuscire ad ottenere un prodotto conforme a dei requisiti che sono garantiti stabili durante il periodo di sviluppo… l’ho fatto perchè quest’ultimo articolo non vuole criticare il “come” le metodologie tradizionali intendono raggiungere gli obiettivi prefissi, ma vuole criticare gli obiettivi stessi, in particolare il concetto di correttezza.
Correttezza, per queste metodologie, è sinonimo di conformità alle specifiche, il che è perfetto nel mondo accademico, in un mondo artificiale, in un mondo dove il cliente è la specifica. Nel mondo reale le cose non stanno proprio così.

Cosa succederebbe se le specifiche fossero sbagliate? Saremmo portati a rispondere che otteremmo un prodotto finale sbagliato, il che sembrerebbe un po’ un assurdo viste le ipotesi di perfezione che abbiamo fatto; allora ci chiediamo: Cosa vuol dire che il prodotto finale è corretto? O meglio, cosa vuol dire che le specifiche sono corrette? Se come me vivete nel mondo reale: “la specifica di un software è corretta se l’utilizzo del prodotto che ne deriva raggiunge gli obiettivi del committente”.

A questo punto qualcuno potrebbe obiettare indicando come responsabilità degli analisti quella di scrivere specifiche corrette, al che domanderei: secondo voi è possibile scrivere specifiche corrette (secondo la definizione di correttezza che abbiamo dato)? Siamo sicuri che all’inizio del progetto esistano già tutte le informazioni necessarie per scrivere delle specifiche che una volta implementate consentiranno al nostro cliente di raggiungere i suoi obiettivi? Gli obiettivi del cliente rimarranno sempre quelli? Il modo in cui il nostro cliente può raggiungere i suoi obiettivi cambierà nel tempo? Ma sopratutto, abbiamo un modo per misurare se il nostro cliente ha raggiunto i suoi obiettivi?

Richiedere la “stabilità dei requisiti” significa richiedere non solo la “stabilità degli obiettivi” ma anche la “stabilità delle strategie per raggiungerli”, questo ci porta ad ambiente immobile, un abiente in cui l’acquisizione di conoscenza è scoraggiata, in cui il cliente viene isolato in quanto pericoloso “agente di cambiamento”, poco importa se quella conoscenza e quei cambiamenti sono indispensabili per permettere al cliente di raggiungere i suoi obiettivi! Questa è la mia più grande critica alle metodologie tradizionali, un difetto che non lascia scampo: il cercare di adattare il mondo reale a quello che funziona in laboratorio, ammesso e non concesso che funzioni, non dimenticatevi che è solo un’ipotesi :-).

Tutto questo mi ha portato ad amare le metodologie Agili perchè hanno il coraggio di confrontarsi continuamente con degli obiettivi reali, misurando iterazione dopo iterazione l’efficacia del prodotto realizzato fino a quel momento e sfruttando ogni dato rilevato come un’opportunità di miglioramento, ma questa è un’altra storia…