Si sta eseguendo una cascata ogni 2 settimane considerato uno sviluppo agile?

La cascata tradizionale (e non corretta) è una singola iterazione attraverso le fasi del ciclo di vita. Innanzitutto, si esegue l'ingegneria dei requisiti. Utilizzando tali requisiti, l'utente progetta e progetta il sistema e verifica / convalida tali progetti. Quindi, si implementa il sistema. Una volta implementato il sistema, lo si verifica per assicurarsi che funzioni come previsto. Infine, lo spedisci al cliente per la distribuzione e l'utilizzo. Il progetto entra in un ciclo di manutenzione in cui si sistemano i bug e si rilasciano gli aggiornamenti, fino a quando il progetto non è terminato. Il processo ha un aspetto simile al seguente:

Inrealtà,questoèuncattivomodelloperlosviluppodisoftware.Ildocumentoincuimoltepersonehannoimparatoaconoscerelacascatainrealtàhapropostoqualcosadimoltodiverso.Coinvolgeunaltolivellodicoinvolgimentodelclienteinognifaseelatransizioneversolefasiprecedentipercorreggereemodificaregliartefatti.Puoileggereulterioriinformazioniinmeritoa articolo di Royce, Gestione dello sviluppo di grandi sistemi software . Sembra qualcosa di più:

Infine,abbiamogliapprocciagili,chesono modelli di sviluppo iterativo e incrementale . Ci sono molte varianti su modelli iterativi e incrementali. L'idea in tutti loro è quella di eseguire tutte le fasi del ciclo di vita - requisiti, architettura, progettazione, implementazione, test, rilascio - molte volte nella vita del prodotto, finché il cliente non vuole terminare il prodotto. Non esiste un diagramma dettagliato reale di come sia lo sviluppo iterativo e incrementale, in quanto vi sono molte varianti, ma il risultato è in genere un ciclo di feedback.

Lo sviluppo agile ti consente di:

1. Offri rapidamente funzionalità di lavoro
2. Rispondi ai requisiti in evoluzione

Uno dei punti è evitare l'intero problema di Big Design Up Front che gli sviluppi tradizionali di Waterfall, che sono durati per anni prima che qualsiasi cosa sia stata recapitata, portano a.

Quindi se stai consegnando qualcosa ogni due settimane, allora agisci in modo efficace (nota la lettera minuscola "a"), ma non Agile (con la lettera maiuscola "A"). Dovresti essere in grado di rispondere ai cambiamenti fintanto che stai solo progettando l'iterazione corrente e non hai un "Big Design" da cui non ti stai allontanando.

La risposta breve è no. Agile implica uno sviluppo iterativo e adattivo dove Waterfall implica anticipatamente il design. Quindi, non stai agendo o non stai facendo cascata, o (molto probabilmente) non lo fai neanche.

chiamata difficile.

Nel caso in cui descrivi, probabilmente utilizzerei costo degli errori di progettazione come fattore determinante.

• Dì, se ci vuole un mese o due per riprendersi da un errore di progettazione scoperto in fase di test e se ciò accade abbastanza frequentemente da provocare dolore allora certamente ha l'odore di un tipico Problema della cascata a me. Altrimenti, sembra essere abbastanza buono da smettere di preoccuparsi della terminologia.

Se stai spedendo una versione ogni 2 settimane, devi avere qualcosa di insolito.

O la tua azienda è in continua evoluzione, le dimensioni dell'implementazione che stai intraprendendo in ogni ciclo sono così ridotte, o il tuo utente non fornisce l'immagine completa dei requisiti.

Tutto quanto sopra è molto rischioso e può essere risolto con un'analisi e una progettazione up-front corrette.

Se rilasci il tuo software ogni 2 settimane, avrai probabilmente bisogno di dedicare molto tempo a test di regressione, documentazione, formazione per il supporto alla produzione, formazione degli utenti, ecc. Inoltre, lo stile di caduta dell'acqua non è basato su cicli iterativi e non ha alloggio per i test di regressione.

Sono anche preoccupato per l'impressione dell'utente finale di un cambiamento nel software ogni 2 settimane. Personalmente, non voglio vedere una nuova voce di menu sull'applicazione ogni tanto che fa qualcosa di nuovo ...

Se fossi in te, vorrei studiare il vero valore di avere un ciclo di 2 settimane.