La metodologia di sviluppo del software Waterfall è ancora praticabile?

Nella mia esperienza, sembra che il modello Waterfall abbia dimostrato di essere troppo inflessibile e non rispondente alle modifiche dei requisiti per essere considerato un metodo praticabile nel moderno mondo dello sviluppo del software. La crescita e la comprovata esperienza di metodi più agili e iterativi sembrano indicare che non vi è alcun motivo per cui qualcuno dovrebbe seguire un processo di blocchi rigidi che presuppone cambiamenti minimi o nulli dall'avvio del progetto alla consegna del prodotto.

La metodologia di sviluppo della cascata è ancora praticabile per la fornitura di sistemi software, in termini di tempo, costi e qualità?

Il modello a cascata a cui ti riferisci non è mai stato inteso come un modello di processo utilizzato in un progetto reale. Invece, è un pagliaccio. Identifica le fasi e le attività chiave esistenti nei progetti software e il flusso più basilare tra di essi. Questa semplificazione eccessiva di come sviluppare software è imperfetta, e fu persino presentata in quel modo.

Dall'articolo di Wikipedia:

La prima descrizione formale del modello a cascata è spesso citata come un articolo del 1970 da Winston W. Royce, sebbene Royce non abbia usato il termine "cascata" in questo articolo. Royce ha presentato questo modello come esempio di un modello difettoso e non funzionante.

L'articolo discusso si intitola Gestione dello sviluppo di grandi sistemi software . In esso, Royce presenta quel modello nella seconda pagina. Tuttavia, il testo immediatamente sotto la rappresentazione pittorica continua a leggere:

Credo in questo concetto, ma l'implementazione sopra descritta è rischiosa e invita al fallimento.

Segue una discussione sui problemi con i test a seguito del "completamento" della fase di sviluppo e su come i fallimenti qui possono portare a importanti riprogettazioni e modifiche al codice e come questi possono portare a grandi sovraccarichi di costi e pianificazione. In tutto il documento, affina il modello originale a uno che è effettivamente praticabile su un progetto. Alla fine, finisce con un modello che introduce la prototipazione, l'interazione con il cliente e il perfezionamento dei manufatti - idee che alla fine sarebbero diventate fondamentali per il movimento agile iniziato alla fine degli anni '90 e all'inizio degli anni 2000.

Per rispondere alla tua domanda: The Waterfall di cui stai chiedendo non è, e non è mai stato, un metodo praticabile per fornire progetti software con una ragionevole quantità di qualità in termini di tempo e budget. Tuttavia, ci sono altre metodologie basate sul piano che sono opposte all'agile che possono e lavorano su progetti.

Le persone non usano il modello a cascata del libro di testo e probabilmente non lo hanno mai fatto.

È un costrutto idealizzato e teorico il cui scopo è farti pensare ai passi nello sviluppo dei sistemi. Il punto principale è che vuoi che i cambiamenti più grandi avvengano il più presto possibile, perché non avrai mai il tempo o i soldi per fare un grande cambiamento una volta che è stato costruito un sacco di codice.

Nonostante sia più un modo di pensare che un processo, è ancora il modo in cui molti - probabilmente la maggior parte delle organizzazioni si occupa di costruire software (o case, sottomarini o qualsiasi altra cosa ...).

Nel mondo reale, non hai interruzioni totalmente rigide tra le fasi e talvolta ritorni alle fasi precedenti per piccoli sottoprogetti. Ciò che la metodologia ti dice non è che "queste cose non sono consentite". Ciò che ti dice è "queste cose ti costano denaro e / o tempo", quindi cerca di evitarlo in futuro.

Va bene per Agile Snobs (TM) guardare in fondo agli sviluppatori "vecchio stile" e alla loro metodologia a cascata insolita, non praticabile, ma il fatto è che Agile non è nemmeno una panacea. Alcuni progetti non possono essere realizzati utilizzando Agile e molti team che pensano di essere Agile sono in realtà solo sciatti e disorganizzati.

La metodologia non è il punto. Il punto è pensare a cosa stai facendo e perché lo stai facendo in questo modo - e ottenere il massimo valore per il cliente nel più breve tempo ragionevole.

Il mitico processo a cascata che viene spesso confrontato con l'agile non è mai esistito e quindi non può essere considerato morto. I processi a cascata reali sono ancora vivi e ineccepibili ed eccellono nel fornire in tempo il software economico che soddisfa le aspettative degli utenti.

Forse un modo migliore per chiedere a cosa stai arrivando è "quando è meglio meno iterativo e più formale?"

Ci sono situazioni in cui questo è il caso:

• Quando i requisiti non cambieranno.

• Quando si soddisfano nuovi requisiti è meno importante che colpire il 100% di quelli originali.

• Quando tutti i componenti tecnologici sono maturi e ben compresi.

In un certo senso puoi prendere il contrario di ciò che potrebbe spingerti ad essere agile.

Pochissime tecniche sono applicabili ovunque. Pochissimi non servono.

Sì, è molto vivo, sebbene oggi sia utilizzato il " modello V " più comune .

In entrambi i casi, il problema che Agile ha è che la soluzione non finisce quasi mai, il cliente può continuare a richiedere modifiche e lo sviluppo continuerà a risolverle in modo iterativo. Per un progetto basato sul tempo e sui costi dei materiali, questo funziona molto bene. Per un progetto che ha un costo fisso, non lo è.

Per questi progetti a costo fisso, il cliente si aspetta quasi sempre che le pietre miliari predefinite dimostrino progressi, tuttavia, si tratta più della varietà scritta formale che del codice di lavoro. Per i clienti come questo, le specifiche scritte diventano il progetto, quello in cui lo sviluppo del software è una considerazione secondaria (poiché presumono, se si dispone di un progetto ben definito, il software dovrebbe essere facile da sviluppare). Queste aziende sono anche quelle che fanno largo uso di risorse di sviluppo economiche e in outsourcing.

Pertanto, se si dispone di una somma di denaro o di tempo fissi, non aspettarsi che i requisiti cambino o non sia consentito cambiarli e ci si aspetta che forniscano una solida serie di documentazione scritta, quindi i modelli a cascata sono gli unici che ha senso.

Agile può essere introdotto nel mezzo di questi progetti per fare lo sviluppo, ma hai ancora una fase di accelerazione in cui le specifiche vengono create dai requisiti e una fase di accelerazione in cui il software viene installato e testato in loco. Agile non risponde bene a questi casi.

A chi? La maggior parte dei gestori con cui ho avuto a che fare utilizza ancora il processo di sviluppo del software Waterfall per la pianificazione, e sembra che i livelli più alti lo apprezzino per una facile programmazione.

In pratica, pochissimi sviluppatori che conosco credono che funzioni o siano addirittura validi.