Non riesco a vedere come un progetto software possa compiere progressi significativi con una metodologia a cascata se i requisiti non possono essere chiaramente definiti sin dall'inizio. Mi sto perdendo qualcosa?
Utilizziamo waterfall e abbiamo completato molti progetti con requisiti in evoluzione. La cascata non è così male come è stata concepita e Agile non è il proiettile d'argento che corregge tutto (come molti progetti agili mal fatti come progetti a cascata, per quanto posso vedere.) Nessuna delle due metodologie ha un tasso di successo particolarmente alto , in parte perché gli utenti non sanno come definire ciò che vogliono e in parte perché ci sono molti incompetenti nel nostro campo.
Il commento di "Andrew" sopra è valido. Inoltre, quale parte dei requisiti è mancante. La metodologia cascata non è rigida come alcuni pensano che sia. La cascata si concentra sullo spostamento tra le fasi principali dopo che sono state raccolte sufficienti informazioni e fatti. Non c'è nulla che ti impedisca di perfezionare le tue analisi finché non ne stai rielaborando parti importanti.
Ad esempio, è possibile avviare la progettazione senza conoscere tutti i report richiesti e avviare la progettazione senza conoscere tutte le regole di convalida. Tutto questo può sempre essere aggiunto in seguito.
Tuttavia, non si desidera avviare il progetto con solo 1/3 delle colonne nel database identificato. La caduta d'acqua è una grande metodologia ed è abbastanza adatta per la maggior parte delle applicazioni in cui l'azienda non viene inventata da zero e dove gli utenti conoscono il business.
Puoi progredire nella progettazione del tuo database, nella progettazione dello schermo, nell'architettura di sistema, negli use case e altro ancora senza conoscere tutti i dettagli.
L'arte qui sta dividendo il problema a pezzi che possono iniziare e progredire con meno dipendenza da altre aree grigie. Questo è un approccio generalmente valido indipendentemente dalla metodologia utilizzata.
Dipende da quanto sono buoni i programmatori.
Se i programmatori hanno una buona conoscenza del business su cui stanno lavorando e se sono abbastanza intelligenti da scrivere il codice in un modo non strettamente accoppiato, quindi verso la fine della cascata quando i clienti vedono il prodotto dovrebbero: / p>
a) non ha molto di cui lamentarsi
e
b) ciò di cui si lamentano può essere facilmente modificato e corretto
Devi essere buono per farlo funzionare comunque!
Non ho mai sentito di un progetto che utilizza una metodologia a cascata che non includeva gli ordini di cambiamento. Quindi, in pratica, se i requisiti iniziali sono sbagliati (sono sempre in qualche modo sbagliati tranne forse in un piccolo progetto - non li ho mai visti perfettamente al 100%) hai solo ordini di cambiamento e rifai tutto ciò che devi fare. Significa che non è davvero cascata? È davvero una domanda filosofica.
Può avere successo? Può, ma la metodologia non è così focalizzata sull'affrontare i requisiti in evoluzione, quindi potrebbe anche non farcela.
In realtà, quello che ho visto molto è che quando i requisiti non sono precisi, la cascata riesce piuttosto bene per gli sviluppatori di software, non per i clienti. Il motivo è che la maggior parte delle volte è stata adottata una metodologia di cascata, in primo luogo perché il cliente, abbastanza ragionevolmente, voleva sapere esattamente cosa sarebbe costato il progetto. Sfortunatamente nessuno sa quanto costerà un progetto software. A volte i clienti non lo capiscono mai e rifiutano di assumere qualcuno che non gli dia un prezzo fisso. Dal momento che a quel punto gli sviluppatori che cercano di ottenere l'attività del cliente sono in competizione principalmente sulla base di un prezzo basso, sottostimano e sperano di trarre profitto dagli ordini di cambiamento, che coprono qualsiasi cosa oltre i requisiti iniziali e di solito comportano un alto tasso orario.
Pertanto, quando i requisiti sono cattivi, ciò significa che gli sviluppatori ottengono più della parte redditizia del contratto (ordini di cambiamento) e meno della parte non redditizia (l'elenco di requisiti che il cliente pensava di volere indietro quando tutto questo è iniziato).
Ma alla fine i veri requisiti vengono scoperti e le modifiche apportate, quindi per il cliente "riesce" nel senso di essere fatto, anche se a costi più elevati in termini di tempo e denaro rispetto a quando i requisiti erano corretti inizialmente.
Quindi mi piace personalmente Agile per due motivi principali: in primo luogo allinea gli interessi del cliente e dello sviluppatore meglio del "è un ordine di cambiamento?" le battaglie a cascata possono portare a, e in secondo luogo perché i risultati frequenti aiutano a mitigare i rischi. Ma "pagaci e cercheremo di scriverti un po 'di software, ma non sappiamo ancora quanto guadagnerai per i tuoi soldi" a volte è una vendita difficile, anche se in realtà ammette solo la realtà soggiacente della situazione .
I requisiti non chiaramente definiti non danneggiano automaticamente il progetto, IMO. La probabilità di fallimento è alta, ammetterò anche se ci possono essere casi in cui riesce ancora.
Può. Devi solo creare un imprevisto nelle tue stime iniziali e spiegare che se i requisiti sono incerti, lo sono anche le tue stime. Se i requisiti stanno arrivando allo stesso ritmo in cui lo sviluppo sta progredendo, funzionerà perfettamente.
Ricorda che Waterfall non è l'opposto di Agile. Tutto quello che stai dicendo è che non fornirai componenti in modo incrementale. È solo "darci le tue esigenze non appena puoi e codificheremo, consegnandoti un prodotto alla fine, ma se non ci porti abbastanza velocemente i requisiti, il tuo prodotto verrà posticipato".
Tuttavia, Scrum è progettato per gestire l'incertezza e il cambiamento e continuo a pensare che sia il modo migliore per andare. Sto solo dicendo che se il cliente non è interessato, ciò non significa che sei sicuro di fallire.
Consentitemi di raccomandare di leggere "Death March" di Ed Yourdon. Una volta che ti rendi conto che non sei l'UNICO che lavora in condizioni non ideali, è davvero utile e motivante. Detto questo, non mi ha nemmeno dissuaso dal porre domande scomode - come perché stiamo codificando senza requisiti chiaramente definiti?
La circostanza per il successo nel rispondere alla domanda su quanto tempo ci vorrà per costruire qualcosa che né tu né il cliente capisci è dire che ci vorrà molto più tempo di quanto pensi. Metti in mesi, o anni di allentamento se necessario.
Leggi altre domande sui tag project-management requirements waterfall