La metodologia Agile e il contesto industriale attuale

Agile
Scritto da Alberto Bonfini

Tempo di lettura: 10 minuti

Nel medioevo l’economia era di tipo artigiano, pensatori e costruttori erano la stessa persona quindi non solo si doveva sapere (inteso come conoscenza della scienza e della tecnica) ma anche saper fare (inteso come abilità manuale, pratica per la realizzazione di manufatti). Il progresso tecnologico era quindi limitato da queste due variabili e dalla necessità che fossero fortemente sviluppate nella stessa persona.

Dapprima l’introduzione delle macchine, poi, lo sviluppo dell’industria e, da ultimo, lo sviluppo di processi automatici, hanno portato al periodo denominato Terza Rivoluzione Industriale (temporalmente collocabile alla fine del XX secolo). Nei secoli passati fino a questo momento, si è assistito ad un’importante verticalizzazione delle conoscenze nei diversi ambiti del sapere. I ruoli di chi sa e di chi sa fare si sono sempre più separati e la specializzazione domina il mercato di lavoro (fenomeno al quale possiamo assistere anche ai giorni nostri).

Attualmente, però, siamo all’interno della Quarta Rivoluzione Industriale, periodo nel quale si presenta una sempre più forte convergenza di tecnologie digitali, fisiche e biologiche. Progettazione tridimensionale, robotica avanzata, tecnologia di produzione additiva, gemelli digitali, personalizzazione di massa dei prodotti e, da ultimo, il forte sviluppo nell’ambito dell’intelligenza artificiale sono tra gli elementi che stanno accompagnando una nuova (e forte) spinta creatrice che sta riavvicinando costruttori e pensatori. I due ruoli non potranno mai più coincidere ma potranno (e dovranno) operare sempre più a stretto contatto, all’interno dello stesso team, sfruttando al meglio queste nuove tecnologie come una vera e propria protesi del pensiero (oltre che delle braccia) umane.

L’attuale contesto industriale

L’attuale contesto industriale può essere definito utilizzando l’acronimo VUCA; questa sigla viene usata per identificare una realtà in rapida evoluzione e altamente sfidante. In particolare:

  • Volatilità (volatility): velocità e natura imprevedibile dei cambiamenti che si verificano nell’ambiente circostante; cambiamenti che possono avere impatti rilevanti sulle condizioni esistenti;

  • Incertezza (uncertainty): mancanza di chiarezza riguardo a eventi futuri e possibili conseguenze; l’instabilità e la mutevolezza rendono difficile l’effettuare previsione soddisfacenti;

  • Complessità (complexity): presenza di molteplici variabili e fattori a definire un singolo fenomeno; questo rende di difficile interpretazione la situazione nella quale ci si trova;

  • Ambiguità (ambiguity): mancanza di chiarezza e univocità riguardo al significato di determinate situazioni e condizioni.

A seguito della pandemia del 2020, però, alcuni studiosi come Jamais Cascio hanno identificato un nuovo acronimo per definire il contesto odierno ossia BANI (brittle, anxious, onlinear, incomprehensibile). Richiamando le parole usate da Casio in “Facing the age of chaos”, si tratta di

un quadro di riferimento per articolare le situazioni sempre più comuni in cui la semplice volatilità o la complessità sono lenti insufficienti per comprendere ciò che sta accadendo. Situazioni in cui le condizioni non sono semplicemente instabili, ma caotiche. In cui gli esiti non sono semplicemente difficili da prevedere, ma completamente imprevedibili. O, per usare il linguaggio particolare di questi framework, situazioni in cui ciò che accade non è semplicemente ambiguo, ma incomprensibile.

Nonostante questo quadro di forte incertezza, i progetti stanno via via sostituendo le operations come motore economico della nostra epoca ma, proprio a causa di questa forte incertezza, solo il 35% dei progetti che vedono la luce riscontrano poi il successo atteso (o qualcosa di più). Questo vuol dire che (circa) il 65% delle risorse impiegate nel mondo industriale vengono disperse per inefficienze di varia natura che non permettono ai progetti di venire alla luce.

La domanda da porsi è quindi “come possiamo gestire al meglio i progetti così da non sprecare tempo e risorse preziose nonostante tutte le difficoltà portate dall’attuale contesto socio-economico-politico?”

Come gestire al meglio i progetti?

Prima di addentrarci in considerazioni più specifiche sugli argomenti che verranno affrontati anche in altri articoli di questa sezione, cerchiamo di fare chiarezza su alcuni concetti. Con la parola progetto si intende un’iniziativa limitata nel tempo che ha lo scopo di creare un prodotto o portare un risultato che si contraddistingue per il suo carattere unico. Il progetto ha un inizio e una fine e può essere collegato o meno ad altre attività di un’azienda. Il Project Manager è la persona che viene incaricata di guidare il gruppo di progetto con l’obiettivo di portarlo a realizzare il prodotto finale desiderato. La possibilità o meno di raggiungere un determinato obiettivo è sicuramente dettata dalle capacità del Project Manager, ma anche dalle tecniche che, assieme al gruppo di progetto, egli decide di utilizzare per ottenere quel determinato risultato. Il gruppo di progetto è, infine, l’insieme di persone che collabora per raggiungere un obiettivo comune in grado di generare valore (in termini di significatività, importanza e utilità del prodotto o servizio realizzato) per gli stakeholders che hanno commissionato il progetto.

Gli approcci principalmente adottati da un Project Manager possono essere definiti secondo tre tipologie: waterfall, agile o ibridi. Esistono poi diversi gradi di ibridazione, argomento che non approfondiremo in questo articolo. Qui analizzeremo solo i due estremi “puri”.

Waterfall

L'approccio Waterfall, o a cascata, è un modello tradizionale e sequenziale utilizzato per gestire i progetti. Questo metodo prevede che le attività siano suddivise in fasi distinte e che ogni fase debba essere completata prima di passare alla successiva, seguendo un flusso sequenziale simile, appunto, ad una cascata.

Le fasi principali della gestione dei progetti secondo un la metodologia Waterfall sono:

  1. Analisi e pianificazione: in questa fase, vengono definiti i requisiti del progetto, stabiliti gli obiettivi e pianificato il lavoro. Si svolge un'analisi dettagliata per identificare le esigenze del cliente e stabilire i requisiti del progetto;

  2. Progettazione: dopo aver stabilito i requisiti, si passa alla progettazione del sistema o del prodotto. Si creano specifiche dettagliate e si elabora l'architettura del progetto in base ai requisiti stabiliti;

  3. Sviluppo: durante questa fase, avviene la vera e propria creazione del prodotto o sistema in base ai piani e alle specifiche definite nella fase di progettazione;

  4. Test: una volta completata la fase di sviluppo, si procede con i test per verificare che il prodotto soddisfi i requisiti stabiliti. Vengono eseguiti test di funzionalità, integrazione e altri test pertinenti per garantire la qualità del prodotto;

  5. Implementazione e manutenzione: dopo aver superato i test, il prodotto viene implementato e reso disponibile per l'utilizzo da parte degli utenti finali. Successivamente, potrebbe essere necessario fornire manutenzione continua e correzioni di eventuali problemi riscontrati.

Una delle principali caratteristiche dell'approccio Waterfall è la sua struttura lineare e sequenziale, che richiede un avanzamento unidirezionale attraverso le fasi del progetto. Tuttavia, questa metodologia presenta alcune limitazioni. Ad esempio, è difficile tornare indietro alle fasi precedenti una volta che sono state completate, rendendo complicato gestire cambiamenti o nuove esigenze che possono emergere durante lo sviluppo del progetto.

Pratiche più moderne come la metodologia Agile (declinata nei suoi vari frameworks) sono state sviluppate per superare queste limitazioni, offrendo maggiore flessibilità e adattabilità alle mutevoli esigenze dei progetti complessi.

Agile

L’approccio Agile alla gestione di progetti vede la sua origine nella stesura dell’Agile Manifesto, documento redatto pensando al mondo software, nel quale vengono definiti i seguenti valori fondamentali:

  1. Individui e interazione più che processi e strumenti;

  2. Software (leggasi anche prodotto) funzionante più che una documentazione esaustiva;

  3. Collaborazione con i clienti più che negoziazione dei contratti;

  4. Risposta al cambiamento più che seguire un piano.

Come è possibile notare, il Manifesto pone in relazione elementi, mettendo in risalto ciò che ogni progettista agile deve valorizzare. Gli elementi di paragone, ai quali è pur riconosciuta importanza, devono essere necessariamente messi in secondo piano nel momento in cui si vede aumentare la complessità del progetto che si deve portare avanti.

I 4 valori fondamentali vengono poi declinati nei 12 principi riportati di seguito:

  1. La nostra più grande priorità è quella di soddisfare il cliente fornendogli presto e in maniera continua incrementi che portino valore al software;

  2. Accogliere il cambiamento di requisiti anche se in stadi avanzati dello sviluppo. I processi Agile imbrigliano il cambiamento al fine di garantire un vantaggio competitivo per il cliente;

  3. Rilasciare frequentemente parti di software funzionante, da un paio di settimane ad un paio di mesi, con la preferenza di tempistiche ridotte;

  4. Persone di business e sviluppatori devono lavorare insieme quotidianamente lungo tutta la durata del progetto;

  5. Costruite progetti attorno ad individui motivati. Date lor l’ambiente, il supporto che cercano e credete in loro affinché possano svolgere il lavoro loro assegnato;

  6. Il metodo più efficace ed efficiente per far giungere un’informazione a membri del team di progetto è la conversazione faccia-a-faccia;

  7. La prima misura del progresso è un software funzionante;

  8. I processi agile promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti devono essere in grado di mantenere un ritmo costante indefinitamente;

  9. Una continua attenzione all’eccellenza tecnica e alla buona progettazione esalta l’agilità;

  10. Semplicità – l’arte di massimizzare il lavoro non fatto – è essenziale;

  11. Le migliori architetture, requisiti e design emergono da gruppi che si auto-organizzano;

  12. Ad intervalli regolari, il gruppo riflette su come diventare più efficiente, quindi aggiusta i suoi comportamenti in accordo con ciò.

L’enfasi è data, quindi, soprattutto alle persone che svolgono il progetto in questione più che al piano di progetto. Il cliente è una parte attiva del gruppo di lavoro e, in quanto tale, deve sempre essere aggiornato e deve poter condividere le sue proposte in merito al progetto. Queste idee saranno la base di futuri (e non inizialmente prevedibili) sviluppi che potranno essere implementati nel prodotto finale grazie a continui cicli di valutazione del lavoro svolto.

Un altro elemento al quale si dà risalto è la necessità di compiere frequenti riunioni in modo che tutto il team di progetto e gli stakeholder siano sempre allineati sulle novità e confermino la bontà del lavoro svolto in precedenza. Come dice il decimo principio, infatti, è essenziale massimizzare il lavoro non fatto e la possibilità di incomprensioni è la più grande nemica di questo obiettivo.

Le “buone pratiche” presentate e l’abilità nella gestione dei rapporti personali, però, non sono nulla se non accompagnati, ovviamente, da un buon prodotto correttamente funzionante e in grado di soddisfare a pieno le necessità del cliente. Quest’ultimo, infatti, deve essere l’obiettivo principale di ogni progetto sennò si andrà in contro solo ad uno spreco di risorse e ad un sicuro fallimento del progetto.

Per quanto in tutte le fasi decisionali si possano commettere errori di valutazione, è bene essere pronti ad accettare il fallimento e bloccare alcuni progetti senza portarli avanti per la sola motivazione che “si è già investito molto”. Il confronto continuo con il cliente e con tutti gli stakeholders che orbitano attorno al progetto è uno di quei validi strumenti che possono aiutare nell’annusare i progetti per capire se realmente possano (o meno) essere portati avanti.

Conclusioni

L’approccio classico di sviluppo di un progetto vede, quindi, la scomposizione in elementi più piccoli che vengono realizzati uno dopo l’altro (in sequenza) come avviene con l’acqua che scorre in una cascata. Riuscire a realizzare in parallelo più fasi di sviluppo (unitamente ad un approccio iterativo tipico di pratiche come lo Scrum) porta a definire due diverse tempistiche di realizzazione del progetto. Questa differenza temporale permette di definire un costo del ritardo che dovrà essere confrontato con i costi portati dalla realizzazione in parallelo di più attività per capire così quale dei due approcci sia il migliore per ogni caso specifico.

Il cambio di mentalità unito all’aumento del commitment nei confronti del progetto costituiscono la motivazione emotiva dietro al cambiamento di approccio. La valutazione del costo del ritardo, invece, definisce la dimensione tecnico-economica nel passaggio da metodi di gestione dei progetti più tradizioni a quelli definiti agili.

Come detto, però, le metodologie agili non sono nemiche di quelle tradizionali che mettono in risalto l’importanza di piani, documentazione, processi e contratti e devono essere considerati utili strumenti per realizzare un prodotto che sia sempre migliore in un contesto, non solo legato al mondo IT, sempre più turbolento e in continua evoluzione. Il Project Management tradizionale non è (e non deve essere) nemico dell’Agile Project Management.

Alberto Bonfini https://albertobonfini.com
Indietro

La mentalità Agile