Qual è la differenza tra approccio agile e approccio tradizionale?

Sebbene l'approccio Agile sia spesso considerato come la scelta migliore per quanto riguarda la metodologia, quest'ultimo comporta una serie di svantaggi da prendere in considerazione prima di adottarlo, tra cui:

Se la clientela non ha tempo o interesse a lavorare a stretto contatto con il team di sviluppo, il progetto non riceverà il feedback o le informazioni necessari per andare avanti.

Se i membri del team non sono completamente impegnati a completare il progetto in modo efficace ed efficiente, l'aspetto di autogestione di Agile viene meno.

Alcune attività, o anche alcune sottoattività, possono essere troppo dispendiose in termini di tempo per essere completate durante un singolo sprint. Per risolvere questo problema, i team devono modificare le priorità o introdurre costosi sprint aggiuntivi.

La natura iterativa e incrementale di Agile non è compatibile con la governance o la supervisione dei progetti. I team che non sono in grado di autogovernarsi sono meno propensi a poter essere gestiti in modo efficace.

Il fatto che l'approccio Agile attribuisca la priorità a un software funzionante rispetto alla documentazione significa che a volte la notazione essenziale viene tralasciata. Ciò può costituire un problema, poiché la documentazione completa aiuta a rendere le implementazioni più condivisibili, identifica il pensiero dietro decisioni specifiche e consente ai team di tornare più facilmente alle fasi iniziali.

Spesso, processi aziendali, set di strumenti, policy, strutture organizzative e controlli consolidati non favoriscono l'agilità. Di conseguenza, un'implementazione Agile efficace richiede un cambiamento culturale su ampia scala in tutta l'organizzazione. Ciò può portare a un rifiuto da parte di singoli individui o reparti abituati a pratiche più tradizionali.

Descritta per la prima volta nel 1970, la metodologia tradizionale ha conosciuto un uso costante tra i team di sviluppo per circa mezzo secolo. Questo perché offre diversi vantaggi, tra cui:

La metodologia tradizionale è forse la più facile da gestire, ogni fase essendo associata a risultati finali specifici e a un chiaro processo di revisione.

Nei progetti in cui è necessario progettare più componenti per consentire l'integrazione con sistemi esterni, l'approccio tradizionale (in cui il design viene completato nelle prime fasi del processo) rappresenta un vantaggio evidente.

I requisiti del prodotto vengono documentati e concordati prima dell'inizio dello sviluppo, stabilendo un insieme di funzionalità prevedibile e concreto.

Una maggiore pianificazione e la documentazione progettata nelle fasi iniziali consentono di ottenere una panoramica chiara dei potenziali costi. Ciò consente una definizione del budget accurata.

Poiché l'intera portata di lavoro è nota in anticipo, la misurazione dei progressi diventa semplice e precisa. I progressi vengono in genere misurati nel "report di stato", dove gli elementi di lavoro relativi a pianificazione, budget e risorse sono definiti in verde, giallo o rosso.

Gli obiettivi vengono identificati e stabiliti prima dell'inizio del lavoro di sviluppo, anziché rimanere liquidi per tenere conto delle esigenze in continua evoluzione.

I membri del team hanno la larghezza di banda necessaria per lavorare ad altri progetti e devono dedicare il proprio tempo al progetto solo durante le fasi designate.

Le metodologie tradizionali creano un'esperienza che richiede un minor intervento da parte della clientela; il coinvolgimento dell'utente finale non è necessario, tranne durante le fasi relative ai requisiti e alla revisione.

Ponendo maggiore attenzione alla pianificazione e alla documentazione, i progetti seguono un percorso stabilito, sono più facili da rivedere e i risultati sono più chiaramente identificabili.

La crescita conosciuta dall'approccio agile attesta la presenza di alcuni inconvenienti nella metodologia tradizionale. Questi svantaggi comprendono:

Poiché la metodologia tradizionale si affida a una pianificazione dettagliata nelle fasi iniziali, i progetti che presentano problemi imprevisti, ostacoli o esigenze in continua evoluzione potrebbero non essere in grado di adattarsi. Analogamente, la metodologia tradizionale procede in una sola direzione e potrebbe essere impossibile o molto difficile tornare alle fasi precedenti per apportare modifiche.

I requisiti definiti in modo rigido lasciano pochissimo spazio per l'ispirazione, l'innovazione o la creatività e possono impedire ai team di sviluppo di sfruttare opportunità inaspettate durante le fasi di sviluppo.

Essendo meno coinvolta nei processi di sviluppo, la clientela potrebbe sentirsi tagliata fuori dal processo. Ancora più problematico è forse il fatto che la clientela potrebbe non essere consapevole di ciò che verrà consegnato fino al completamento del progetto. D'altra parte, il team di sviluppo stesso potrebbe non sapere quali siano le aspettative della clientela riguardo al risultato, ampliando ulteriormente il divario. Inoltre, poiché i controlli vengono eseguiti solo alla fine del progetto, è più probabile che si presentino bug e problemi di UX.

Scadenze non chiare per fasi specifiche possono portare a ritardi nel completamento dei progetti. A volte, i team accelerano le ultime fasi, tra cui quelle relative ai controlli. Ciò può portare a prodotti di qualità inferiore.

I requisiti devono essere chiaramente identificati e approvati prima di iniziare qualsiasi lavoro. In caso contrario, i singoli membri del team possono interpretare i requisiti in modo diverso, portando a una mancanza di coordinazione.

Con così tanto impegno nella pianificazione e nella documentazione, sono disponibili meno risorse per la realizzazione effettiva dei prodotti.

I progetti che presentano requisiti rigorosi sono più adatti alla metodologia tradizionale, mentre un numero inferiore di requisiti e di normative consente a quella agile di mettere in evidenza creatività e libertà.

Processi rigorosi rendono l'implementazione della metodologia agile molto difficile e traggono maggior vantaggio da un approccio tradizionale. Agile è più efficace quando i processi sono più flessibili.

La metodologia tradizionale è efficace quando clienti, utenti finali e proprietari o proprietarie di prodotti non sono interessati/e a lavorare a stretto contatto con il team di sviluppo. Le persone che desiderano un maggiore coinvolgimento trarranno il massimo vantaggio dall'approccio agile.

L'ottimizzazione dei progetti esistenti, in cui le funzionalità sono già ben definite e le integrazioni sono state stabilite, trae vantaggio dall'approccio tradizionale. Se il progetto è innovativo e si desidera provare a realizzare qualcosa che non è ancora stato fatto, l'approccio iterativo della metodologia agile consente ai team di imparare e adattarsi man mano che procedono.

La metodologia tradizionale stabilisce un risultato prevedibile e lavora bene con scadenze ben definite e progetti di lunga durata. Scadenze più brevi e più flessibili si adattano meglio all'approccio agile.

La prevedibilità della metodologia tradizionale è anche adatta a budget poco flessibili, in cui ogni azione e spesa deve essere documentata nelle prime fasi del processo. La metodologia agile richiede meno rigidità nella definizione del budget, concentrandosi sulle caratteristiche e sulla velocità di sviluppo e non assumendo una posizione così rigida rispetto ai costi.

I progetti più piccoli e ben definiti sono spesso più adatti alla metodologia tradizionale. I progetti più grandi e complessi traggono vantaggio dall'approccio agile.

Quando ci si coordina con personale remoto o si collabora con altre organizzazioni, la ridotta necessità di collaborazione presenziale della metodologia tradizionale fa sì che quest'ultima si riveli una scelta migliore. Se invece il progetto è nelle mani di un'unica organizzazione e i membri del team si trovano tutti nello stesso luogo, l'approccio agile è più efficace.