Progettazione software predittivo vs reattivo

Question

So che per me ho iniziato a seguire il metodo a cascata della gestione dei progetti e insieme a ciò sono andato con l'approccio predittivo alla progettazione del software. In questo voglio dire che avevamo enormi pacchetti di documentazione, UML, schemi di database, dizionari di dati, flussi di lavoro, diagrammi di attività, ecc.

Avendo lavorato nel software da oltre 10 anni, trovo molto più realistico avvicinarmi al software design da un approccio Reattivo. Seguo spesso un approccio scrum alla gestione dei progetti e con questa documentazione molto poco pesante viene mai generata. Abbiamo pochissime specifiche del flusso di lavoro (sebbene abbiano ancora l'uso). Questo è un approccio molto più dinamico alla creazione del software. Ovviamente, con il frequente processo di refactoring man mano che il tempo passa scopriamo nuove funzionalità nel tempo che, se avessimo pianificato per il futuro, avremmo cambiato le cose in modo drammatico.

La grande differenza per noi è che il primo approccio richiede più tempo, sembra fallire più frequentemente in un mondo di costruzione di software e non è altrettanto flessibile. Il secondo approccio offre maggiore flessibilità, ci rende più consapevoli di errori più rapidi (in modo che possiamo correggere più velocemente) e fornisce una qualche forma di funzionalità alla fine di ogni iterazione.

Conoscendo entrambe le parti dall'esperienza, trovo ancora molte persone che AMANO l'approccio a cascata sull'approccio agile per lo sviluppo del software. Non capisco

domanda: Perché qualcuno dovrebbe usare la cascata su una qualche forma di agile con tutta la ricerca di supporto agile? Quali sono gli argomenti forti per l'utilizzo di cascata su agile?

Answer 1

Il mio capo mi dice di.

Sospetto che molte persone non abbiano scelta ei vecchi capi non imparino nuovi trucchi.

Answer 2

Quando ho iniziato a programmare (con COBOL non meno), waterfall era l'approccio "nuovo". Oggi, ti direi che uso una metodologia agile cascante. Per i sistemi più grandi, trovo che un avvio a cascata funziona meglio. Non creare documenti enormi (è una perdita di tempo IMO), ma piuttosto prendere provvedimenti come la creazione di un prototipo UI e/o casi d'uso per capire a fondo il problema del business. Una volta che ci sentiamo a nostro agio, abbiamo risolto il problema e abbiamo una solida comprensione, ci muoviamo in una modalità di sviluppo agile.

Per rispondere alla tua domanda, penso che il motivo principale per cui la cascata si aggira è che a molte persone non piace il cambiamento. È spaventoso cambiare e passare da una cascata all'altra è un grande cambiamento.

Answer 3

Se si conoscono esattamente i requisiti che non sono mai chagen, se si sa per quanto tempo ogni passaggio richiederà e se si conoscono tutte le risorse disponibili al momento necessario, è possibile eseguire una cascata e funzionerà. Ma in realtà questi tipi di progetti sono piuttosto rari e penso che non ne farò mai parte.

Answer 4

Quando si progettano sistemi da utilizzare da parte degli utenti finali, agile spesso funziona bene perché i requisiti potrebbero non essere corretti e gran parte del processo riceve feedback dagli utenti sotto forma di una versione utilizzabile.

Tuttavia, quando si crea un software che si interfaccia con altri software, spesso i requisiti possono essere elaborati in modo molto chiaro. In questo caso è spesso più produttivo assicurarsi di avere una specifica molto chiara e precisa, test unitari In questo modello è anche possibile generare stime di lavoro abbastanza buone e ci sarebbe molto più costo per usare il modello agile.

Answer 5

Penso che una parte del motivo per cui le persone spesso si aggrappano alla cascata è che dà l'illusione del controllo.In una cascata, puoi fare abbastanza lavoro in anticipo per mettere insieme una bella agenda che affronta in modo appropriato ogni evenienza che ti viene in mente, e quindi dare una roadmap dettagliata per il futuro a chiunque sia sul lato business che chiede quando la feature X sarà a disposizione.

Il problema è che non si può quasi mai seguire quel piano per la lettera, e si è quasi sempre in ritardo/cadere le funzionalità. Tuttavia sin dall'inizio, sembra molto controllato e gestibile.

Sono un grande fan di Agile, ma quello con cui ho sempre avuto a che fare è la roadmap/previsione a lungo termine che viene spesso richiesta dalle persone addette alle vendite e al marketing. Penso che l'illusione della certezza della cascata sia molto confortante per i manager e gli uomini d'affari.

Answer 6

Non schierarsi, ma praticamente qualsiasi ricerca non sarebbe scientifica.

Tu dici (corsivo è mio)

domanda: Perché qualcuno dovrebbe utilizzare cascata su una qualche forma di agile con tutto il supporto di ricerca agile? Quali sono gli argomenti forti per l'utilizzo di cascata su agile?

ma non collegare a nessuno studio.

È una di quelle cose che sono note per essere estremamente difficili da testare. Non puoi avere due team identici che lavorano sullo stesso progetto contemporaneamente, perché non esistono due squadre identiche. Non è possibile avere la stessa squadra completare la stessa attività due volte di seguito utilizzando due diverse metodologie senza il primo passaggio che macchia la seconda. Non ho mai sentito di nessuno che progetta uno studio sperimentale (o anche statistico) che possa argomentare in modo convincente per qualsiasi metodologia di sviluppo del software. Sarei interessato a vederne uno, se hai un link.

In mancanza di prove reali, si riduce alle preferenze personali. Quali sono gli argomenti forti per il cioccolato rispetto alla vaniglia?

Answer 7

Farò l'avvocato del diavolo e dichiaro che l'agilità è imperfetta è quasi altrettanti modi del metodo a cascata. Non sono uno di quelli che adorano il metodo a cascata, ma non amo neanche l'agile.

La mia esperienza con l'agile non è stata molto positiva. Per essere onesti, l'ho usato in un ambiente aziendale, che ha reso il servizio "agile" mentre aspettavo ancora che il nostro manager producesse in anticipo traguardi e traguardi a lungo termine.

Tuttavia, ho trovato che le metodologie agili (scrum in particolare) spesso nascondono problemi importanti con il design. Mentre la cascata dà ai manager l'illusione del controllo, agile sembra fare lo stesso per i team di sviluppo. Ho visto team in cui sollevare qualsiasi problema che non si trova nello sprint corrente/iteraton è disapprovato, con l'aspettativa che verrà gestito "in tempo". Richiede solo alcune importanti decisioni di progettazione per essere ignorato per il futuro del progetto, mentre le iterazioni correnti vanno senza intoppi e l'aspetto del progetto è sulla buona strada.

Si può sostenere che la squadra è in errore per non aver compreso lo spirito dell'agile, ma mi piacerebbe vedere metodologie migliori che incorporano le parti migliori dell'agile.

Answer 8

Il titolo dice tutto. (In realtà: proattivo vs reattivo). Perché scegliere il modo reattivo e rinunciare al controllo a meno che non sia necessario? La cascata non è l'unica alternativa, puoi avere qualsiasi tipo di processo di sviluppo ciò che raffini quando vuoi. Il controllo è la chiave.

È uno spettro tra la cascata su un'estremità e il totalmente reattivo, a zero i metodi di documentazione sull'altra estremità. Se lavori nel settore dei consulenti per clienti potenti (e solitamente indecisi), devi ricorrere a metodi reattivi. Se sviluppi software di termoretraibilità, puoi pianificare in anticipo e gestire le conoscenze. Alcuni progetti richiedono anche tonnellate di specifiche e regole, in cui il codice e l'approccio corretto non lo riducono. Per me l'ingegneria del software riguarda principalmente la gestione e la progettazione della conoscenza, la codifica è al secondo posto.

P.s non esiste una cosa come il prezzo agile e fisso. Non nel modo classico di solito vendono il metodo. Vedere http://martinfowler.com/bliki/FixedPrice.html

Answer 9

comportamento retroattivo

Answer 10

Se si dispone di un team di poche decine di persone che hanno nel corso di un decennio, raffinato la strategia cascata al punto che funziona bene per loro, chi sei tu per venire e dire "Stai sbagliando ..."? Davvero, se sta lavorando per loro, perché cambiare le cose? Sì, questo è semplicemente capovolgere la domanda, ma penso che potrebbe essere un punto valido.

Answer 11

Uno dei presupposti di (almeno) XP è che il cambiamento è economico. Il modello a cascata è stato costruito sui principi che cambiano, ogni cambiamento è costoso. L'ipotesi nel modello a cascata è che una volta che il software è stato scritto, cambiarlo è più costoso che investire il tempo in anticipo per arrivare a una comprensione "completa" del problema.

L'esperienza sembra indicare che è molto difficile arrivare a una completa comprensione del problema e che se vengono prese alcune precauzioni (ad esempio il Test di unità) il cambiamento può diventare molto più economico. Pertanto, se si verifica un problema in cui alcune premesse agili non sono valide, altri approcci potrebbero diventare nuovamente fattibili. Tra Cascata e Agile c'è almeno lo sviluppo Spirale che è - una sorta di - ciò che pratichiamo.

Answer 12

Nel mio team abbiamo scoperto che con i progetti di manutenzione (che è la maggior parte di ciò che facciamo) dove stiamo modificando o sostituendo come con simili, non c'è sempre più bisogno di input da parte dell'utente, magari forse qualche interfaccia utente prototipi.

In tal caso, soprattutto dato che ci sono accordi commerciali coinvolti, l'approccio a cascata a livello macro può adattarsi bene. Anche allora ci piacciono ancora gli approcci incrementali/agili a livello di implementazione.

Vale la pena notare che la maggior parte dei nostri clienti è costituita da grandi organizzazioni di legname che si innamorano delle loro scartoffie, in modo tale da aggiungere ancora più slancio a noi almeno per apparire loro tradizionali.

Answer 13

La documentazione generata durante il processo a cascata consente un sacco di CYA. Puoi puntare le dita quando un progetto esce dai binari. Pochissimi dirigenti stanno andando bene con "oh, beh, immagino che quel progetto sia stato lontano da noi! Beh, almeno lo abbiamo scoperto presto, nessun danno, nessun fallo!"

Inoltre, i documenti di progettazione possono generare automaticamente piani di test, utile per il controllo qualità.

Answer 14

È necessario essere abbastanza predittivi per consegnare la merce. Devi essere abbastanza reattivo per affrontare i problemi.

Una volta sono stato bloccato con sei mesi per completare un progetto stimato in un anno, e in base all'esperienza passata l'esperienza avrebbe richiesto due. Così ho trascorso tre mesi a studiare metodologie. Abbiamo finito in tempo (in tre mesi), utilizzando le parti appropriate di un processo a cascata.

Alcuni punti che hanno reso il lavoro methodoly: - Creare uno standard di uso, aggiornarli quando necessario. - Costruisci librerie: fallo una volta, fallo bene, risolvilo senza rompere il codice esistente. - Basta documentazione. - La versione controlla tutto ciò che puoi. - Rompi le cose; un metodo dovrebbe gestire il lavoro o lavorare. - Aumentare la coesione, ridurre l'accoppiamento, riutilizzare. - Compra o costruisci gli strumenti che ti servono. - Tieni traccia dei tuoi problemi e progressi.

Un altro progetto in cui ero coinvolto era un progetto di sei mesi. Non sono stato coinvolto fino a un anno e mezzo dopo l'inizio. Il lead di sviluppo era stato assunto a un markup estremo mentre stava lasciando una carriera con un piano pensionistico. All'inizio del progetto ha chiesto al project manager: "Vuoi che lo faccia nel modo giusto o essere reattivo?" Riuscite a indovinare la risposta? La settimana in cui sono stata coinvolta la stessa funzione è stata implementata lunedì, mercoledì e venerdì. Indovina cosa è successo martedì e giovedì?

La forza in Agile è la sua enfasi su abbastanza, appena in tempo. La forza del metodo cascata è che copre tutte le cose a cui devi pensare. Devo ancora lavorare su un progetto che ha fatto o avrebbe dovuto fare tutti i passaggi. Ho lavorato su molti progetti che hanno fatto dei passi che avrebbero dovuto essere fatti su base aziendale.

Answer 15

È piuttosto comune quando si offre un contratto che una delle condizioni rivestite di ferro è che segui il loro "processo" che in fase di ispezione è cascata.