Qualcuno sa la differenza tra quei due?
Sono entrambi creati da un approccio iterativo - dando una revisione successiva dopo ogni iterazione. Entrambi hanno le fasi iniziali del progetto idea- > analysis- > (outline).
Le definizioni varieranno quindi dubito che otterrai una risposta definitiva a questa domanda.
Detto questo, la differenza più ovvia e potenziale che vedo è come le iterazioni si riferiscono al tuo design / architettura di alto livello:
"Il design evolutivo" è un termine generico che copre tutti i metodi di progettazione che utilizzano una sorta di meccanismo di mutazione / selezione (vale a dire, modifica - prova - rifiuto / accetta cicli); "Cascata con iterazioni" descrive in modo specifico un processo di sviluppo che applica il modello Waterfall in modo iterativo.
Un processo informale a singolo sviluppatore in cui tutto lo sviluppo avviene su una macchina, le modifiche vengono apportate ad hoc secondo necessità e distribuito quando sono considerate "pronte", è certamente un modello di progettazione evolutivo, ma non si adatta alla definizione di Waterfall , nemmeno nella sua interpretazione più rilassata.
Da quello che ho vissuto, le persone usano per lo più "cascata con iterazioni" come termine derisorio per implementazioni agili scarse o timide e non come metodologia pratica.
Comunque mi sono imbattuto in questo articolo che ha una spiegazione decente del termine "cascata itterativa".
Iterative Waterfall potrebbe anche significare abbattere i progetti di grandi dimensioni nelle pietre miliari e chiamare ogni milestone come "iterazione".
Naturalmente, fare questo è peccato poiché rimuove tutte le possibilità di revisione o feedback da iterazioni precedenti a quella successiva. Eppure l'ho visto applicato dopo di che i loro goniometri proclamavano alto e strong che ora erano Agile per farlo !!
Un'altra definizione di cascata iterativa è di avere cascate successive in cui il prossimo si nutre del precedente. Di nuovo nessun feedback durante il ciclo stesso dalla progettazione alla consegna, ma solo tra consegna e progettazione è consentito il feedback. Questa definizione sembra corrispondere al collegamento fornito da DPD.
La mia personale definizione di stile "Waterfall" e processi in stile "Agile" sta nel modo in cui il progetto viene visualizzato e analizzato. Entrambe coprono praticamente le stesse fasi e processi, ma le affrontano in un modo molto diverso. Se si visualizza la produzione di un software come stack con Inception nella parte superiore e distribuzione e supporto nella parte inferiore.
Waterfall abbatterà il processo di creazione del software orizzontalmente e attraverserà ogni livello in sequenza. Per un cascinista (se una cosa del genere può essere detta) procedere allo strato successivo è impossibile senza aver completamente elaborato lo strato sopra, è semplicemente inconcepibile. L'argomento tipico sarebbe che non costruisci mai il tetto di una casa prima della fondazione e dirai cose simili a "misurare due volte ma tagliare una volta".
Agile d'altra parte abbattere il processo di creazione verticalmente producendo porzioni di funzionalità che vengono aggiunte al prodotto nel tempo. con ogni fetta tuttavia non procedono attraverso la pila dall'alto verso il basso ma affrontano tutto in una volta. Sono in grado di farlo perché hanno volutamente ridotto la portata del risultato finale. Per loro è inconcepibile procedere senza test prima per vedere se l'idea ha senso. Con ogni iterazione aggiungono scarse funzionalità e testarlo contro l'idea e contro il resto del sistema.
La cascata è radicata in ingegneria dove l'obiettivo è un prodotto tangibile della vita reale e l'errore non è ammissibile. Vedono il software come pezzi rigidi di acciaio e cemento che devono essere assemblati in una struttura. Quindi tenderanno a essere troppo cauti planando tutto minutamente sprecando risorse sull'altare della perfezione. Affinché Waterfall funzioni, hai bisogno di giocatori esperti molto forti e di una totale fiducia in loro, devi essere estremamente meticoloso in ogni fase del percorso nel prevedere cosa potrebbe essere e in anticipo.
Agile è radicata nel processo scientifico in cui la conoscenza viene raccolta un po 'alla volta e testata continuamente. Capiscono perfettamente che il software è malleabile e può essere piegato e modellato a volontà. Trattano le idee come farebbe un ricercatore per trattare una teoria, vale a dire finché è d'accordo con i test. Pertanto tenderanno a rimodellare continuamente il loro sistema sprecando risorse ricreando le stesse cose ogni volta con una leggera svolta per adattarsi alle nuove variabili. Per lavorare agilmente è necessario valutare continuamente il sistema nel suo insieme e metterlo contro la nuova realtà. Le misure e l'automazione sono essenziali per ottenere il quadro più preciso possibile del presente in modo tale che il prossimo passo possa essere preso come misura correttiva verso il percorso ideale. Anche il percorso ideale deve essere rivalutato per assicurarsi che punti effettivamente verso il target ideale.
Il software Waterfall Build durerà così com'è, statico, impostato in concreto.
Agile sviluppa software, prendilo cura e tendilo in un mondo in continua evoluzione.
È vero che il software è malleabile nelle prime fasi ma, man mano che guadagna dimensioni ed età, acquisisce rigidità e resistenza a cambiamenti sempre più numerosi. Secondo me non esiste un proiettile d'argento e tende ad esserci molta devozione religiosa a scapito della riflessione razionale. Detto questo dei due estremi, Agile sembra essere quello che tiene conto del software morbido.
Leggi altre domande sui tag development-process waterfall