La metodologia di sviluppo del software Waterfall è ancora valida?

Il modello a cascata a cui ti riferisci non è mai stato concepito come un modello di processo utilizzato su un progetto reale. Invece, è un uomo di paglia. Identifica le fasi chiave e le attività esistenti nei progetti software e il flusso più fondamentale tra di loro. Questa semplificazione eccessiva del modo in cui sviluppare il software è difettosa, ed è stata persino presentata in questo modo.

Dall'articolo di Wikipedia:

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, though Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.

Il documento discusso è intitolato Gestione dello sviluppo di sistemi software di grandi dimensioni . In essa, Royce presenta quel modello nella seconda pagina. Tuttavia, il testo immediatamente sotto la rappresentazione pittorica continua a leggere:

I believe in this concept, but the implementation described above is risky and invites failure.

Segue questo con una discussione dei problemi con i test che seguono il "completamento" della fase di sviluppo, e come i guasti qui possono portare a importanti riprogettazioni e modifiche al codice, e come questi possono portare a maggiori eccedenze di costi e tempi. In tutto il lavoro, affina il modello originale in uno che è effettivamente fattibile in un progetto. Alla fine, finisce con un modello che introduce la prototipazione, l'interazione con il cliente e la raffinatezza degli artefatti - idee che alla fine finirebbero per essere fondamentali per il movimento agile iniziato tra la fine degli anni '90 e l'inizio del 2000.

Per rispondere alla tua domanda: la cascata che stai chiedendo non è, e non è mai stata, un metodo valido per consegnare progetti software con una ragionevole quantità di tempo e budget. Tuttavia, esistono altre metodologie pianificate che sono opposte a quelle dell'agile che possono e funzionano sui progetti.

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 reale sono ancora vivi e vegeti, e eccellono nel fornire in tempo un software di budget che soddisfi le aspettative degli utenti.

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

È un costrutto teorico idealizzato il cui scopo è farti riflettere sui passaggi nello sviluppo dei sistemi. Il punto principale è che desideri che i cambiamenti più grandi avvengano il prima possibile, perché non avrai mai il tempo o i soldi per apportare grandi cambiamenti una volta che il codice sarà stato compilato molto.

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

Nel mondo reale, non si hanno interruzioni completamente rigide tra le fasi e talvolta si ricorre alle fasi precedenti per piccoli progetti secondari. Quello che la metodologia ti dice non è che "queste cose non sono permesse". Ciò che ti dice è "queste cose ti costano denaro e / o tempo", quindi cerca di evitarlo in futuro.

Va benissimo che Agile Snobs (TM) guardi dall'alto in basso gli sviluppatori "fuori moda" e la loro metodologia di cascata, caratteristica e inaffidabile, ma il fatto è che Agile non è una panacea. Alcuni progetti non possono essere creati utilizzando Agile e molti team che pensano di essere Agile sono in realtà solo sciatti e non organizzati.

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

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

Ci sono situazioni in cui questo è il caso:

• Quando i requisiti non cambieranno.

• Quando soddisfare i nuovi requisiti è meno importante del colpire il 100% di quelli originali.

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

In un certo senso puoi assumere l'opposto di ciò che potrebbe spingerti ad essere agile.

Pochissime tecniche sono applicabili ovunque. Pochissimi non hanno alcun uso.

Sì, è molto vivo, anche se oggi è il più comune " V model " quello è usato

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

Per questi progetti a costi fissi, il cliente si aspetta quasi sempre delle pietre miliari predefinite per dimostrare il progresso, tuttavia, queste sono più della varietà scritta formale piuttosto che del codice funzionante. Per clienti come questo, le specifiche scritte diventano il progetto, uno in cui lo sviluppo del software è una considerazione secondaria (poiché assumono che, se si dispone di un progetto ben definito, il software dovrebbe essere facile da sviluppare). Queste aziende sono anche quelle che fanno un uso pesante di risorse di sviluppo a basso costo e in outsourcing.

Quindi, se hai un po 'di tempo o denaro fisso, non ti aspetti che i requisiti cambino o non ti sia permesso di cambiare alcun requisito, e ci si aspetta che forniscano un solido set di documentazione scritta, allora i modelli a cascata sono solo quelli che hanno senso.

Agile può essere introdotto nel bel mezzo di questi progetti per lo sviluppo, ma si ha ancora una fase di accelerazione in cui le specifiche sono create dai requisiti e una fase di rampa di decollo in cui il software è installato e testato in situ. Agile non risponde bene a questi casi.

A chi? La maggior parte dei manager con cui ho avuto a che fare usano ancora il Waterfall Software Dev Process per la pianificazione e sembra che i livelli siano graditi per una facile pianificazione.

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