Il tema della Metodologia Agile riguarda una delle sfide più importanti che qualsiasi azienda si trova quotidianamente a fronteggiare, e cioè di rispondere adeguatamente ai cambiamenti, da quelli normativi a quelli culturali, sociali, economici. Sono cambiamenti tipici, sempre esistiti, ma la novità di questo decennio è la forte impennata dei processi di trasformazione che ormai coinvolge praticamente ogni settore industriale.
In questo contesto di continuo e veloce cambiamento, come possono le aziende restare competitive?
Per un’azienda operante nel settore dei rifiuti come Dife, la risposta sta nella capacità di considerare i processi di trasformazione non più come una minaccia, ma come una opportunità. Si tratta di un approccio che deriva direttamente dall'esperienza in un settore complesso come quello della gestione dei rifiuti, ma la cui adozione oggi si sta allargando praticamente ad ogni settore, ed ha un suo nome ed una sua formulazione metodologica.
Si tratta appunto della Metodologia Agile (o sviluppo agile del software, in inglese agile software development, abbreviato in ASD) ed è la risposta alle nuove sfide di un’epoca in cui l’incertezza è dominante ed il cambiamento avviene in modo sempre più veloce e imprevedibile.
Ma che cos'è la Metodologia Agile?
In pratica, si tratta di un insieme di buone regole di project management per gestire al meglio i rischi connessi alle variazioni in corso d’opera di un progetto. Ma se la vediamo da un punto di vista più ampio, è un vero e proprio approccio metodologico che permette alle organizzazioni di ogni dimensione di rispondere adeguatamente ai cambiamenti, senza venirne travolti, ma anzi, sfruttandoli come vantaggio competitivo.
Da cosa nasce?
Nel 2001 un gruppo di sviluppatori e project manager si riunì nello Utah per cercare una risposta ad un problema all’epoca nuovo e complesso. Erano gli anni della new economy, la nascente industria moderna dello sviluppo software si stava ingrandendo a ritmi veloci e serrati, e spinta da questo vento d’innovazione, il digitale ed il web stavano iniziando ad essere considerati dalle aziende come asset di primaria importanza.
Tuttavia, era tutto nuovo e pochi sapevano ancora muoversi efficacemente in questi nuovi territori digitali, ma ciò che apparve subito chiaro era che le classiche metodologie per lo sviluppo di software non potevano più funzionare in questo nuovo scenario, in cui i mutamenti tecnologici e di mercato avvenivano a ritmi fino ad allora inediti.
Quali erano le criticità della vecchia metodologia?
Fino a quel momento il software si sviluppava “a cascata” (Waterfall Metodology): ad inizio progetto si definiva una lista ordinata e precisa delle funzionalità del software, basata su analisi anch'esse precedenti all'avviamento della fase di sviluppo. Su questa lista di funzionalità venivano quindi basate le caratteristiche tecniche, i tempi di lavorazione ed i costi.
Il problema – che divenne subito chiaro in quegli anni – è che questo approccio funziona solo quando si lavora in un contesto a basso livello di cambiamento e di innovazione. Se il contesto non cambia, le richieste di requisiti e funzionalità definite ad inizio progetto saranno ancora valide alla consegna del software, ma se il contesto è cambiato, se i modelli di business sono cambiati, se le normative ed il mercato sono cambiati, è molto probabile che il prodotto software appena consegnato risulti già obsoleto.
Se estendiamo questa situazione ad altri contesti, appare chiaro che oggi questo problema non riguarda solo lo sviluppo software. Praticamente ogni pianificazione aziendale può essere messa in discussione – già nelle prime fasi di applicazione – da una variazione strutturale dello scenario (un’evoluzione tecnologica, ad esempio) oppure non prevista (una crisi economica o climatica, un cambiamento sociale o politico, un’epidemia, una crisi di reputazione, una variazione normativa, etc.).
Un altro rischio della Metodologia Waterfall riguarda la misurazione del valore. La qualità di un progetto viene infatti definita sulla rispondenza ai requisiti iniziali, e non viene considerato il valore che quel prodotto porta al contesto per il quale è stato creato. In altre parole, ci si ritrova a considerare buono un software (o una scelta manageriale, ad esempio) solo perché funziona bene sulla base di funzioni e logiche precedentemente definite, ma che non è detto siano ancora valide. Viene da sé che questo approccio considera come negativa ogni variazione di scenario, e la conseguenza è una grave e bassa risposta ai mutamenti di mercato ed un basso livello competitivo per l’organizzazione.
In che modo un approccio Agile può risolvere queste problematiche?
Alla fine di quell'incontro, i 17 informatici riuniti nello Utah non definirono un vero e proprio framework per la gestione di progetti (di sviluppo software), ma tirarono fuori un Manifesto che in seguito fu definito Manifesto della Metodologia Agile, che offre delle linee guida per una buona e moderna gestione dei progetti in un contesto in continuo mutamento. Il manifesto recita:
“Gli individui e le interazioni
più che i processi e gli strumenti.
Il software funzionante
più che la documentazione esaustiva.
La collaborazione col cliente
più che la negoziazione dei contratti.
Rispondere al cambiamento
più che seguire un piano.
Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.”
Continua a leggere: La Metodologia Agile: tutto quello che c’è da sapere – parte 2
