Come faccio a scegliere un modello di modello di sviluppo del ciclo di vita?

Per prima cosa, non è una scelta di cascata o agile, ma è guidata dal piano piuttosto che agile. Esistono molte metodologie pianificate da cui scegliere. L'altra metodologia promossa dal piano è Boehm's Spiral Model . È uno sviluppo iterativo, ma non è (necessariamente) incrementale. Ho fatto una domanda su altri metodi basati su piani e l'altro indicato era Cap Gemini SDM .

Quando decidi tra una metodologia guidata dal piano e una metodologia agile, ci sono una serie di fattori da considerare. In Rapid Development: Taming Wild Software Schedules , Steve McConnell ha un'intera sezione dedicata alla scelta di un modello di ciclo di vita. Analizza una serie di modelli del ciclo di vita: cascata pura, code-and-fix, spirale, cascate modificate, prototipi evolutivi, consegna graduale, consegna evolutiva, design-to-schedule, design-to-tools e software COTS. Ognuno è discusso in profondità e valutato sulla sua capacità di far fronte a requisiti poco chiari, per produrre un sistema affidabile, per gestire il rischio, per adattarsi a un programma o budget limitato, per fornire visibilità ai clienti e / o alla gestione e alla sofisticazione della squadra.

Quindi, sì, una considerazione è il tipo di progetto che viene consegnato. Ma ci sono numerosi fattori e molti modelli di ciclo di vita che possono essere scelti da.

Is it really as cut and dry as "if it's a bridge or nuke reactor type project use waterfall else use agile?

Sì.

In realtà è così semplice.

Il punto di Agile è di adattare il processo al problema da risolvere.

Il punto di Waterfall è un'analogia (in parte falsa) tra le costruzioni edili e la progettazione e lo sviluppo del software. La costruzione (progettare prima tutto, costruire tutto secondo) non si applica molto bene al software, perché il software è quasi interamente un esercizio di progettazione. C'è poco nello sviluppo del software che è parallelo all'edilizia o alla produzione convenzionale.

Ha molto meno a che fare con le metodologie di sviluppo dominate da due scuole di pensiero. Sarebbe come chiedere se c'è una differenza tra "Rigido, inflessibile e rigido" vs. "Sciolto, flessibile e in continua evoluzione". Sono in bianco e nero, con un'infinita varietà di diverse sfumature di grigio.

Inoltre all'interno di Agile ci sono diversi modelli tra cui scegliere Fonti: Wikipedia :

• Modellazione agile
• Agile Unified Process (AUP)
• Metodo di sviluppo dei sistemi dinamici (DSDM)
• Essential Unified Process (EssUP)
• Exia Process (ExP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Apri processo unificato (OpenUP)
• Scrum
• Crystal Clear
• Tracciamento della velocità

Notate che ho detto Modelli, perché in realtà ogni organizzazione ha esigenze uniche a cui deve essere adattato, e uno di questi modelli può fornire un buon punto di partenza. Se questa non è una scelta sufficiente per il management, per passare a un metodo sano e realistico di sviluppo del software basato sulla realtà, allora è solo un po 'esitante e si limita a prestare attenzione al pensiero, arrivando al punto di dire che sono meno interessati a scrivere software di qualità che si adatta alle esigenze del cliente rispetto a mantenere l'illusione di un controllo fermo e totale sul processo e sulle persone.

IMHO, Waterfall non si adatta a nessuno sviluppo, viene dal settore edile, dove rifare qualcosa è impossibile (o almeno estremamente costoso). Ma per il software, la riprogettazione e la riscrittura sono economiche, ed è estremamente preferibile rivedere continuamente le specifiche.

OTOH, Agile richiede che tutti i membri del team abbiano approssimativamente la stessa esperienza, ei team dovrebbero essere piccoli, altrimenti aggiunge un notevole sovraccarico di comunicazione. Quando i livelli di esperienza sono disparati, si perde un sacco di tempo per i più esperti.

L'approccio che ho usato di più, e che ho sperimentato come più efficace, è di non avere alcuna struttura definita.

In un primo momento, i progetti richiedono i più talentuosi e abili che puoi ottenere, per avere buone basi. Generalmente non hai nient'altro da fare, metti queste persone nel progetto e attendi qualche giorno, presto inizieranno ad organizzare tutto; è il potere della natura.

Avere le persone giuste nel posto giusto fa il trucco. Cerca leader naturali (quelli odiano tutti, eppure amano). Una volta che la cosa inizia a muoversi, passeranno in modalità Guardian per mantenere le cose buone, e prenderà velocità.

(Beh, ammetto che c'è una struttura implicita, ma è altamente dinamica)

Il punto è: lo sviluppo consiste quasi interamente (da questo punto di vista) nelle interazioni sociali, qualcosa di estremamente complesso e resiliente all'intervento incauto, quindi ogni tentativo di progettare l'interazione sociale è condannato. L'unica cosa che possiamo fare al riguardo è di influenzare, leggermente.

Gli approcci maturi e agili sembrano praticamente distinguibili l'uno dall'altro. Il tuo obiettivo principale dovrebbe essere che l'azienda guidi lo sviluppo del software. Non importa quale modello si utilizza se non è possibile puntare a una funzione e fare riferimento ai requisiti aziendali per tale funzione. È qui che entra in gioco il QA.

È necessario un solido ambiente di controllo qualità che sia il sistema di registrazione per i requisiti aziendali. Il QA è sinonimo di garanzia della qualità, non di test. Tutti i test eseguiti da QA assicurano che il sistema in fase di sviluppo esegua la mappatura dei requisiti finalizzati in loro possesso. E gli sviluppatori ora hanno una direzione da seguire nello sviluppo del loro software.

Per far sì che queste cose funzionino bene con il team di sviluppo. È necessario disporre di cicli di rilascio brevi in modo che l'azienda non sia sopraffatta dal prendere decisioni su ciò che dovrebbe essere sviluppato successivamente. Inoltre, il QA avrà una migliore possibilità di determinare se una funzione specifica fa ciò che dovrebbe fare e il feedback al team di sviluppo sarà più specifico perché ci sono meno ipotesi su cosa sia o non rompere quella parte del sistema .

Tutte queste cose vanno verso la creazione di software di qualità. La metodologia di sviluppo è ciò che li incolla insieme in una soluzione coesiva che consente a tutti di lavorare insieme in modo prevedibile. L'approccio a cascata tende a iniziare con l'attività che ha un tempo di adattamento più facile, dove l'approccio agile è maggiormente focalizzato sugli sviluppatori. Ma entrambi si incontrano nel mezzo alla fine.