Questo articolo è stato scritto per iubenda da Antonello Calamea, Fractional CTO, IT Mentor & Coach.
Il mondo dello sviluppo software, insieme a tutto ciò che gli ruota attorno, ha subito enormi cambiamenti negli ultimi quarant’anni.
Negli anni ‘80, l’avvento del personal computer, simbolo della democratizzazione dell’informatica precedentemente riservata al solo mondo “corporate”, ha innescato un aumento esponenziale della domanda di software. Quest’ultimo è quindi diventato l’elemento fondamentale per la fornitura di nuovi tipi di servizi.
In quegli stessi anni, abbiamo assistito anche alla crescita di colossi come Microsoft e Apple, il che ha portato alla necessità di gestire progetti il cui “deliverable” fosse la produzione di software.
Nel 1970, emerse una metodologia che per molti anni fu lo standard de facto e che tuttora è largamente utilizzata: il modello Waterfall.
Vediamo di cosa si tratta.
La metodologia Waterfall si basa su un approccio sequenziale, che include fondamentalmente una fase di analisi dei requisiti, una di progettazione, una di sviluppo, una di testing, per arrivare poi alla consegna e successiva manutenzione.
In altre parole, si determina cosa c’è da fare, si progetta una soluzione, la si implementa, si verifica che funzioni e la si rende disponibile per l’utilizzo.
Questo approccio potrebbe sembrare sensato (e in certi contesti lo è), ma consideriamo questo grafico.
C’è un evidente quasi paradosso, che consiste nel prendere molte decisioni nella fase di analisi e progettazione, quando la conoscenza di quello che si vuole davvero fare e di come farlo è bassa. Queste decisioni vengono poi ratificate e “congelate”, impedendo ulteriori modifiche durante l’implementazione, quando il livello di conoscenza aumenta.
Inoltre, manca completamente una fase di restituzione di feedback; non c’è modo di validare “sul campo”, ovvero sul mercato, l’efficacia di una certa assunzione se non al termine di tutto il progetto.
Ma che cosa significa “acquisire conoscenza” nel contesto dello sviluppo software? Il Cynefin Framework può aiutarci a rispondere a questa domanda.
Da pronunciare “Canevian” (termine scozzese che significa habitat, inteso come l’habitat in cui operiamo), il Cynefin è un framework introdotto da Dave Snowden nel 1999 per facilitare il processo decisionale.
Per citare le sue parole: “Situazioni problematiche diverse giustificano approcci diversi per trovare la giusta soluzione”.
Ci sono quattro aree diverse che individuano quattro possibilità differenti:
Diventa subito evidente come il metodo Waterfall non sia la soluzione ideale a causa della sua rigidità, che mal si adatta a contesti in cui il rapporto di causa-effetto non è rilevabile a priori e che può risultare poco adeguato anche in progetti “complicati”.
Cosa fare, allora?
Un elemento curioso e interessante è il fatto che i concetti alla base della nascita dell’Agile derivano da industrie standard, come quelle manifatturiere. Queste, già a partire dalla metà del secolo scorso, stavano vivendo un importante cambiamento, con l’avvento del TPS (Toyota Production System) negli anni ‘50, poi tradotto in occidente come Lean Manufacturing negli anni ’90.
Questi approcci introducevano concetti legati alla riduzione degli sprechi e alla creazione di valore attraverso una produzione più efficiente e flessibile, concetti che sono stati successivamente adattati al contesto informatico.
Nel 1995 fece infatti la sua comparsa Scrum, un metodo per la gestione di progetti software che trae ispirazione dal Lean Manufacturing.
Un altro evento significativo si verificò nel Febbraio 2001, negli Stati Uniti. Un gruppo di figure di rilievo nel settore dello sviluppo software si riunì con l’intento di trovare un paradigma diverso rispetto ai metodi tradizionali fino ad allora utilizzati.
Da quell’incontro nacque l’Agile Manifesto, un breve documento che si articola in quattro valori e dodici principi.
È importante citare almeno i valori, per capire la differenza rispetto al passato:
E la frase subito successiva, altrettanto importante per intenderne l’essenza:
“Ovvero, sebbene riconosciamo il valore delle voci a destra, consideriamo più importanti le voci a sinistra.”
Così, la flessibilità, comunicazione costante, e la capacità di adattarsi alle esigenze del cliente diventano fattori principali, che supportano (e non sostituiscono) un approccio più rigido e formale.
In altre parole, strumenti, documentazione, contratti e pianificazione sono comunque necessari, ma rivestono un ruolo meno rilevante.
Rispetto al Waterfall, si passa da una visione basata sulla predizione e il controllo ad una in cui prevale la condivisione dell’autonomia. Si preferisce un approccio adattivo, in cui ci si adegua al cambiamento — che è parte integrante del processo — piuttosto che un approccio reattivo, in cui si reagisce ad eventi non previsti.
Le decisioni, che in passato erano prese dal management, spesso separato dalla linea produttiva, sono ora prese “sul campo”. Quello che c’è da fare, anziché essere predefinito e immutabile, evolve e cambia nel tempo, per adattarsi a ciò che è importante in un preciso momento.
Se volessimo esprimere quale sia la value proposition di un approccio Agile, potremmo dire che mira a:
Tutto questo è realizzato attraverso:
È dunque possibile affermare che un approccio Agile (declinato poi in vari framework e metodologie, come ad esempio Scrum e Kanban) sia IL modo giusto di fare software?
La risposta è che non c’è un modo giusto di fare software, ma esistono approcci più o meno consigliati rispetto ad un particolare contesto. Questo non è solo legato al tipo di progetto, tecnologia o mercato di riferimento, ma anche alle persone che ne saranno parte attiva.
Ed è proprio per questo che è importante fare una precisa distinzione tra “fare Agile” ed “essere Agile”.
Quando si adotta una metodologia, specie se essa implica principi e valori che rientrano nell’aspetto comportamentale e valoriale di chi li deve mettere in pratica, è necessario fare qualche considerazione in più rispetto alla mera adozione di passi operativi e best practice.
“Essere Agile” vuol dire proprio avere un approccio in cui si accoglie il cambiamento, si è flessibili, si ha una costante volontà di miglioramento e si dà valore. Sono questi i driver attitudinali che poi alimentano specifiche azioni.
Molto spesso, invece, ci si limita al “Fare Agile”, ovvero si segue magari scrupolosamente un manuale d’uso, con la speranza che risolva problemi pratici e di processo che invece sono di altra natura e più legati alla sfera “personale” (ad esempio comunicazione o attitudine).
Non è per niente paradossale affermare che, quando non ci sono le condizioni necessarie, la scelta più Agile possibile sia il non fare Agile.
Ma al di là di dinamiche che coinvolgono più persone, cosa si può fare a livello individuale rispetto a questo tipo di approccio?
Se metodi e framework sono utilizzati a livello di team, proprio per permettere di operare in una certa maniera condivisa, l’Essere Agile è qualcosa che, come detto, è prima di tutto un’attitudine e, di conseguenza, si può applicare anche a livello individuale.
Ad esempio, avere piena consapevolezza di quello che c’è da implementare e consegnare all’interno di un periodo di tempo predefinito è un elemento essenziale da definire con lo stakeholder, proprio per avere una definizione chiara e condivisa di cosa porti più valore in un determinato momento.
Essere pronti a modificare il proprio lavoro in base alle richieste del Cliente o alle necessità del progetto, piuttosto che difendere specifiche posizioni come immutabili, è un altro elemento molto importante, che richiede quindi capacità di adattamento e di flessibilità.
Tuttavia, è fondamentale bilanciare questa propensione al cambiamento: non dovrebbe essere attuato in modo indiscriminato, ma gestito con attenzione e criterio. Questo perché è necessario mantenere un certo grado di stabilità nelle nostre attività per assicurare l’efficienza.
Ecco perché la comunicazione continua con tutte le persone coinvolte, in modo da dare e ricevere feedback e definire delle regole semplici, chiare e condivise è forse il comportamento più importante da adottare.
Come abbiamo visto, scrivere software significa navigare nell’incertezza.
La celebre affermazione di Brian Kernighan, un noto programmatore, che dice “dominare la complessità è l’essenza della programmazione”, ci ricorda l’importanza di cercare la semplicità anche nella gestione, evitando di aggiungere ulteriore complessità a qualcosa che di per sé è già complesso.
Nella mia esperienza, ho appreso che strumenti, metodologie e la stessa tecnologia danno il massimo quando sono il risultato di valori, atteggiamenti e preparazione.
Trasparenza, ispezione e adattamento sono i tre pilastri che guidano un approccio empirico, in cui l’esperienza si trasforma in conoscenza. Questa conoscenza ci dà la possibilità di intraprendere nuove azioni, valutare i risultati e così via, alimentando un ciclo continuo e incrementale.
Tuttavia, è importante sottolineare che questo approccio non è adatto a tutti i contesti e potrebbe richiedere tempo per assimilare i suoi valori a coloro che lo adottano, proprio perché comporta un lavoro a un livello più profondo rispetto a quello puramente operativo.
Pertanto, il mio consiglio è di iniziare a sperimentare con curiosità per scoprire cosa funziona meglio per te, di imparare dalle tue esperienze e da quelle degli altri, con l’obiettivo di migliorarti come professionista e come individuo.