Negli ultimi cinque anni ho fatto parte di due team agili. Secondo la mia esperienza, osservando la realtà senza preconcetti, dovrei aver dedotto che l’agile non funziona, o non serve.

Su cosa si dovrebbe basare un giudizio sulle pratiche agili? Penso, principalmente, sulla soddisfazione degli utenti finali del software prodotto. Beh, non ricordo un cliente veramente soddisfatto. I casi emblematici sono due.

Uno: gli utenti erano più contenti prima che arrivasse l’agile, perché allora, quando qualcuno aveva un problema, faceva una telefonata e arrivava uno sviluppatore, che sistemava l’eventuale bug, e installava al volo un eseguibile dell’applicazione sul pc dell’utente. Con gli “Agili”, occorre più tempo per avere il fix, e, una volta sistemato il bug, si deve aspettare il “prossimo rilascio”. Prima l’utente era operativo da subito, senza attendere lo svolgersi di quella che viene percepita come burocrazia.

Due: il cliente critica il team agile perché, a fronte di un costo maggiore degli altri, non presenta una maggiore efficacia. Stessi risultati dei “non agili”, costi maggiori.

Allora si potrebbe spostare l’attenzione sulla qualità interna e dire: “sì però il codice prodotto è sicuramente di qualità!” No. Spesso è clamorosamente complesso, complice quella patternite di cui soffrono, non di rado, gli agilisti.

L’idea che basti una serie di pratiche per avere codice semplice, con un buon design, è sbagliata. Non sono il TDD o il pair programming (o qualunque altra pratica) che ti fanno scrivere codice di pregio. Il design non emerge da solo grazie alle pratiche. Il design deve essere prima nella testa di chi programma. E se chi programma non è in grado di creare software semplice, non saranno le pratiche a permettergli di farlo.

Una frase che ho sentito spesso, per giustificare l’insoddisfazione del cliente, suona più o meno così: “noi siamo molto migliori degli altri, ma non riusciamo a dimostrarlo”. Beh, essere bravi senza riuscire a dimostrarlo equivale a non essere bravi affatto.

Personalmente, l’unico vero vantaggio che ho percepito nel lavorare in modo agile è stato che il lavoro era molto meno stressante di quanto non sarebbe stato diversamente. Modificare il codice con relativa tranquillità, grazie ai test, non ha prezzo. Secondo me, ottenere risultati analoghi agli altri, ma senza fare le notti e dormendo sonni tranquilli è già un ottimo risultato. Ma è sufficiente?