Uno studio commissionato dalla società di consulenza Engprax ha fatto emergere risultati decisamente inattesi sull’efficacia delle metodologie Agili nello sviluppo software. La ricerca, condotta intervistando 600 ingegneri software nel Regno Unito e negli Stati Uniti, ha rivelato che i progetti che adottano pratiche Agile, spesso usati per esperimenti e progetti pilota, hanno addirittura il 268% di probabilità in più di fallire rispetto a quelli che non le adottano.

Questo dato alimenta i sospetti di una parte della comunità che il tanto osannato Manifesto Agile potrebbe non essere così efficace come viene dipinto. Uno dei risultati più eclatanti è che i progetti in cui i requisiti sono stati chiaramente documentati prima dell’inizio dello sviluppo hanno il 97% di probabilità in più di avere successo.

Ciò va in netto contrasto con uno dei quattro pilastri del Manifesto Agile (Working Software over Comprehensive Documentation). Secondo lo studio, mettere in atto una specifica prima di cominciare lo sviluppo può portare ad un aumento del 50% delle probabilità di successo, mentre assicurarsi che i requisiti rispecchino accuratamente il problema reale può far crescere le probabilità del 57%.

Il Dr. Junade Ali, autore del libro Impact Engineering, ha dichiarato che con il 65% dei progetti Agile che non vengono consegnati in tempo, è giunto il momento di mettere in discussione il culto Agile, per il quale, non dovendo fare mesi di studio e documentazione delle specifiche, la fase iniziale costa meno e quindi è anche più facile per i vertici aziendali “staccare la spina” di un progetto senza pensarci troppo.

La ricerca dimostra che ciò che conta veramente per consegnare software di alta qualità nei tempi e nei budget prestabiliti è un solido processo di ingegnerizzazione dei requisiti e avere un ambiente sicuro dal punto di vista psicologico per discutere e risolvere i problemi man mano che emergono, prendendo al contempo misure per prevenire il burnout degli sviluppatori.

Anche altre metodologie di sviluppo hanno comunque i loro difetti. Waterfall, ad esempio, utilizza una successione di fasi documentate di cui la codifica è solo una parte. Mentre è semplice da capire e gestire, può anche essere lento e costoso, con modifiche difficili da implementare. Quindi c’è una tendenza dei team a cercare alternative.

Uno dei dati più preoccupanti emersi dallo studio è che i progetti in cui gli ingegneri sentivano di avere la libertà di discutere e affrontare i problemi avevano l’87% di probabilità in più di avere successo. Purtroppo, i lavoratori nel Regno Unito avevano il 13% di probabilità in meno di sentirsi liberi di discutere i problemi rispetto a quelli negli Stati Uniti.

Molti dei problemi dell’attuale mondo tecnologico tendono ad essere attribuiti al Manifesto Agile. Un flusso infinito di patch, codice incompleto o superficiale che arriva in questo stato sono tutti aspetti che vengono imputati alle pratiche Agile, ma se è vero che il Manifesto Agile ha i suoi problemi, questi derivano più dall’implementazione che dai principi stessi. Frasi come Non abbiamo bisogno di un team di test perché siamo Agile sono un’abdicazione di responsabilità a favore del risparmio di costi.

Evidenziando la necessità di comprendere i requisiti prima di iniziare lo sviluppo, la ricerca traccia una via di mezzo tra i puristi di Agile e i sostenitori di Waterfall, invitando a trovare un equilibrio nel riconoscere i punti di forza di entrambi gli approcci pur sottolineandone anche le debolezze.