Qual è la differenza tra approccio agile e approccio tradizionale?

Agile e "a cascata" (anche detto tradizionale) sono due metodologie di sviluppo: quello agile utilizza un approccio iterativo, mentre quello tradizionale è sequenziale.

Quando si avvia un nuovo progetto, programma o prodotto, i/le project manager devono prendere decisioni sul tipo di metodologia di consegna da utilizzare. Un metodo di consegna è essenzialmente un framework: un processo o una serie di processi utilizzati per facilitare la pianificazione organizzata, lo sviluppo, l'esecuzione, la riparazione, il monitoraggio, e la revisione del lavoro. Due delle metodologie più ampiamente utilizzate oggi sono il framework tradizionale e il nuovo approccio agile. Un terzo approccio, che combina metodi di lavoro tradizionali e agili, sta conoscendo inoltre uno sviluppo diffuso.

L'approccio Agile è una metodologia iterativa di sviluppo di software il cui obiettivo è la collaborazione tra team interfunzionali e in grado di organizzarsi in modo autonomo. Scopri di più sull'approccio Agile.

L'approccio Agile evita il tradizionale approccio "una fase alla volta", in cui le risorse allocate eseguiranno attività specifiche prima di passare il progetto alla fase successiva o alle risorse assegnate. Ci si affida invece a team dedicati in grado di operare in modo collaborativo e simultaneo. Questi team eseguono le attività contemporaneamente, eliminando la necessità di attendere il completamento delle attività, e sono inoltre in grado di affrontare facilmente esigenze mutevoli o problemi emergenti.

Come menzionato in precedenza, l'approccio Agile è iterativo, supporta continue release e suddivide il lavoro in più sequenze di cicli ripetuti, chiamati iterazioni. In questo modo, si fornisce all'utente finale valore in modo continuo, anziché tutto in una volta al completamento del progetto. L'approccio Agile svolge un ruolo chiave nella consegna continua e nel miglioramento continuo.

Metodologia Agile - ServiceNow

Sebbene team diversi possano adottare un approccio Agile in diversi modi, quest'ultimo rispetta sempre i seguenti principi fondamentali:

  • Adattabilità
    I progetti Agile devono avere la flessibilità necessaria per cambiare architettura, progettazione, risultati finali, requisiti e altri elementi nel corso del progetto.
  • Sviluppo snello
    Agile adotta l'approccio più semplice allo sviluppo, eliminando i passaggi superflui o ridondanti.
  • Lavoro di squadra
    L'approccio Agile dipende da un lavoro di squadra e da una comunicazione efficaci, consentendo il completamento di più attività contemporaneamente.
  • Coinvolgimento della clientela
    Le iterazioni Agile offrono valore in incrementi, rendendo possibile collaborare con la clientela per introdurre nuove idee ed effettuare revisioni sui prodotti.
  • Sostenibilità
    Agile pone l'accento sulla creazione di un ritmo di sviluppo costante e sostenibile per fornire valore alla clientela in base ai risultati, anziché affaticare i team concentrati sugli output.
  • Tempo
    Il tempo dedicato ai progetti Agile è suddiviso in sprint, piccole unità di tempo in cui vengono completate e poi riesaminate attività specifiche.
  • Controlli
    I test di controllo vengono eseguiti in ogni fase del progetto Agile, evitando di dover attendere che l'intero progetto sia completato.

Dalla sua introduzione all'inizio degli anni 2000, Agile ha acquisito una notevole popolarità. I vantaggi della metodologia Agile includono:

Pianificazione prevedibile

Gli sprint predefiniti consentono di fornire nuove funzionalità in modo rapido e prevedibile. Inoltre, il beta test può essere eseguito prima di quanto sarebbe altrimenti possibile.

Autonomia del team

L'attenzione di Agile si focalizza sulla semplicità e sulla collaborazione, offrendo ai team una libertà senza precedenti per quanto riguarda l'organizzazione autonoma e le decisioni cruciali.

Flessibilità

L'autonomia data dall'approccio Agile offre ai team la flessibilità di scegliere i metodi e le tecniche più adatti al risultato desiderato. Allo stesso tempo, i progetti stessi diventano più adattabili, poiché elementi di backlog nuovi o modificati possono essere introdotti durante lo sviluppo. I primi beta test forniscono inoltre un feedback essenziale utilizzabile dai team di sviluppo per apportare modifiche importanti.

Comunicazione più efficace

L'approccio Agile dipende dalla capacità di un team di comunicare in modo efficace, sia internamente che esternamente. Si enfatizza la direzionalità e la chiarezza, assicurando una comunicazione regolare e presenziale.

Maggiore attenzione al valore di business

Nella metodologia Agile, è la clientela o l'utente finale a determinare la priorità delle funzionalità. In questo modo, i team di sviluppo possono capire chiaramente quali caratteristiche offrono il miglior valore al business.

Maggiore attenzione alla clientela

Quando si trovano di fronte a scadenze strette e a obiettivi a lungo termine complessi, i team di sviluppo possono facilmente perdere di vista l'importanza della clientela. L'approccio Agile riallinea questo obiettivo, utilizzando le esigenze della clientela e altri feedback dell'utente come base per il miglioramento dei prodotti. Ciò comporta non solo un aumento della soddisfazione della clientela, ma anche un miglioramento dei rendimenti.

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:

Richiede un elevato grado di coinvolgimento da parte della clientela

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.

Richiede la totale dedizione del team

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.

Potrebbe non prevedere abbastanza tempo per soddisfare tutti i risultati finali

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.

Non consente una governance completa

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.

Vi è poca documentazione

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.

Richiede l'adozione di una certa cultura

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.

Con il suo approccio più tradizionale allo sviluppo, è una metodologia lineare e sequenziale che divide il ciclo di vita dello sviluppo di software in fasi distinte, in cui la fase successiva può essere avviata solo se la fase precedente è stata completata.

In qualità di metodologia di sviluppo più antica, quella tradizionale è semplice da utilizzare e da comprendere e dipende in larga misura dalla progettazione iniziale del lavoro, dalla ricerca, dalla documentazione e dalla pianificazione. Si tratta di un approccio "misura due volte, taglia una volta sola": tutti i requisiti del progetto sono chiaramente definiti all'inizio del progetto e viene in seguito creato un piano dettagliato per soddisfare tali esigenze.

Quali sono le fasi della metodologia tradizionale?

La metodologia di sviluppo tradizionale suddivide i progetti in sette fasi distinte. Ciascuna di queste fasi è indipendente dalle altre; in genere, una nuova fase non può iniziare prima del completamento della fase precedente. Inoltre, la maggior parte delle fasi è separata da un "gate di fase" che rappresenta una serie di requisiti da completare, nonché le decisioni di gestione che devono essere prese prima che il progetto possa passare alla fase successiva. Le fasi sono le seguenti:

  • Concezione
    I team di sviluppo iniziano valutando il progetto in entrata, inclusi i vantaggi e i potenziali costi.
  • Documentazione
    Si raccolgono e documentano i requisiti di sistema e del software, nonché le altre risorse per il progetto.
  • Analisi e progettazione
    I team analizzano il progetto e definiscono in che modo desiderano che il prodotto o il servizio funzioni; si identifica e pianifica il lavoro essenziale.
  • Codifica e controllo dell'unità
    La codifica ha inizio per ciascuna unità del software, con controlli eseguiti lungo il percorso. Le unità sono integrate nell'architettura del software definita nelle fasi precedenti.
  • Controlli a livello di sistema
    Vengono eseguiti controlli a livello del sistema, inclusi i test per il rilevamento di bug e i test di accettazione utente (UAT, User Acceptance Testing), nonché altri controlli essenziali.
  • Risoluzione dei problemi
    Si risolvono e correggono i bug, le inefficienze e i problemi identificati nella fase precedente.
  • Consegna
    Il prodotto o il servizio finito viene distribuito all'utente finale.

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:

Pianificazione e progettazione semplici

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

Design migliore con approccio all'intero sistema

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.

Portata di lavoro chiaramente definita

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

Proiezione dei costi più accurata

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.

Chiaro controllo dell'avanzamento

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.

Ruoli del team ben definiti

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

Carico condiviso

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.

Indipendenza del progetto rispetto alla clientela

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.

Documentazione completa

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:

Utilizza una struttura rigida

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.

Non consente incertezze

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.

Può portare all'insoddisfazione della clientela

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.

Posticipa i controlli alle fasi finali

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.

Richiede requisiti chiari già nelle fasi iniziali

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.

Si concentra sulla documentazione a discapito della costruzione

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

Agile e tradizionale presentano entrambe vantaggi e svantaggi. Tenendo presente questo aspetto, comprendere i casi di utilizzo specifici per entrambe le opzioni può aiutare le organizzazioni a scegliere le metodologie più adatte per ogni progetto.

Quando si prendono queste decisioni, si consideri quanto segue:

Requisiti

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à.

Agile e tradizionale a confronto - ServiceNow

Requisiti

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 esistenti

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.

Coinvolgimento dell'utente

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.

Progetti esistenti o innovativi

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.

Sequenza temporale

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.

Budget

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.

Dimensioni e complessità del progetto

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.

Fattori organizzativi

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.

Poiché offrono entrambi vantaggi significativi, le aziende di tutto il mondo sono alla ricerca di modi per combinare questi vantaggi, limitando al contempo i loro svantaggi. Ne risulta una gestione ibrida dei progetti.

La gestione ibrida dei progetti riunisce i due approcci per creare una soluzione che ottimizzi i tempi, le risorse e la soddisfazione dell'utente.

Scopri di più su ServiceNow ITBM

Crea più valore con una strategia di IT e aziendale allineata utilizzando la nostra soluzione scalabile ITBM.