Esiste un'alternativa valida alla metodologia di sviluppo agile?

47

Le due metodologie di sviluppo del software predominanti sono cascate e agili. Quando discutiamo di questi due, spesso ci si concentra molto sulle pratiche particolari che li contraddistinguono (programmazione della coppia, TDD, ecc., Confronto con le specifiche funzionali, il design avanzato, ecc.)

Ma le differenze reali sono molto più profonde, in quanto queste pratiche derivano da una filosofia.

La cascata dice: Il cambiamento è costoso, quindi dovrebbe essere ridotto al minimo.
Agile dice: Il cambiamento è inevitabile, quindi cambia a poco prezzo.

La mia domanda è, indipendentemente da cosa pensi del TDD o delle specifiche funzionali, la metodologia di sviluppo di cascata è davvero valida?

Qualcuno pensa davvero che ridurre al minimo i cambiamenti nel software sia un'opzione praticabile per coloro che desiderano fornire software prezioso? O la domanda è davvero su quale tipo di pratiche funzionano meglio nelle nostre situazioni per gestire l'inevitabile cambiamento?

    
posta Eric Wilson 12.11.2010 - 17:29
fonte

9 risposte

59

Naturalmente cascata è praticabile. Ci ha portato sulla luna!

Ed è un allenatore agile che parla qui!

Se non riesci a identificare chiaramente i problemi relativi al modo in cui gestisci i tuoi progetti, non c'è alcun motivo valido per cambiare.

In alternativa alle metodologie Agile e Waterfall , suggerirò LA TUA metodologia . Adatta alla tua attività specifica, al tuo team specifico, ai tuoi prodotti, al tuo modo di lavorare, alla tua cultura aziendale ... È per questo che Scrum è chiamato semplice framework anziché una metodologia.

Vogliamo implementare una metodologia perché qualcuno su un blog di cui ti piace parlare è stupido come lasciare andare i problemi senza fare nulla.

    
risposta data 12.11.2010 - 17:41
fonte
21

Per prima cosa, non accetto le tue affermazioni:

Waterfall says: Change is costly, so it should be minimized.
Agile says: Change is inevitable, so make change cheap.

La mia interpretazione è:

La cascata dice: il cliente sa cosa vuole.
Agile dice: Il cliente non sa cosa vuole, quindi dovremo fare alcune versioni differenti.

La migliore implementazione di "cascata" che abbia mai visto era un enorme progetto di integrazione con un cliente finanziario molto grande e c'erano circa 40 progetti secondari coinvolti. Il pacchetto desktop e del sito web che abbiamo fornito era solo uno di questi oltre 40 progetti secondari. Mentre pensavo che facessero esplodere il denaro degli altri in maniera eccessiva, avevano le loro cose insieme e tenevano oltre 40 navi diverse che si muovevano insieme nella formazione. Il progetto è andato in diretta alla data di destinazione (l'obiettivo si è spostato una volta durante il progetto) e mentre pensavo che avrebbero potuto farlo in modo più frugale e agile, è stato fatto in tempo e in base alle specifiche. L'orario della go-live night era di circa 100 pagine e circa 40 di quelle pagine erano i dettagli di contatto di emergenza del panico di tutti i tipi di persone coinvolte. Sono rimasto molto colpito da questo cliente.

Oppure, potresti fare ciò che facciamo, che è correre e fare ciò che è la segnalazione / bug più recente, e chiamare quella agile.

    
risposta data 13.11.2010 - 04:45
fonte
21

Inizi a dire:

The two predominant software-development philosophies are waterfall and agile.

Questo è falso. Questa dicotomia è stata costruita dalla comunità agile per creare un avversario contro cui posizionarsi. Prima che l'agile fosse in voga, la gente parlava di una miriade di approcci diversi alla creazione di software. Esistono ancora oggi, ma in qualche modo sono spesso raggruppati in un gran caos chiamato "cascata" da parte di sostenitori agili.

Ho utilizzato OPEN / Metis e le sue varianti per oltre 10 anni con grande successo. Non è sicuramente agile, e sicuramente non cascata. Migliaia di sviluppatori creano software estremamente complessi per aeromobili, sistemi vitali, bancari, ecc. Usando metodi non agili ogni giorno.

Quindi sì, certo che esiste un'alternativa praticabile all'agile.

    
risposta data 20.12.2010 - 23:45
fonte
10

Sì, varie tecniche di sviluppo software sono tutte valide a seconda del dominio del problema. È "Cavalli per i corsi".

Ad esempio, stai scrivendo software per controllare una centrale nucleare o per guidare lo space shuttle della NASA. Questo tipo di dominio problematico è probabilmente più adatto a un approccio a cascata (o anche più severo), se vuoi risolvere tutti i problemi in anticipo, se possibile (o BOOM!).

Costruire l'ultima interfaccia utente di web 2.0 / 3.0 / buzzy di marketing? Agile è un modo molto migliore per andare (hai bisogno di un feedback rapido e cambiare).

Ci sono quelli che definirei principi di artigianalità del software che possono ancora essere applicati a prescindere dalla metodologia, ad esempio:

  • Controllo del codice sorgente
  • build e CI
  • coppia programmazione
  • TDD
  • Do un ^% $$ &

e altro.

Qualunque cosa tu faccia, non ascoltare gli zeloti su entrambi i lati dell'equazione, fai ciò che è giusto per te, la tua squadra e il tuo dominio problematico.

    
risposta data 12.11.2010 - 17:42
fonte
2

Il problema deriva dalla complessità del software. La cascata funziona alla grande per cose come la costruzione di ponti e la pavimentazione stradale perché la fisica non cambia mai. Certo, a un certo punto svilupperemo un nuovo asfalto ma non rivoluzionerà il modo in cui vengono costruite le strade. L'acciaio nella sospensione di un ponte ha le dimensioni giuste o non lo è. Non puoi eseguire il kludge o lo stub di un vero progetto di costruzione come con il software.

Cambiamenti software. Il software cambia rapidamente. La legge di Moore afferma che il numero di transistor su chip raddoppia ogni 18-24 mesi. In corollario, anche il numero di righe di codice in un programma raddoppia. La complessità tra quelle linee di codice aumenta quindi con un bigO di qualcosa come 2 ^ (2t).

Il software cambia rapidamente e la complessità aumenta esponenzialmente con esso.

Quando controlli il costo del software, vuoi controllare i fattori esponenziali , non solo moltiplicativi o additivi. La modifica del codice aumenta la complessità (e diventa esponenzialmente più complessa quando il progetto procede) in modo esponenziale.

Cambia è inevitabile. La natura stessa della programmazione estende il linguaggio con le classi e i metodi personalizzati, modificando così la lingua stessa. Non puoi farlo in nessun altro tipo di disciplina ingegneristica (come costruire strade, non inventare nuovi marciapiedi solo per pavimentare una strada in Kansas oltre la California).

Il metodo agile fornisce anche una piattaforma per gestire versioni future e correzioni di bug. Hai già gli strumenti di gestione, i processi, i dipendenti formati, per lo sviluppo di software con versioni. Con un metodo a cascata, avresti bisogno di riqualificare il tuo team per gestire anche correzioni di bug minori.

comunque, i miei 2 centesimi.

    
risposta data 12.11.2010 - 17:45
fonte
2

Per rispondere alla domanda, c'è un'alternativa valida, per il software forse no - o non ancora, almeno nel caso generale. Penso che dipenda dalla natura del software. Il software, essendo informazioni, può essere duplicato gratuitamente. A differenza di un ponte o di una casa. Ciò significa che con la pratica potrei diventare bravo a costruire una casa e operare in un dominio relativamente semplice. A che punto, perché non utilizzare un approccio one-shot?

Ma poiché il software ha costi di duplicazione pari a zero, perché mai farei la stessa cosa due volte? Il software è lontano dalla produzione. Quindi, se tutto il software è la creazione di un nuovo prodotto, operiamo sempre in un dominio complesso dove, in una certa misura, non sappiamo cosa stiamo facendo. O è costoso sapere in anticipo ed è più economico scoprirlo. In un dominio complesso e rischioso, vorrei provare esperimenti, incrementare e iterare.

Le centrali nucleari e i sistemi di trasmissione in volo sono spesso indicati come esempi di software che si desidera eseguire in cascata. Ma il sistema avionico dello shuttle non era sviluppato in modo iterativo? Come erano i sistemi di controllo del traffico aereo canadese e statunitense?

E se OPEN / Metis è iterativo e incrementale, per me sembra che abbia la filosofia agile anche se non si associa ad altre pratiche agili comuni.

    
risposta data 10.01.2012 - 04:14
fonte
1

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.

    
risposta data 17.02.2012 - 12:34
fonte
0

Sì, Waterfall, Spiral, Iterative e altri modelli di processo ibridi sono tutti fattibili, ma il cambiamento è inevitabile. Il processo è qualcosa di più di come gestire il cambiamento, e (sostengo che) il fattore determinante più grande è quanto bene tu conosca / capisca il problema e quanto accuratamente puoi pianificare e prevedere.

Affermare che "le due metodologie di sviluppo del software predominanti sono cascanti e agili" è disingeno, in quanto esiste una gamma di processi di sviluppo del software e molte aziende sintetizzano la propria versione del modello di processo, spesso cambiando per un determinato progetto. Esistono più di due approcci fattibili allo sviluppo del software. Sebbene Waterfall e Agile tendano a cadere su estremità opposte dello spettro del "cambiamento", è ragionevole tipizzare queste metodologie in competizione come,

La cascata dice: Il cambiamento è costoso, quindi dovrebbe essere ridotto al minimo.

Agile dice: Il cambiamento è inevitabile, quindi cambia a poco prezzo.

Ma non è tutta la storia. Le aziende devono essere in grado di pianificare e prevedere, ma il software è un processo creativo e le stime sono spesso sbagliate. Ricorda il triangolo buono - veloce - economico? Aggiungi una quarta dimensione, processo e scopri che la riduzione dello sforzo del processo può anche comprimere la pianificazione, quando le stime risultano errate e un progetto è in pericolo di ritardo. Il software è un processo fungibile (mutabile) e Agile, Iterative, Spiral offrono tutti la possibilità di fornire funzionalità incrementali a intervalli più brevi.

Le cascate e altri modelli di processo guidati dai requisiti hanno controlli per gestire il cambiamento, quindi è impreciso dire che Waterfall minimizza i cambiamenti, è più preciso dire che Waterfall riconosce e gestisce i cambiamenti e comunica l'impatto di tale cambiamento (perché il cambiamento causa un programma impatto quando hai esigenze e progetta in anticipo). Quando crei un prodotto o hai bisogno di definire completamente i requisiti (funzionalità), sei guidato a uno dei modelli ibridi.

E quando le stime sono sbagliate, spesso il processo (la quarta tratta del triangolo di ferro) viene sacrificato per soddisfare il programma.

    
risposta data 02.05.2014 - 17:07
fonte
-1

Gli approcci maturi e agili a cascata sono indistinguibili l'uno dall'altro. La tua ipotesi sull'obiettivo dell'approccio a cascata non è corretta. Entrambi hanno l'obiettivo di produrre software di qualità. Quando non si dispone di un solido approccio di sviluppo per la società nel suo complesso, è necessario considerare quale approccio fornirà il minor numero di frizioni all'adozione. Alla fine, i cicli di sviluppo brevi, un solido team di controllo qualità e un'azienda che guida lo sviluppo sono ciò che è più importante per la produzione di software di prima qualità.

    
risposta data 10.01.2012 - 16:52
fonte

Leggi altre domande sui tag