Ci sono dei vantaggi per le pratiche agili oltre ad avere una build funzionante tra gli sprint?

Prima di tutto, il modello "cascata" è sempre stato un uomo di paglia che descrive come NON eseguire un progetto di sviluppo software. Cercare.

Comunque, la maggior parte dei progetti SDLC "a cascata" comportano un processo di "Change Management", per quando le persone scoprono che le ipotesi che sono state scritte nelle specifiche non sono più valide (e ciò accade sempre su progetti complessi di grandi dimensioni). Sfortunatamente, il processo di gestione delle modifiche è costruito come misura di gestione delle eccezioni ed è stupidamente costoso, il che significa che il progetto finirà in ritardo o di scarsa qualità.

L'idea alla base delle metodologie Agile è che il cambiamento è un dato di fatto: accadrà. Pertanto, è necessario eseguire l'operazione standard di "gestione delle modifiche" anziché la gestione delle eccezioni. Questo non è facile, ma la gente ha scoperto che se si utilizzano molte buone pratiche di progettazione, è possibile farlo.

Un altro grosso problema con il design a caricamento anteriore è che (molto spesso) si impiega così tanto tempo nella raccolta dei requisiti e nella fase di progettazione, sviluppo e tempo di test soffre. Inoltre, se il test è l'ultima fase e viene rilevato un problema serio, è altamente improbabile che venga risolto entro il lasso di tempo.

Forse una delle migliori caratteristiche di un approccio Agile è che richiede un'interazione continua (ovvero una comunicazione reale) tra il team che sviluppa la soluzione e il cliente che ne ha bisogno. Le priorità sono fatte, in modo che le voci con la priorità più alta vengano eseguite per prime (e se il tempo scade, sono gli elementi a bassa priorità che vengono tagliati). Il feedback arriva rapidamente.

Tornando alla questione dei cambiamenti radicali - è davvero necessario utilizzare metodi che mitigano i cambiamenti. I principi SOLID OO solidi possono svolgere una buona parte di questo, così come la creazione di solidi test suite automatizzati in modo da poter eseguire il test di regressione del software. Dovresti fare queste cose indipendentemente dalla tua metodologia, ma diventano veramente essenziali se stai cercando di essere agile.

Bene, ci sono alcuni vantaggi. Il primo è che i clienti non leggono i documenti specifici. Mai. Waterfall presuppone che tutti siano d'accordo su una specifica all'inizio e che quando il software verrà consegnato al cliente un anno dopo, le specifiche saranno soddisfatte. In pratica, i clienti scoprono solo tutte le cose di cui hanno veramente bisogno, non ne hanno davvero bisogno e hanno davvero bisogno di essere qualcosa di diverso quando giocano attivamente con il software stesso. Agile ottiene un prototipo funzionante nelle mani dei clienti, quindi queste disconnessioni vengono catturate immediatamente. Agile non si tratta solo di reagire ai mutevoli requisiti. Significa anche far sì che i requisiti in evoluzione si presentino presto, quando il costo del cambiamento è basso, non alla fine, quando il costo del cambiamento è elevato.

Un secondo vantaggio è che, poiché Agile ha spesso risultati molto visibili, i progetti hanno meno probabilità di uscire dai binari. Con un grande progetto Waterfall, è fin troppo facile andare indietro senza nemmeno rendersene conto. La cascata produce marce di morte plurime alla fine del progetto. Con Agile, perché stai consegnando ai clienti ogni due settimane, tutti sanno esattamente dove si trova il progetto e gli slittamenti vengono catturati (e adattati per) rapidamente. Nella mia esperienza, Waterfall produce settimane o mesi di 100 ore settimanali alla fine. Agile significa che potresti dover inserire un paio di 12 ore alla fine dello sprint.

Un terzo vantaggio è che i progetti Agile tendono ad essere più motivanti. È molto difficile per le persone avere una sorta di senso di guida in un progetto lungo un anno. La scadenza sembra così lontana e questa mancanza di immediatezza significa che le persone tendono a procrastinare, a smussare i progetti e, altrimenti, semplicemente non funzionano in modo molto produttivo. Ciò è particolarmente vero perché i primi mesi vengono spesi per cose che le persone non amano fare, come i documenti spec. Poiché Agile ha sempre delle scadenze concrete e immediate nel prossimo futuro, le persone tendono ad essere più motivate. È molto più difficile procrastinare con una scadenza concreta per una serie fissa di compiti dovuta la prossima settimana.

In risposta alla citazione dalla domanda, che è un malinteso fondamentale degli avversari anti-agili

"... mentre waterfall consente di perfezionare la tua architettura prima di rilasciare qualsiasi cosa." è un errore, lascia che lo aggiusti per te; "... mentre waterfall consente di perfezionare la tua architettura così mai rilasciare nulla. "

L'implicazione di Waterfall su come fornire un'architettura di qualità superiore è fondamentalmente falsa e completamente smentita da prove storiche empiriche.

Se Facebook è stato progettato in modo cascata con 500 milioni di utenti come requisito duro e veloce e non è stato rilasciato fino a quando un'architettura per supportare era perfezionata nessuno ne avrebbe mai sentito parlare oggi.

Stessa cosa con YouTube, Twitter e innumerevoli altre società.

Hanno qualcosa che il cliente può toccare e rispondere al lavoro e lo rilasciano il più rapidamente possibile. Hanno ricevuto feedback e lo hanno perfezionato e rilasciato di nuovo; iterare. Ecco come in questi tre esempi, rispondono solo con le caratteristiche che i clienti accettano e vogliono e sprecano il minor tempo possibile su cose che i clienti trovano di poco o nessun valore.

Chiunque abbia anni significativi di esperienza nello sviluppo del software sarà d'accordo che non esiste un'architettura perfezionata . Solo uno che inizia più lontano dall'entropia e dalla grande palla di fango di altre alternative. Agile riconosce questo e lo prende in considerazione. Costruire nel processo, questo come debito tecnico, rapida ridefinizione delle priorità e refactoring.

Scrum di per sé non prescrive alcuna pratica tecnica perché è un framework generale.

Lo sviluppo di software agile richiede l'eccellenza tecnica del team. Questo deriva dalle seguenti pratiche tecniche da XP (programmazione estrema). Ad esempio, devi conoscere refactoring, tdd, tutto il team, programmazione di coppie, progettazione incrementale, ci, collaborazione ecc.

Facendolo in questo modo è possibile gestire il cambiamento in modo rapido e sicuro, che è anche la ragione principale per l'utilizzo dello sviluppo agile in primo luogo.

L'unica misura di agilità che conta è se regolarmente (settimanalmente, bisettimanale) riesci a rilasciare software prezioso e funzionante ai tuoi clienti. Puoi farlo? Allora sei agile nel mio libro.

Per me, il principale vantaggio di agile è la riduzione del rischio nel progetto.

Consegnando iterativamente e ricevendo molti feedback dalla tua base di utenti, aumenterai le possibilità che tu possa offrire qualcosa che realmente vogliono, e lo farai realizzando pragmaticamente le funzionalità più importanti per loro fin da subito possibile. In teoria, questo sarà fatto con migliori stime e pianificazione. Questo è ovviamente molto interessante dal punto di vista del business - molto più che solo la build rilasciabile.

Potresti sostenere che questo cambiamento costante compromette il tuo sistema e riduce la qualità, ma direi due cose. 1) Questo cambiamento avviene comunque su progetti di consegna di software più tradizionali - è solo scontato e si verifica più avanti nel progetto che è quando, come hai sottolineato, le cose sono più difficili e più costose da cambiare. 2) Agile ha molto da dire su come affrontare questo cambiamento in termini di utilizzo di persone motivate con esperienza e pratiche come TDD, accoppiamento e recensioni di codice. Senza quel cambio di mentalità verso la qualità e il miglioramento continuo, accetto che i frequenti cambiamenti che l'agilità implica potrebbero iniziare a causare problemi.

In a lot of cases the architecture will need to be modified very significantly, which will also mean you'll need to re-implement all the features that relied on the older architecture.

Se la tua architettura ha bisogno di essere modificata significativamente come conseguenza di una modifica dei requisiti, hai una cattiva architettura o cattivi requisiti. Una buona architettura consente di rinviare il maggior numero possibile di decisioni e disaccoppiare i componenti del sistema. I buoni requisiti (utente) non sono cose come "usa un database diverso".

Quindi, operiamo partendo dal presupposto che abbiamo una buona architettura di lavoro. Se questo è il caso, allora le metodologie di sviluppo agili perdono questo "lavaggio" con le metodologie di progettazione frontale. Dopotutto, una caratteristica fondamentale delle metodologie di sviluppo agili sono le pratiche come TDD che promuovono l'accoppiamento lento nel codice, consentendo al progetto di continuare ad alta velocità, sia che sia vicino all'inizio o molto maturo.

In a lot of cases the architecture will need to be modified very significantly, which will also mean you'll need to re-implement all the features that relied on the older architecture. So the whole point of reduced costs kinda goes away here.

Seguendo un processo agile, c'è una migliore possibilità di cogliere questo requisito prima che sia stato sviluppato troppo software (e deve essere modificato). Quando trascorri diversi mesi senza lavorare con il cliente e dando loro qualcosa da guardare, cogli questi problemi architettonici importanti solo dopo aver "pensato" di essere pronto per la consegna.

Preferirei provare a implementare queste modifiche in un'applicazione funzionante che abbia una copertura di test piuttosto che una massiccia quantità di codice che non viene nemmeno compilata. Mentre ero a capo del supporto tecnico, mi è stato consegnato un CD di un'applicazione che era stata in mesi di sviluppo e che non sarebbe nemmeno stata installata. Avremmo potuto trovare il problema la prima settimana, ma invece è stato il momento di ordinare la cena perché era una lunga notte.