Il metodo Waterfall è certamente fattibile ed è filosoficamente valido come qualsiasi altro approccio. Ricorda che Waterfall è stato molto più lungo di Agile, ma nota che questo non è un argomento per stabilire se una metodologia è migliore di un'altra.
Si utilizza il metodo Cascata quando si ha una comprensione molto chiara dell'intero dominio del problema e di ciò che il cliente desidera ottenere in un pacchetto software. Probabilmente hai quotato un prezzo fisso quando assumi il contratto e il tuo cliente capisce che non possono discostarsi da alcun requisito concordato. Il tuo processo è rigorosamente uno che attraversa una serie di accordi tra le varie fasi di sviluppo, ed è spesso il caso che ogni fase è completata da una squadra diversa - a volte anche una società diversa - ciascuna delle quali potrebbe non necessariamente contatto con gli altri. Si vedono spesso le Cascate applicate a buoni risultati in progetti militari e governativi quando vengono offerte ad appaltatori esterni. Dove Waterfall e altri approcci simili ottengono una cattiva reputazione è quando gli sviluppatori si imbattono in problemi, come la scarsa stima, pianificazioni pianificate senza tempi di contingenza, o una comprensione scarsa o incompleta del dominio del problema. Il problema non è mai veramente una colpa della metodologia, ma nella sua applicazione.
Il confronto tra Agile e qualsiasi metodologia è falso. Agile non è una metodologia, è una filosofia, o forse sarebbe meglio dire che è un termine generico che rappresenta un modo diverso di guardare come si sviluppa lo sviluppo del software. Una metodologia è semplicemente uno strumento, e in quanto tale il suo valore sarà sempre inferiore agli individui e alle interazioni che sono al centro di cosa significa essere Agili .
Does anyone really think that minimizing change in software is a viable option for those that desire to deliver valuable software?
Ogni opportunità di ridurre al minimo le modifiche è preziosa sia per lo sviluppatore che per il cliente. Le modifiche possono far sì che una pianificazione scivoli o che le funzioni vengano lasciate fuori per soddisfare un programma. È come gestisci gli effetti dei cambiamenti che influiscono sul valore dei tuoi progetti.
Or is the question really about what sort of practices work best in our situations to manage the inevitable change?
Le tue pratiche potrebbero essere di aiuto nella gestione del cambiamento, oppure potrebbero ignorare completamente il cambiamento. Ciò che conta è la combinazione delle tue pratiche di sviluppo e la gestione delle tue relazioni con i tuoi clienti, e se queste cose funzionano insieme efficacemente per tutte le parti coinvolte.
Quelli di noi che sono a tutti gli effetti Agile capiscono che tu scegli un metodo che funziona per te. Se ti piace un approccio particolare, seguilo. Se non si adatta perfettamente alle tue esigenze, cambialo. Il modo in cui realizzi il software di crafting si riduce a cercare di utilizzare al meglio le risorse a tua disposizione e di ridurre al minimo le pratiche che possono portare il tuo progetto al fallimento, e spesso scopri che devi cambiare il metodo per adattarlo particolare progetto a portata di mano.
È davvero una cosa da dire "Ok, quindi ora siamo Agile", e totalmente un'altra per vivere e lavorare realmente con la filosofia che è Agile. Sia che utilizzi Waterfall, Incremental, Spiral, SCRUM, XP, FDD, o qualsiasi altro metodo, sei fondamentalmente Agile dove apprezzi:
- Individui e interazioni su processi e strumenti
- Software di lavoro su documentazione completa
- Collaborazione con il cliente per la negoziazione del contratto
- Risposta al passaggio successivo a un piano
e dove porti insieme i tuoi strumenti, i tuoi metodi e la tua esperienza per applicare con successo questi valori.