Come scegliere un metodo di sviluppo?

Esiste qualcosa come un continuum tra metodi agili e il vecchio, rigido, strongmente formale approccio "a cascata". Più ti allontani dallo sviluppo agile, più aggiungi struttura e design al tuo processo di sviluppo.

Questo significa che avvicinandoti a un modello a cascata avrai bisogno di designer più esperti, di programmatori più esperti e di manager di progetto più laboriosi. Ancora più importante, più ti avvicini a un modello a cascata, più hai bisogno di clienti conosciuti

I clienti sono probabilmente il fattore decisivo. Se hai un cliente che non sa realmente di cosa ha realmente bisogno o che vuole, sei praticamente costretto ad adottare un modello di sviluppo che sia in grado di adattarsi a una grande quantità di cambiamenti. Questo di solito è il caso dello sviluppo web, per esempio. Se hai un cliente strongmente tecnico, maturo e ben informato, come di solito accade nel campo dello sviluppo integrato, di solito ti viene richiesto di adottare un metodo strongmente formale (qualcosa come una cascata).

I programmatori sono un altro importante punto di selezione. In realtà non è possibile adottare un metodo strongmente formale con un gruppo di lavoratori part-time universitari. Più hai bisogno di un approccio formale ("cascata" come esempio estremo), più avrai bisogno di programmatori esperti con un ampio e strong insieme di competenze.

Il tipo di sistema sviluppato è meno rilevante. Ci sono applicazioni web così complesse che hanno bisogno di un modello di sviluppo molto simile a quello usato dalla NASA per andare sulla Luna (Amazon.com, per esempio) e sistemi embedded così semplici che un singolo programmatore universitario può svilupparlo in poche settimane da solo con qualsiasi metodo di sviluppo (come molti progetti di giocattoli basati su Arduino).

Nonostante ciò, di solito i sistemi che implicano un qualche tipo di dipendenza hardware (sistemi incorporati di qualsiasi tipo) richiedono un approccio strongmente formale perché ogni errore verrà pagato in $ o € dalla società in via di sviluppo.

Questo è un altro continuum: più ti allontani dall'hardware, meno hai bisogno di un approccio formale. Più ti allontani dalle cose legate al denaro (sistemi bancari, sistemi di e-commerce, POS, ecc.), Più puoi avere un approccio agile e iterattivo. Il limite è probabilmente rappresentato dal tipico brochureware web-based in cui non è effettivamente necessario alcun approccio formale allo sviluppo (purché si abbiano persone mature e coscienziose).

In Rapid Development , Steve McConnell scrive sulla scelta di un modello di ciclo di vita appropriato per il tuo progetto. C'è un'intera sezione di un capitolo dedicato a questo argomento, ma si tratta delle caratteristiche del progetto: il livello di comprensione dei requisiti, il livello di comprensione dell'architettura, l'affidabilità richiesta, l'entità e la gravità dei rischi, i limiti del programma e del budget, la visibilità desiderata del cliente e / o della direzione e l'abilità / sofisticazione del team di progetto sono identificati come le selezioni principali.

Il tipo di sistema ha molto poco a che fare con esso, anche se spesso gioca nell'affidabilità o nella tendenza futura a modificare / migliorare il sistema). Le persone sono i tuoi più grandi piloti in termini di comprensione del dominio, degli strumenti, del progetto e dell'interazione tra il team di sviluppo e gli altri stakeholder. Anche la conoscenza del processo è importante in quanto c'è un sovraccarico nell'apprendimento di nuove tecniche per lavorare.

Ti suggerisco di provare il Consulente del processo sul sito web OPFRO . Fai clic su "Consulente del processo" nel menu a sinistra e rispondi alle domande a scelta multipla relative alle tue esigenze. Lo strumento consiglierà un ciclo di vita del metodo. Vedrai anche alcune spiegazioni sul perché questa è l'opzione migliore.