Articles

Waterfall vs. Agile: qual è la metodologia di sviluppo giusta per il tuo progetto?,

Posted by admin
Scritto da Maria Lotzon luglio 5, 2018

Una delle prime decisioni che abbiamo di fronte per ogni nostro progetto implementazioni a Segue è “Quale metodologia di sviluppo dovremmo usare?”Questo è un argomento che ottiene un sacco di discussione (e spesso acceso dibattito)., Se questo non è qualcosa con cui hai lavorato prima, una definizione di metodologia di sviluppo è in ordine; in parole molto semplici, è un modo di organizzare il lavoro di sviluppo del software. NON si tratta di uno stile di gestione del progetto o di un approccio tecnico specifico, anche se si sente spesso questi termini tutti gettati insieme o usati in modo intercambiabile.

Le due metodologie di base più popolari sono:

  1. Waterfall: (ugh, nome terribile!,), che potrebbe essere più propriamente chiamato approccio “tradizionale”, e
  2. Agile: un tipo specifico di sviluppo rapido di applicazioni e più recente di Waterfall, ma non così nuovo, che viene spesso implementato usando Scrum.

Entrambi sono utilizzabili, metodologie mature. Essendo stato coinvolto in progetti di sviluppo software per lungo tempo, ecco i miei pensieri sui punti di forza e di debolezza di ciascuno.

La metodologia Waterfall

Waterfall è un approccio lineare allo sviluppo del software., In questa metodologia, la sequenza di eventi è qualcosa come:

  1. Raccogliere e documentare i requisiti
  2. Design
  3. Codice e test di unità
  4. Eseguire il test del sistema
  5. Eseguire user acceptance test (UAT)
  6. Correzione di eventuali problemi
  7. Consegnare il prodotto finito

In una vera Cascata di sviluppo del progetto, ognuno di questi rappresenta un ciclo di sviluppo software, e ogni fase generalmente termina prima che il prossimo può iniziare., C’è anche in genere un cancello di fase tra ciascuno; ad esempio, i requisiti devono essere rivisti e approvati dal cliente prima che la progettazione possa iniziare.

Ci sono cose buone e cattive sull’approccio a cascata. Sul lato positivo:

  • Sviluppatori e clienti concordano su ciò che verrà consegnato all’inizio del ciclo di vita dello sviluppo. Questo rende la pianificazione e la progettazione più semplice.
  • Il progresso è più facilmente misurato, poiché l’intero ambito del lavoro è noto in anticipo.,
  • Durante tutto lo sforzo di sviluppo, è possibile che vari membri del team siano coinvolti o continuino con altri lavori, a seconda della fase attiva del progetto. Ad esempio, gli analisti aziendali possono conoscere e documentare ciò che deve essere fatto, mentre gli sviluppatori stanno lavorando su altri progetti. I tester possono preparare script di test dalla documentazione dei requisiti mentre la codifica è in corso.
  • Ad eccezione di recensioni, approvazioni, riunioni di stato, ecc., una presenza di cliente non è richiesta rigorosamente dopo la fase di requisiti.,
  • Poiché la progettazione è completata all’inizio del ciclo di vita dello sviluppo, questo approccio si presta a progetti in cui più componenti software devono essere progettati (a volte in parallelo) per l’integrazione con sistemi esterni.
  • Infine, il software può essere progettato completamente e con più attenzione, sulla base di una comprensione più completa di tutti i deliverable software., Ciò fornisce una migliore progettazione del software con meno probabilità di “effetto frammentario”, un fenomeno di sviluppo che può verificarsi quando pezzi di codice vengono definiti e successivamente aggiunti a un’applicazione in cui possono o non possono adattarsi bene.

Ecco alcuni problemi che abbiamo riscontrato utilizzando un approccio a cascata pura:

  • Un’area che quasi sempre è inferiore è l’efficacia dei requisiti. Raccogliere e documentare i requisiti in modo significativo per un cliente è spesso la parte più difficile dello sviluppo del software, a mio parere., I clienti sono a volte intimiditi dai dettagli e dettagli specifici, forniti all’inizio del progetto, sono richiesti con questo approccio. Inoltre, i clienti non sono sempre in grado di visualizzare un’applicazione da un documento dei requisiti. Wireframe e mockup possono aiutare, ma non c’è dubbio che la maggior parte degli utenti finali abbia qualche difficoltà a mettere insieme questi elementi con i requisiti scritti per arrivare a una buona immagine di ciò che otterranno.,
  • Un altro potenziale svantaggio dello sviluppo di pure Waterfall è la possibilità che il cliente sia insoddisfatto del prodotto software consegnato. Poiché tutti i deliverable sono basati su requisiti documentati, un cliente potrebbe non vedere cosa verrà consegnato fino a quando non sarà quasi finito. A quel punto, i cambiamenti possono essere difficili (e costosi) da implementare.

La metodologia Agile

Agile è un approccio iterativo allo sviluppo basato sul team. Questo approccio enfatizza la rapida consegna di un’applicazione in componenti funzionali completi., Piuttosto che creare attività e pianificazioni, tutto il tempo è “time-boxed” in fasi chiamate “sprint.”Ogni sprint ha una durata definita (di solito in settimane) con un elenco di risultati finali, pianificato all’inizio dello sprint. I risultati finali sono prioritari in base al valore aziendale determinato dal cliente. Se tutto il lavoro pianificato per lo sprint non può essere completato, il lavoro viene ripriorizzato e le informazioni vengono utilizzate per la pianificazione futura dello sprint.

Quando il lavoro è completato, può essere rivisto e valutato dal team di progetto e dal cliente, attraverso build giornalieri e demo di fine sprint., Agile si basa su un livello molto alto di coinvolgimento del cliente durante tutto il progetto, ma soprattutto durante queste recensioni.

Alcuni vantaggi dell’approccio Agile sono facili da vedere:

  • Il cliente ha frequenti e precoci opportunità di vedere il lavoro in consegna e di prendere decisioni e cambiamenti durante tutto il progetto di sviluppo.
  • Il cliente acquisisce un forte senso di proprietà lavorando estesamente e direttamente con il team di progetto durante tutto il progetto.,
  • Se il time to market per un’applicazione specifica è una preoccupazione maggiore rispetto al rilascio di un set completo di funzionalità al lancio iniziale, Agile può produrre più rapidamente una versione base del software di lavoro che può essere costruita in iterazioni successive.
  • Lo sviluppo è spesso più incentrato sull’utente, probabilmente il risultato di una direzione sempre più frequente da parte del cliente.,
  • Per ulteriori Agile benefici in termini di Sviluppo, si prega di vedere la sezione 8 Benefici dello Sviluppo Agile del Software

E, naturalmente, ci sono alcuni svantaggi:

  • L’elevato grado di coinvolgimento del cliente, mentre grande per il progetto, può presentare problemi per alcuni clienti che semplicemente non hanno il tempo o l’interesse per questo tipo di partecipazione.
  • Agile funziona meglio quando i membri del team di sviluppo sono completamente dedicati al progetto.,
  • Poiché Agile si concentra sulla consegna in scatola e sulla riprioritizzazione frequente, è possibile che alcuni articoli impostati per la consegna non vengano completati entro il periodo di tempo assegnato. Potrebbero essere necessari ulteriori sprint (oltre a quelli inizialmente pianificati), aggiungendo al costo del progetto. Inoltre, il coinvolgimento del cliente spesso porta a funzionalità aggiuntive richieste durante tutto il progetto. Ancora una volta, questo può aumentare il tempo e il costo complessivi dell’implementazione.,
  • Le strette relazioni di lavoro in un progetto Agile sono più facili da gestire quando i membri del team si trovano nello stesso spazio fisico, cosa che non è sempre possibile. Tuttavia, ci sono una varietà di modi per gestire questo problema, come webcam, strumenti di collaborazione, ecc.
  • La natura iterativa dello sviluppo Agile può portare a un frequente refactoring se l’intero ambito del sistema non viene considerato nell’architettura e nel design intial. Senza questo refactoring, il sistema può soffrire di una riduzione della qualità complessiva., Questo diventa più pronunciato nelle implementazioni su larga scala o con sistemi che includono un alto livello di integrazione.

Fare la scelta tra Agile e Waterfall

Quindi, come scegliamo? Innanzitutto, cambiamo un po ‘ il gioco (che è ciò che fanno la maggior parte delle organizzazioni di sviluppo software) definendo il nostro processo. In Seguito, si chiama our Process Framework ed è una variazione sulla metodologia tradizionale della cascata., Le nostre modifiche includono l’uso della prototipazione, ove possibile, per fornire al cliente una migliore visione del prodotto finito all’inizio del ciclo di progettazione/sviluppo. Questo aiuta a migliorare la comprensione dei requisiti del team e la comunicazione con il cliente. Dopo che il quadro primario dell’applicazione è stato completato per requisiti di alto livello, continuiamo a sviluppare e anche a raggiungere il cliente per il perfezionamento dei requisiti. In questo modo, ci sforziamo di essere il più iterativo possibile senza compromettere la nostra architettura complessiva del sistema.,

Consideriamo i seguenti fattori quando consideriamo quale metodologia utilizzare:

I fattori di cui sopra non sono ugualmente ponderati; ciascuno è valutato in base al singolo progetto e alle circostanze.

Anche se stiamo iniziando a vedere l’adozione di massa di varie metodologie Agili in Azienda (anche DoD e agenzie federali), ci sono ancora molte organizzazioni che sono lenti a fare il cambiamento., E ‘ anche molto comune per l’organizzazione di transizione in più di un approccio Agile ibrido che combina aspetto sia Agile e cascata. La Guida pratica Agile è stata sviluppata specificamente per aiutare l’organizzazione a comprendere e valutare l’uso di approcci agili e ibridi. Il Project Management Institute (PMI) che ha sviluppato la guida PMBOK (Project Management Body of Knowledge) ha collaborato con Agile Alliance per raggruppare le due guide in un’unica offerta per aiutare organizzazioni, manager e leadership ad aumentare l’agilità nel processo di sviluppo.,

Una volta che abbiamo deciso quale metodologia di base utilizzare, possiamo perfezionare ulteriormente il processo per adattarsi al meglio ai nostri obiettivi di progetto. In definitiva, anche se il modo in cui facciamo il nostro lavoro è importante, fornire un prodotto solido e manutenibile che soddisfi il nostro cliente è ciò che conta davvero.

Leave A Comment