Ci sono vantaggi rispetto a pratiche agili oltre ad avere una build funzionante tra gli sprint?

Di recente mi sono interessato alle pratiche agili nello sviluppo del software e da allora ho visto molti articoli sottolineare che queste pratiche consentono di ridurre i costi complessivi.

La logica alla base di solito va così: se i tuoi requisiti cambiano, puoi riflettere questo cambiamento nel prossimo backlog dello sprint e questo porterà a costi ridotti, perché la progettazione della nuova funzionalità e l'implementazione è ravvicinata in termini di tempo, quindi il il costo diminuisce, secondo la famosa regola secondo cui in seguito è necessario apportare una modifica alle proprie esigenze, maggiore sarà il costo per soddisfare tale requisito.

Ma i progetti software medio-grandi sono complessi. Un'improvvisa modifica dei requisiti non significa che non dovrai toccare altre parti del tuo sistema per soddisfare tale requisito. In molti casi l'architettura dovrà essere modificata in modo molto significativo, il che significa anche che dovrai implementare nuovamente tutte le funzionalità che si basavano sull'architettura precedente. Quindi l'intero punto di riduzione dei costi in un certo senso scompare qui. Naturalmente se un nuovo requisito richiede una nuova parte indipendente del sistema, questo non è un problema, la vecchia architettura cresce, non ha bisogno di essere ripensata e reimplementata.

E il contrario. Se stai usando la cascata e improvvisamente ti rendi conto che deve essere introdotto un nuovo requisito, puoi andare e cambiare il tuo design. Se richiede che l'architettura esistente venga modificata, la riprogetti. Se in realtà non si scherza, ma introduce solo una nuova parte del sistema, allora vai e fai tutto il lavoro, nessun problema qui.

Detto questo, mi sembra che l'unico vantaggio di uno sviluppo agile sia la creazione di funzionalità complete tra gli sprint, e per molte persone e gli articoli non è fondamentale. Inoltre, l'agile sembra comportare una cattiva architettura del software in generale, poiché le caratteristiche sono un po 'schiaffeggiate l'una sull'altra, i team agili si preoccupano solo che una funzione funzioni, non come funziona. Questo sembra che quando i sistemi crescono in complessità con il tempo, le pratiche di sviluppo agili aumentano effettivamente il caos nell'architettura generale del prodotto, con conseguente conseguente aumento dei costi, dal momento che sarà sempre più difficile introdurre cambiamenti, mentre la cascata ti consente di perfezionare la tua architettura prima di rilasciare qualcosa.

Qualcuno può indicarmi dove sto andando storto qui, perché ovviamente molte persone usano agile in ambienti di produzione, quindi devo sbagliarmi da qualche parte.

Prima di tutto, il modello "a cascata" era sempre un uomo di paglia che descriveva come NON eseguire un progetto di sviluppo software. Cerca.

Comunque, la maggior parte dei progetti SDLC "a cascata" comportano un processo di "gestione del cambiamento", poiché quando le persone scoprono che i presupposti che sono stati scritti nelle specifiche non sono più validi (e ciò accade sempre su grandi progetti complessi). Sfortunatamente, il processo di gestione delle modifiche è costruito come misura di gestione delle eccezioni ed è incredibilmente costoso, il che significa che il progetto finirà tardi o di scarsa qualità.

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

Un altro grosso problema con la progettazione a caricamento frontale è che (molto spesso) viene dedicato così tanto tempo alla raccolta dei requisiti e alla progettazione, allo sviluppo e al collaudo. Inoltre, se il test è l'ultima fase e viene rilevato un problema serio, è altamente improbabile che venga risolto entro il periodo di tempo.

Forse una delle migliori caratteristiche di un approccio Agile è che richiede una continua interazione (cioè una vera comunicazione) tra il team che sviluppa la soluzione e il cliente che ne ha bisogno. Vengono stabilite le priorità, in modo che gli elementi con la priorità più alta vengano eseguiti per primi (e se scade il tempo, vengono tagliati gli articoli con priorità bassa). Il feedback arriva rapidamente.

Tornando alla questione dei cambiamenti drammatici, devi davvero usare metodi che mitigano i cambiamenti. Buoni direttori di SOLID OO possono svolgere un ruolo importante in questo, così come la creazione di solide suite di test automatizzate in modo da poter testare la 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 delle specifiche. Mai. Waterfall parte dal presupposto che tutti accetteranno bene una specifica all'inizio e quindi quando il software verrà consegnato al cliente un anno dopo, corrispondendo alle specifiche, saranno felici. In pratica, i clienti scoprono sempre tutte le cose di cui hanno davvero bisogno, davvero non hanno bisogno e devono davvero 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 alle mutevoli esigenze. Si tratta anche di far sì che tali requisiti mutevoli si verifichino 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 altamente visibili, i progetti hanno meno probabilità di uscire dai binari. Con un grande progetto Waterfall, è fin troppo facile andare indietro senza nemmeno accorgersene. Waterfall produce marce morte di un millesimo alla fine del progetto. Con Agile, poiché effettui consegne ai clienti ogni due settimane, tutti sanno esattamente dove si trova il progetto e le scivolate vengono catturate (e adattate) rapidamente. Nella mia esperienza, Waterfall produce alla fine settimane o mesi di 100 ore settimanali. Agile significa che potresti dover mettere un paio di giorni 12 ore alla fine dello sprint.

Un terzo vantaggio è che i progetti Agile tendono ad essere più motivanti. È molto difficile per le persone avere un qualche senso di guida in un progetto lungo un anno. La scadenza sembra così lontana e quella mancanza di immediatezza significa che le persone tendono a procrastinare, lucidare eccessivamente i progetti e altrimenti 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 delle specifiche. Poiché Agile ha sempre delle scadenze molto immediate e concrete nel prossimo futuro, le persone tendono ad essere più motivate. È molto più difficile procrastinare con una scadenza concreta per una serie fissa di compiti previsti per la prossima settimana.

In risposta alla citazione della domanda, che è un'idea sbagliata fondamentale degli avversari anti-agili

"... mentre la cascata ti permette di perfezionare la tua architettura prima di rilasciare qualsiasi cosa." è un errore, lascia che lo aggiusti per te; "... mentre la cascata ti permette di perfezionare la tua architettura in modo da non rilasciare mai nulla. "

L'implicazione che Waterfall fornisce in qualche modo un'architettura di qualità superiore è fondamentalmente falsa e completamente smentita da prove storiche empiriche.

Se Facebook fosse stato progettato a cascata con 500 milioni di utenti come un requisito duro e veloce e non fosse rilasciato fino a quando un'architettura a supporto che fosse stata perfezionata, nessuno ne avrebbe mai sentito parlare oggi.

Lo stesso con YouTube, Twitter e innumerevoli altre società.

Hanno ottenuto qualcosa che il cliente può toccare e rispondere al lavoro e lo rilasciano il più rapidamente possibile. Hanno ricevuto feedback, perfezionato e rilasciato di nuovo; iterate. Ecco come in questi tre esempi, rispondono solo con funzionalità che i clienti accettano e desiderano e perdono il minor tempo possibile in cose che i clienti trovano di scarso o nessun valore.

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

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

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

Farlo in questo modo consente di gestire i cambiamenti in modo rapido e sicuro, che è anche il motivo principale per utilizzare lo sviluppo agile in primo luogo.

L'unica misura di agilità che conta è se riesci regolarmente (settimanalmente, due volte a settimana) a rilasciare software valido e funzionante per il tuo cliente. Puoi farlo? Allora sei agile nel mio libro.

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

Fornendo in modo iterativo e ricevendo un sacco di feedback dalla tua base di utenti, aumenti la possibilità che tu fornisca qualcosa che realmente desiderano e lo farai fornendo pragmaticamente le funzionalità più importanti per loro il prima possibile. In teoria, ciò avverrà con stime e pianificazione migliori. Questo è ovviamente molto allettante dal punto di vista aziendale, molto più della semplice costruzione rilasciabile.

Potresti sostenere che questo cambiamento costante compromette il tuo sistema e riduce la qualità, ma direi due cose. 1) Questo cambiamento si verifica comunque su progetti di consegna di software più tradizionali: non è stato preso in considerazione e si verifica più avanti nel progetto, 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 e pratiche come TDD, accoppiamento e revisioni del codice. Senza quel cambiamento di mentalità verso la qualità e il miglioramento continuo, accetto che i frequenti cambiamenti che l'agile implica potrebbero iniziare a causare problemi.

In molti casi l'architettura dovrà essere modificata in modo molto significativo, il che significa anche che dovrai implementare nuovamente tutte le funzionalità che si basavano sull'architettura precedente.

Se la tua architettura deve essere modificata in modo significativo a seguito di una modifica dei requisiti, hai una cattiva architettura o requisiti cattivi. Una buona architettura consente di rinviare quante più decisioni possibili e di disaccoppiare i componenti del sistema. Buoni requisiti (utente) non sono cose come "usa un database diverso".

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

In molti casi l'architettura dovrà essere modificata in modo molto significativo, il che significa anche che dovrai implementare nuovamente tutte le funzionalità che si basavano sull'architettura precedente. Quindi l'intero punto di riduzione dei costi in un certo senso scompare qui.

Seguendo un processo agile, ci sono maggiori possibilità di ottenere questo requisito prima che sia stato sviluppato troppo software (e deve essere cambiato). Quando trascorri diversi mesi senza lavorare con il cliente e dando loro qualcosa da guardare, affronti questi importanti problemi architettonici solo dopo aver "pensato" di essere pronto a consegnare.

Preferirei provare a implementare queste modifiche in un'applicazione funzionante che ha una copertura di test piuttosto che un enorme mucchio di codice che non si compila nemmeno. Pur essendo a capo dell'assistenza tecnica, mi è stato consegnato un CD di un'applicazione che era stata in mesi di sviluppo e che non si sarebbe nemmeno installata. Avremmo potuto trovare quel problema la prima settimana, ma invece era tempo di ordinare la cena perché era una lunga notte.