Esiste una valida alternativa alla metodologia di sviluppo agile?


47

Le due metodologie di sviluppo software predominanti sono a cascata e agili. Quando si discute di questi due, spesso ci si concentra molto sulle pratiche particolari che li distinguono (programmazione di coppie, TDD, ecc. Rispetto alle specifiche funzionali, grande design iniziale, 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 rendilo economico.

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

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


1
domanda interessante. in attesa di risposte.
DevSolo,


3
@FarmBoy - Buona domanda. Vedo la filosofia agile in modo leggermente diverso. Lo scriverei come "Agile dice: il cambiamento è inevitabile, quindi rendilo economico per determinare il costo del cambiamento". Il cambiamento potrebbe essere ancora molto costoso, ma in agile puoi capirlo rapidamente ed economicamente in modo da sapere sempre il costo del cambiamento. Esprimerlo in altro modo fa pensare alle persone che dal momento che stanno agendo il cambiamento sarà economico. Alcune modifiche costano molto, indipendentemente dal processo.
Mike Two

1
@Yannis Rizos: perché chiudi da solo questa interessante domanda, senza un solo voto della community?

1
@ Pierre303 a causa di questo problema che la discussione qui portato a questa domanda.
Ryathal,

Risposte:


59

Naturalmente la cascata è praticabile. Ci ha portato sulla luna!

Ed è un allenatore agile che parla qui!

A meno che tu non riesca a identificare chiaramente i problemi relativi al modo in cui gestisci i tuoi progetti, non c'è motivo valido per cambiare.

In alternativa alle metodologie Agile e Waterfall , suggerirò la TUA metodologia . Adattato al tuo business specifico, al tuo team specifico, ai tuoi prodotti, al tuo modo di lavorare, alla tua cultura aziendale ... Ecco perché Scrum è chiamato un framework semplice anziché una metodologia.

Volere implementare una metodologia perché qualcuno su un blog di cui ti piace parlarne è stupido come lasciar andare i problemi senza fare nulla.


10
+1 sulla TUA metodologia, il prossimo allenatore Agile che mi dice SCRUM è l'unico modo per ottenere uno stivale sul retro;)
Martijn Verburg

1
@karianna: faccio specificamente SCRUM, ma a volte non è proprio appropriato. D'altra parte, ho anche visto un team che cercava di vendere SCRUM ai loro capi pensando che avrebbe risolto il loro problema. Hanno fallito perché il problema non erano i loro capi o il loro PM. Non esiste una singola regola. Ogni caso è la sua soluzione. E sì, la maggior parte dei problemi organizzativi può essere risolta con tecniche agili, ma l'agile non è un proiettile d'argento.

5
Non solo la luna. La navetta spaziale aveva ~ 1 milione di righe di codice C nei suoi sistemi integrati. In circa 30 anni hanno avuto solo 2 bug che lo hanno trasformato in build di produzione.
Dan Neely,

2
Waterfall ha anche ucciso i primi tre astronauti. Questa insistenza sull'uso di questo programma Apollo come poster per Waterfall è nella migliore delle ipotesi ignorante. Waterfall è anche citato come responsabile per entrambi i programmi di complete condizioni finanziarie, e lo Shuttle è un "ingegnere spaziale" fragile, ingegnoso e costoso quando le specifiche originali erano per un "camion spaziale". Sono abbastanza sicuro che SpaceX non sarebbe d'accordo su Waterfall.

4
@DanNeely il livello di alta qualità del software dello space shuttle non era economico. Apparentemente il prezzo era di $ 1000 per riga di codice.

21

In primo luogo, non sarò d'accordo con le tue dichiarazioni:

La cascata dice: il cambiamento è costoso, quindi dovrebbe essere ridotto al minimo.
Agile dice: il cambiamento è inevitabile, quindi rendilo economico.

La mia interpretazione è:

Waterfall dice: il cliente sa cosa vuole.
Agile dice: il cliente non sa cosa vuole, quindi dovremo fare alcune versioni diverse.

La migliore implementazione di "cascata" che io abbia mai visto era un enorme progetto di integrazione con un cliente finanziario molto grande e c'erano circa 40 sotto-progetti coinvolti. Il pacchetto desktop e per sito Web che abbiamo fornito era solo uno di quegli oltre 40 progetti secondari. Mentre pensavo che facessero esplodere i soldi degli altri in modo piuttosto eccessivo, avevano le loro cose insieme e tenevano più di 40 navi diverse che si muovevano tutte insieme in formazione. Il progetto è stato pubblicato alla data prevista (l'obiettivo è stato spostato una volta durante il progetto) e mentre pensavo che avrebbero potuto farlo in modo più frugale e agile, è stato realizzato in tempo e in base alle specifiche. Il programma della serata di go-live era lungo circa 100 pagine e circa 40 di quelle pagine erano dettagli di contatto per il panico di emergenza di tutti i tipi di persone coinvolte. Sono stato molto colpito da questo cliente.

Oppure, si potrebbe fare quello che facciamo, che è gestito in giro e fare ciò che il più recente rapporto denuncia / bug è, e chiamare che agile.


8
Secondo Agile Dilbert: is.gd/lDoQgb
Peter K.

11
È più come "Waterfall dice: il cliente non sa cosa vuole, quindi sediamoci, discutiamolo e concordiamo su ciò che vogliono prima di iniziare a hackerarlo" ...
scrwtp,

+1: ottima risposta. Penso che la comunità agile abbia un problema di base: l'agile è buono in determinati contesti per determinate classi di progetti e clienti, ma non riescono a vedere che ci sono progetti in cui i requisiti non cambiano che approcci rapidi e più strutturati sono una scelta migliore . Penso che la comunità agile dovrebbe cercare di identificare realisticamente le aree in cui il loro approccio è una scelta migliore (penso che tali aree esistano) e non provare a spingerlo come soluzione generale, perché non lo è.
Giorgio,

6
@scrwtp - e Agile è più simile a "Il mio cliente non sa cosa vuole, e non può / non parla e non lo pensa, e cambia idea ogni 5 minuti. Devo spingere qualcosa in faccia per ottenere risposte significative ". Wow. Sembra davvero sfortunato quando lo scrivo.
Michael Kohne,

1
@scrwtp: Penso che la domanda da un milione di dollari sia: è questa "convinzione" che puoi "sederti e discuterne e concordare" fattibile? La risposta è: dipende, giusto? Dipende da una serie di variabili: quanto è grande il progetto? Sappiamo anche quanto è grande? Quanto tempo i clienti devono "sedersi" con noi? Abbiamo tentato per decenni di mettere in relazione lo sviluppo del software con la costruzione, che è quasi prescrittiva al 100%. Lo sviluppo del software si trova a metà strada tra "totalmente reazionario" e "100% prescrittivo". Nella maggior parte dei negozi, è più vicino al "totalmente reazionario", quindi all'adozione agile.
Calphool,

21

Inizi dicendo:

Le due filosofie di sviluppo software predominanti sono a cascata e agili.

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

Uso OPEN / Metis e le sue varianti da oltre 10 anni con grande successo. Non è sicuramente agile, e sicuramente non è una cascata. Migliaia di sviluppatori creano software estremamente complessi per aeromobili, sistemi critici per la vita, banche, ecc. Utilizzando metodi non agili ogni giorno.

Quindi sì, ovviamente c'è una valida alternativa all'agile.


6
Non riesco a capire rapidamente cosa sia OPEN / Metis da quel link. (Di solito non è necessario scaricare una metodologia.) La mia domanda è: qual è la sua filosofia, in particolare per quanto riguarda il cambiamento? Tenta di minimizzare il cambiamento o di ridurre il costo del cambiamento? Ricorda che la mia domanda riguardava la filosofia agile, non le pratiche agili.
Eric Wilson,

OPEN / Metis ha un ciclo di vita iterativo che costruisce i sistemi in modo incrementale. Il cambiamento è riconosciuto come qualcosa che non solo accade, ma che è grandioso quando accade, poiché lo scopo stesso dello sviluppo di un sistema di informazione è quello di effettuare alcuni cambiamenti. Il costo del cambiamento, tuttavia, è controllato e gestito attraverso un ciclo di vita adeguato e pratiche associate.
CesarGon,

1
Per quanto riguarda la tua osservazione sul "download di metodologie", beh ... non scarichi metodologie, sono d'accordo. Scarica documenti che descrivono metodologie. Altrimenti, come li apprendi? Guarda le miriadi di libri che descrivono XP, Scrum, ecc.
CesarGon,


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 ad un approccio a cascata (o anche più rigoroso), se possibile risolvere tutti i problemi in anticipo (o BOOM!).

Stai costruendo l'ultima interfaccia utente di marketing 2.0 / 3.0 / buzzy? Agile è un modo molto migliore di procedere (hai bisogno di feedback e modifiche rapidi).

Esistono quelli che definirei principi di artigianato del software che possono essere ancora applicati indipendentemente dalla metodologia, ad esempio:

  • Controllo della fonte
  • build e CI
  • programmazione in coppia
  • TDD
  • Io do un ^% $$ &

e altro ancora

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


La cascata funziona se te lo puoi permettere. Qualcuno sopra ha affermato che il costo del software del progetto luna della NASA era di circa $ 1000 per riga di codice. La maggior parte dei negozi ha bisogno di qualcosa come $ 1–10 per riga di codice e agile è meglio per quel tipo di situazioni. Tuttavia, non pretendo che l'agile offra una migliore qualità complessiva. Fondamentalmente si riduce a puoi permetterti di pagare un sacco di soldi per essere abbastanza sicuro che il software sia corretto o è più economico capire la soluzione una volta scoperto che il software non è corretto.
Mikko Rantalainen,

2

Il problema deriva dalla complessità del software. Waterfall funziona alla grande per cose come la costruzione di ponti e pavimentazioni stradali perché la fisica non cambia mai. Certo, a un certo punto svilupperemo un nuovo asfalto ma non rivoluzionerà il modo in cui le strade sono costruite. L'acciaio nelle sospensioni di un ponte ha le dimensioni giuste oppure non lo è. Non è possibile eseguire il kludge o lo stub di un vero progetto di costruzione come con il software.

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

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

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

Il cambiamento è inevitabile. La natura stessa della programmazione estende la lingua con classi e metodi personalizzati, cambiando così la lingua stessa. Non puoi farlo in nessun altro tipo di disciplina ingegneristica (come la costruzione di strade. Non inventi nuovi marciapiedi solo per pavimentare una strada in Kansas sulla California).

Il metodo agile offre anche una piattaforma per la gestione di versioni future e correzioni di bug. Hai anche gli strumenti di gestione, i processi, i dipendenti formati, per lo sviluppo di software con versione. Con un metodo a cascata, dovrai riqualificare la tua squadra per gestire anche piccole correzioni di bug.

comunque, i miei 2 centesimi.


2
Ci sono molti aspetti della progettazione del software che sono assoluti come le leggi della fisica. Agile è uno strumento proprio come la cascata o altre metodologie e, come altre persone hanno pubblicato, ci sono molti casi aziendali in cui non ha senso. Sarei sorpreso se ti vedessi in fila per salire su un aereo dove Boeing ha detto che erano nel mezzo di un processo agile sul software di controllo di volo e avevano bisogno che i clienti facessero l'iterazione se l'aereo non si ribalta a mezz'aria per no Motivo.
Hounshell,

E solo per sparare più buchi nella tua discussione, ci sono progetti stradali in fase di progettazione in questo momento che sarebbero appropriati per una strada tra Kansas e California, ma non tra New York e Boston. E nuove tecniche per la gestione dell'asfalto stanno venendo fuori continuamente.
Hounshell,

2
E infine, dici "Con un metodo a cascata, dovrai riqualificare la tua squadra per gestire anche piccole correzioni di bug". È così ignorante come funziona il processo a cascata. Dovresti provare un buon negozio a cascata prima di salire in tribuna su quanto sia inappropriato per ogni scenario di sviluppo software.
Hounshell,

1
Ciao Stephan, non tutti i requisiti software cambiano costantemente.
Paul Nathan,

1
Gli affari cambiano sempre ; un'azienda che non sta cambiando e adattandosi è un'azienda che sta morendo. Il tempo è una costante , che non interagisce bene con il cambiamento. Un sistema che ha la filosofia che riconosce il cambiamento è atteso può accogliere il cambiamento, altrimenti il ​​tempo deve adattarsi al cambiamento ed è una costante non nascente!

2

Per rispondere alla domanda, esiste un'alternativa praticabile, forse per il software 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 usare un approccio one-shot?

Ma poiché il software ha zero costi di duplicazione, perché mai dovresti fare la stessa cosa due volte? Il software tende alla produzione. Quindi, se tutto il software è la creazione di nuovi prodotti, allora operiamo sempre in un dominio complesso in cui, in una certa misura, non sappiamo cosa stiamo facendo. Oppure è costoso conoscerlo in anticipo ed è più economico scoprirlo facendo. In un dominio complesso e rischioso, vorrei provare esperimenti, incrementare e iterare.

Le centrali nucleari e i sistemi fly-by wire sono spesso indicati come esempi di software che vorresti fare a cascata. Ma il sistema avionico della navetta non è stato sviluppato in modo iterativo? Come sono stati i sistemi di controllo del traffico aereo canadesi e statunitensi?

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


2
Quindi ora agile sta cercando di prendersi il merito per iterativo e incrementale? Non importa che iterativo e incrementale siano stati CORE parti dello sviluppo delle cascate da quando ho iniziato lo sviluppo nel '92.
Dunk

1

Il metodo Waterfall è certamente praticabile ed è filosoficamente valido come qualsiasi altro approccio. Ricorda che Waterfall è in circolazione da molto più tempo di Agile, ma nota che questo non è un argomento per affermare se una metodologia è migliore di un'altra.

Si utilizza il metodo Waterfall quando si ha una comprensione molto chiara dell'intero dominio problematico e di ciò che il cliente desidera ottenere in un pacchetto software. Probabilmente hai sottoscritto un prezzo fisso al momento della stipula del contratto e il tuo cliente comprende che non può deviare da alcun requisito concordato. Il tuo processo è strettamente quello che attraversa una serie di firme tra le varie fasi di sviluppo, ed è spesso il caso in cui ogni fase è completata da un team diverso - a volte anche da una società diversa - ognuna delle quali potrebbe non necessariamente contatto con gli altri. Spesso vedi Waterfall applicato con buoni risultati nei progetti militari e governativi quando vengono offerti ad appaltatori esterni. Dove Waterfall e altri approcci simili hanno una cattiva reputazione è quando gli sviluppatori incontrano problemi, come una stima scadente, pianificazioni pianificate senza tempo di contingenza o una comprensione scarsa o incompleta del dominio problematico. Il problema non è mai veramente un difetto 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 vedere come si sviluppa lo sviluppo di software. Una metodologia è semplicemente uno strumento e come tale il suo valore sarà sempre inferiore agli individui e alle interazioni che sono al centro di ciò che significa essere Agili .

Qualcuno pensa davvero che ridurre al minimo i cambiamenti nel software sia un'opzione praticabile per coloro che desiderano fornire software prezioso?

Ogni opportunità di minimizzare il cambiamento è preziosa sia per lo sviluppatore che per il cliente. Le modifiche possono causare lo slittamento di una pianificazione o l'esclusione delle funzionalità per soddisfare una pianificazione. È il modo in cui gestisci gli effetti del cambiamento che incidono sul valore dei tuoi progetti.

Oppure la domanda su quale tipo di pratiche funziona meglio nelle nostre situazioni per gestire l'inevitabile cambiamento?

Le tue pratiche potrebbero aiutarti nella gestione del cambiamento o potrebbero ignorare completamente il cambiamento. Ciò che conta è la combinazione delle tue pratiche di sviluppo, la gestione delle tue relazioni con i tuoi clienti e se queste cose collaborano efficacemente per tutte le parti coinvolte.

Quelli di noi che sono a tutti gli effetti Agile capiscono che scegli un metodo che funziona per te. Se ti piace un approccio particolare, seguilo. Se non si adatta perfettamente alle tue esigenze, modificalo. Il modo in cui costruisci il software si riduce davvero a cercare di sfruttare al meglio le risorse che hai a portata di mano e a minimizzare quelle pratiche che possono portare il tuo progetto verso il fallimento, e spesso scopri che devi cambiare il tuo metodo per adattarlo al progetto particolare a portata di mano.

Una cosa è dire "Ok, quindi ora siamo Agili", e un'altra è vivere e lavorare secondo la filosofia di Agile. Che tu usi Waterfall, Incremental, Spiral, SCRUM, XP, FDD o qualsiasi altro metodo, sei sostanzialmente Agile dove apprezzi:

  • Individui e interazioni su processi e strumenti
  • Software funzionante su documentazione completa
  • Collaborazione con i clienti sulla negoziazione del contratto
  • Rispondere al cambiamento seguendo un piano

e dove riunisci i tuoi strumenti, il tuo metodo e la tua esperienza per applicare questi valori con successo.


2
Wow. Ci sono così tante cose strane qui. La cascata è praticabile sulla base di essere in giro più a lungo? La cascata è giustificata sulla base dell'uso nei contratti di difesa? Ogni opportunità per ridurre al minimo i cambiamenti è davvero nel miglior interesse del cliente o porta a offrire ciò che pensava di voler piuttosto che ciò che realmente desiderava? Dato che sembra che ti interessi a questo, ho cercato di capire da dove vieni, ma mi manca qualcosa.
Eric Wilson,

1
@EricWilson Waterfall è in circolazione da più tempo e viene utilizzata con successo molto prima della discussione della filosofia Agile. È praticabile perché esiste e quando applicato funziona correttamente per coloro che desiderano utilizzarlo. Non ho giustificato il suo utilizzo, ma ho semplicemente indicato un esempio in cui ho avuto un'esperienza personale in cui l'ho visto funzionare, e sì, ho visto anche alcuni fallimenti spettacolari. Non cerchi opportunità per minimizzare il cambiamento, vuoi opportunità per introdurre il cambiamento, ma devi farlo in modo sensato, altrimenti il ​​tuo cliente o ottiene meno di quanto desiderasse o una scadenza scaduta.
S.Robins,

0

Sì, Waterfall, Spiral, Iterative e altri modelli di processi ibridi sono tutti praticabili, ma il cambiamento è inevitabile. Il processo è molto più di come gestire il cambiamento e (lo sostengo) il principale fattore determinante è la conoscenza / comprensione del problema e la precisione con cui è possibile pianificare e prevedere.

Affermare che "le due metodologie di sviluppo del software predominanti sono a cascata e agili" è disingeno, in quanto esiste uno spettro 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 praticabili allo sviluppo del software. Sebbene Waterfall e Agile tendano a cadere alle estremità opposte dello spettro del "cambiamento", è ragionevole definire queste metodologie concorrenti come,

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

Agile dice: il cambiamento è inevitabile, quindi rendilo economico.

Ma questa 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. Ricordi il triangolo buono - veloce - economico? Aggiungi una quarta dimensione, processo e scopri che ridurre lo sforzo del processo può anche comprimere il programma, quando le stime risultano errate e un progetto rischia di ritardare. Il software è un processo fungibile (mutabile) e Agile, Iterative, Spiral offrono tutti la possibilità di fornire funzionalità incrementali a intervalli più brevi.

Waterfall e altri modelli di processo guidati dai requisiti dispongono di controlli per la gestione delle modifiche, pertanto non è corretto affermare che Waterfall riduce al minimo le modifiche, è più preciso affermare che Waterfall riconosce e gestisce le modifiche e comunica l'impatto di tale modifica (poiché la modifica provoca un impatto sulla pianificazione quando l'utente avere requisiti e progettare in anticipo). Quando si crea un prodotto o è necessario definire i requisiti (funzionalità) in modo completo, si viene guidati verso uno dei modelli ibridi.

E quando le stime sono errate, spesso il processo (la quarta gamba del triangolo di ferro) viene sacrificato per rispettare il programma.


Non ero disonesto. Dopo cinque anni di sviluppo in diverse aziende, ne ho incontrate solo due e una è nominata solo come un peggiorativo. Spirale? Non ne ho mai sentito parlare.
Eric Wilson,


Volevo dire che non li avevo incontrati nel mondo reale. C'è un sacco di cose là fuori negli interwebs, ma non ho intenzione di iniziare a dar loro la caccia ora solo perché mi è capitato di porre una domanda nel 2010.
Eric Wilson,

-1

Gli approcci maturi di agilità e 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 l' intera azienda , è necessario esaminare quale approccio fornirà la minima quantità di attrito all'adozione. Alla fine brevi cicli di sviluppo, un solido team di controllo qualità e un'azienda che guida lo sviluppo sono ciò che è più importante per la produzione di software di alto livello.


1
Vorrei mettere un avvertimento al tuo commento. La cascata richiede persone di talento o cadrà sulla sua faccia. Imparare a progettare bene è difficile. Imparare a programmare è relativamente semplice. IMO, questo è il motivo principale per cui la maggior parte degli sviluppatori sembra preferire l'agile.
Dunk

4
Posso dire lo stesso di agile. Gli sviluppatori Jr. senza guida possono fare un casino agile con una rapidità.
Charles Lambert,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.