Esistono molte metodologie di sviluppo del software - SCRUM, agile, XP, ecc. - e tutte hanno vantaggi e svantaggi, suppongo.
Ma quando abbiamo davvero bisogno di applicarli? Sicuramente non sono necessari per i piccoli progetti di 1 uomo, ma per le grandi squadre con più di 50 persone non si può sicuramente andare su ad-hoc: il tutto.
Quindi qual è la linea per quando usare e quando non usare una tale metodologia, se ce n'è davvero una?
Anche in un progetto rigorosamente a 1 uomo (il software di codifica per te senza pianificazione) devi:
Potresti farlo in modo informale (cowboy), ma dato che il progetto 1-man è un caso limite (di solito c'è almeno tu e qualcun altro per cui lavori), farlo con un formalismo leggero ben fondato è praticamente sempre preferibile. Tieni presente che il nucleo del Agile Manifesto è in realtà solo alcuni principi. Le metodologie formali (ad esempio Scrum) volte a raggiungere tali principi possono e devono essere adattate in base alle dimensioni del team, ecc.
"nessuna metodologia" è ancora una metodologia, solo non molto buona (ripetibile, prevedibile, migliorabile)
La domanda in realtà non ha senso. Non importa quello che fai, stai applicando una qualche forma di approccio SDLC. Questo approccio potrebbe essere codifica da cowboy o cascata, ma è un approccio. Una domanda migliore è quali progetti e dimensioni della squadra sono più adatti a quali approcci.
Le metodologie software sono puramente un mezzo per ridurre il rischio del progetto.
È abbastanza risaputo che se si prende un team di sviluppatori che pratica una certa metodologia e si dice loro che non devono più seguirlo e può lavorare come vogliono, la loro produttività aumenterà, ma il rischio che costruiranno il la cosa sbagliata al prezzo sbagliato nel tempo sbagliato aumenterà notevolmente.
Quindi, per scegliere una metodologia appropriata, devi prima determinare quali sono i rischi se il progetto fallisce.
Se l'unica cosa da perdere è un paio di settimane delle tue serate, allora alcuni schizzi in un taccuino e nessuna misurazione dei progressi o dei risultati finali va bene.
Se la vita di sette astronauti e miliardi di dollari è il prezzo del fallimento del software, allora è meglio avere una pianificazione di livello mondiale, un processo di sviluppo, una gestione dei progetti e dei test in atto.
L'approccio allo sviluppo che fai deve massimizzare il ROI del progetto. A seconda della natura del progetto e delle risorse disponibili, la giusta direzione da prendere potrebbe essere diversa.
Però ci sono due regole ovvie, comuni alla progettazione di qualsiasi sistema funzionante
La necessità di controllo della versione del codice asource, backup di sistema, procedure di controllo qualità e molti altri bit essenziali è solo un'altra parte della gestione del rischio del progetto.
Un'ultima considerazione: più grande è l'azienda e più i dipartimenti come il tuo sono tanto più desiderati è avere alcune pratiche convergenti utilizzate a livello globale per assicurare un sovraccarico minimo sul trasferimento delle risorse da progetto a progetto e anche un minimo di costi generali per senior gestione necessaria per comprendere i dettagli dei progetti nei reparti che gestiscono.
Leggi altre domande sui tag development-methodologies