La cultura dell’agilità si rispecchia nella velocità con cui si prendono le decisioni, nella misura in cui si monitora un processo per prendere decisioni informate, nella misura in cui si adatta un processo per migliorare la qualità di un prodotto nel rispetto della sostenibilità.

Nel contesto dell’ingegneria del software, che un po’ è arte e un po’ è scienza, agile non vuol dire necessariamente finire prima o spendere meno. Significa piuttosto capire presto quando un processo non funziona. Significa spendere meglio per ottenere maggiore qualità. Tipicamente questo comporta anche il finire prima, senza che però questo sia l’obiettivo da raggiungere. La qualità è l’obiettivo. Due esempi su tutti, ben rappresentativi a mio avviso della cultura dell’agilità.

Le revisioni di codice (code review). Se il codice di un progetto presenta un elevato debito tecnico, forse adottare un processo di code review unitamente a degli strumenti di analisi statica potrebbe migliorare la qualità interna senza richiedere nel medio-breve tempo un investimento economico insostenibile. Organizzare code review con cadenza fissata e monitorare lo stato di avanzamento del progetto, misurando poi alcuni indici di qualità del codice, permette di capire se la pratica delle revisioni è efficace, tenuti in considerazione i vincoli di qualità del progetto e il contesto sociale dell’organizzazione. Adattare il processo con l’obiettivo di migliorare la qualità del prodotto e avere feedback precoce sono due punti nevralgici dell’essere agile. Se, per contro, impieghiamo sei mesi solo per decidere di fare qualche revisione di codice significa che stiamo ancora pensando in modo monolitico, a cascata, guidati dalle emergenze. Quando ci sarà abbastanza tempo, una volta terminate le attività a calendario, allocheremo le risorse per le revisioni. Chi ragiona guidato dai calendari e dalle emergenze rischia di trovarsi continuamente in emergenza perché il processo è inefficiente, non è adattativo, non misura continuamente il feedback. E alla fine i calendari sono fatti per essere riepiti e così arrivano nuove scadenze. L’azienda diventa bloccata, immobile. E la qualità del prodotto diminuisce costantemente perché, se non gestita esplicitamente, essa diventa inversamente proporzionale alla complessità.

Un altro esempio: il testing. Essere agili vuol dire capire presto il livello di testing necessario e sostenibile per verificare un determinato livello di qualità nel prodotto finale. Significa conoscere varie strategie e adattare il proprio approccio al testing. Se si hanno poche risorse, forse faremo meno test di unità e più test di accettazione end-to-end, usando lo stile del Behavior-Driven Development Testing. Se un test formale non è richiesto dal cliente, forse un approccio utile per scovare il maggior numero di bachi nel minor tempo è il testing esplorativo. L’uso delle asserzioni, poi, può ridurre i tempi di debug, fornendo diagnostiche interne molto precise. Essere agili vuol dire porsi il problema presto, fin dall’inizio del progetto (molte asserzioni di dominio, ad esempio, nascono fin dalle prime iterazioni di analisi dei requisiti). Essere agili vuol dire adattare il processo di sviluppo per integrare la strategia scelta, raccogliere contestualmente feedback e prendere decisioni informate.