Il problema con questo tipo di quantificazione è che è quasi impossibile ottenere dati sufficienti sull'efficacia delle pratiche di ingegneria del software per trarre conclusioni significative.
Soprattutto, correlazione non implica causalità - ad esempio, potrebbe essere solo che i bravi programmatori sono pronti a saltare e implementare nuove idee, quindi vedi una correlazione generale tra successo e adozione del progetto di nuove tecniche di ingegneria del software. Ma questo non prova nulla dell'efficacia delle tecniche stesse, poiché l'intero effetto potrebbe essere spiegato dal livello di talento più alto dei programmatori che li adottano.
E quindi è difficile controllare le variabili indipendenti . Come garantisci un equo divertimento a meno che tu non sia in grado di controllare tutti i seguenti?
- Livello di esperienza / abilità / motivazione del team
- Estensione effettiva dell'adozione della metodologia dichiarata (stanno davvero facendo correttamente TDD?)
- Presenza / assenza di errori di progettazione principali non correlati alla metodologia di ingegneria del software (ad esempio quelli che richiedono una grande re-architettura durante il progetto)
- Livello di difficoltà dei progetti confrontati
- Impatto di problemi imposti dall'esterno (ad esempio modifiche ai requisiti principali)
- Bias di selezione (ad esempio, le persone tendono a condividere i dati più spesso su progetti di successo?)
- Pregiudicazione della conferma (ad esempio, le persone hanno esagerato il successo dei progetti che utilizzano la loro metodologia preferita?)
Anche se decidi di affrontare quanto sopra, assegnando a più team accuratamente selezionati lo stesso problema nelle stesse condizioni attentamente controllate, il tuo esperimento sarà probabilmente eccessivamente costoso se vuoi creare abbastanza dati per essere statisticamente significativo.
E infine quasi impossibile misurare il successo :
- Una metrica relativa alle quantità come linee di codice sorgente (SLOC) è terribilmente pessima. L'incentivo per gli sviluppatori è creare mostruosità di milioni di righe con codifica copia / incolla per apparire più "produttivi"
- Una metrica sul tempo / sul budget dipende principalmente dal livello di ambizione nelle stime utilizzate per creare il piano / budget
- Una metrica di tipo ROI dipende tanto dalla situazione del mercato e dalla gestione commerciale del prodotto quanto dalla qualità dell'output ingegneristico (guarda la cronologia di Microsoft Windows!)
- I punti storia sono utili per avere una sensazione di velocità in una squadra agile ma non sono paragonabili tra i vari team
- Le metriche basate sulla funzionalità come punti funzione o Use Case Points sono forse i migliori di un brutto gruppo, ma sono burocratici raccogliere e non riflettere la differenza nello sforzo ingegneristico necessario per creare ogni unità di funzionalità.
- Le metriche di qualità come i bachi nella disponibilità di produzione / app sono notoriamente difficili da calcolare e confrontare su base di parità - dipende in modo significativo da cose come la piattaforma scelta, la dimensione della base di utenti e vari fattori operativi / di implementazione.
In conclusione: cercare di quantificare l'impatto delle attività di sviluppo del software è un compito estremamente difficile, e nonostante molti anni dopo l'argomento nessuno ha ancora trovato un approccio veramente efficace. Di conseguenza, la valutazione delle metodologie di sviluppo del software rimane più un'arte che una scienza e probabilmente lo rimarrà per molti anni a venire.
È interessante notare che esiste un approccio che ritengo possa promettere: applicazione dei principi snelli . Questa non è una panacea e non risolverà direttamente il problema della valutazione delle metodologie di sviluppo del software, ma ha una visione chiave: Un processo con un particolare elemento di rifiuto è inequivocabilmente meno efficiente dello stesso processo senza quell'elemento di rifiuti, a parità di altre condizioni . Quindi, se ti concentri sull'eliminazione degli sprechi nel processo di sviluppo del software, puoi almeno essere sicuro che ti stai muovendo nella giusta direzione. Inoltre, i rifiuti sono spesso quantificabili, quindi dovresti anche avere un'idea di quanto tu stia ottenendo, almeno in termini approssimativi.