Come sopravvivere in un mondo a cascata? [duplicare]

Raccogli i requisiti dei clienti migliori e più specifici.

Quando perfezioni i requisiti fino al punto in cui ogni requisito può essere soddisfatto con una manciata di classi, e hai una buona idea di come appariranno queste classi nel codice, diventerà molto più chiaro per quanto tempo le cose andranno prendere, e sarà molto più facile dichiarare il successo su ogni requisito.

I tuoi requisiti dovrebbero includere specifiche dettagliate di tutte le interfacce tra i componenti, in modo che sia chiaro a ogni sviluppatore di software esattamente quello che devono fare, e sarà più facile dividere il lavoro o spostare il lavoro da uno sviluppatore ad un altro.

Una cosa che potresti voler spingere sono cascate più piccole. Rompere il progetto in fasi aiuterà tutti fornendo punti di controllo in cui è possibile monitorare i progressi e ottenere feedback dagli stakeholder (molto come si farebbe con agile). Agile riesce dove fallisce la cascata perché spesso la cascata morde più di quanto puoi masticare.

Per essere più bravo a fornire l'elenco delle attività e il tempo che impiegano, è necessario esercitarsi e registrare i risultati. Quindi, prima di tutto, fai in modo che ogni stima sia abbastanza dettagliata (non dimenticare di includere comunicazioni e riunioni, sviluppo dei requisiti, progettazione, test, qa, implementazione, documentazione (sempre necessaria in cascata), ricerca e altri compiti non codificanti. è sbagliato stimano solo il tempo di codifica reale. Pensa, "Beh, mi ci vorranno circa 2 giorni, quindi questa è la stima" e 12 ore di riunioni dopo, non hai nemmeno iniziato a sviluppare.

Quando dai un preventivo, lo memorizzi e il tempo da qualche parte e quando esegui il progetto, segna per quanto tempo ogni attività ha effettivamente preso. Presto vedrai uno schema (la maggior parte delle persone stima costantemente troppo basso). Avrai anche i dati per dire a che ora prendono le cose. Diventa più difficile discutere con le tue stime quando si basano su numeri difficili di ciò che è stato necessario per attività simili in passato.

In un progetto a cascata, si può presumere che ci saranno cambiamenti dell'ultimo minuto, quindi stimare una percentuale di tempo speso anche su questo! Se un'attività è nuova (non hai attività simili nella cronologia), ricorda di aggiungere più tempo per la ricerca e la progettazione, perché probabilmente sarà necessario più tempo per capire cosa fare.

In un progetto a cascata, la cosa migliore che puoi fare per te e il tuo team è di far scivolare la scadenza e aumentare la stima ogni volta cambiano il requisito dopo la fase di definizione dei requisiti. Se ottengono costantemente nuovi tuoi pronostici che dicono loro quanto costerà quel piccolo cambiamento, ridurrai il numero di "Oh tra l'altro" e cambierai drasticamente. Devi gestire il cliente in un grande progetto.

E passa il tempo in anticipo nello sviluppo e nella progettazione dei requisiti. Questo è lo scopo di un progetto a cascata poiché è molto più economico cambiare le cose a quel punto che dopo aver svolto il lavoro di sviluppo. Esistono tipi di progetti più adatti alla cascata che agili. Quindi non pensate automaticamente che sia cattivo che lo si usi. Impara invece a usarlo bene per gestire i progetti. Se impari a gestire bene la cascata, sei in testa alla maggior parte degli sviluppatori in cascata o in ambienti agili perché la verità è che molti sviluppatori sono pessimi in tutto ciò che riguarda la gestione di un progetto e ottenere progetti in base al nome del gioco. p>