È agile scientificamente provato?

Question

Esistono studi scientifici che hanno confrontato l'agilità con altre metodologie di sviluppo del software? Penso che agile sia un buon modo di lavorare, ma esiste una base scientifica per questo?

Sto cercando qualcosa come this, ad eccezione di questo studio si occupa solo di TDD. Esistono studi sull'agile in generale?

Lo chiedo perché ho incontrato un agile zelante che sosteneva che l'agile modo di lavorare produce un software migliore di tutti gli altri modi di lavorare. Ha presentato questo come un dato di fatto, che non credo sia.

Answer 1

Vedere this response per una domanda diversa per alcune informazioni sul motivo per cui raramente vi sono buoni studi empirici su qualsiasi aspetto del software di costruzione.

Answer 2

Laurie Williams from NCSU ha pubblicato un sacco di studi davvero interessanti sull'efficacia della programmazione della coppia, e quindi ha iniziato a trattare con più aspetti dell'agile.

Answer 3

Scientifico? Bene, sono molto impressionato dal lavoro di Alistair Cockburn. Ascoltatelo here

Alistair Cockburn era stato un progettista hardware e ricercatore per 16 anni quando IBM gli ha chiesto di scrivere una metodologia per i progetti orientati agli oggetti. Ha passato l'ultimo decennio a studiare e scrivere sullo sviluppo del software e ha imparato che alcuni dei progetti di maggior successo hanno i processi più semplici. Nel 2001 lui e altri 16 specialisti dello sviluppo del software si sono incontrati per discutere le cosiddette metodologie leggere e un risultato è stato il Manifesto dello sviluppo del software Agile, che comprende quattro dichiarazioni di valore: individui e interazioni su processi e strumenti; software funzionante su documentazione completa; collaborazione del cliente per la negoziazione del contratto; e rispondere al cambiamento dopo aver seguito un piano.

Answer 4

Alcuni aspetti della mischia hanno confermato prove empiriche. Sono stati fatti molti studi empirici su diverse parti della mischia. Ho sentito Jeff Sutherland (http://jeffsutherland.com/scrum/ l'inventore della mischia) menzionare molti studi specifici e osservazioni nei suoi discorsi.

Agile in generale è solo un termine generico progettato per mantenere moderatamente felici i diversi gruppi politici. Non aspettarti di vedere un esperimento dimostrare qualcosa di generale su tutto ciò che è "agile". È troppo vago per essere utile.

Answer 5

Non credo sia possibile "provare" una cosa del genere.

Andrò ancora oltre, e dico che non penso sia davvero possibile studiare il problema della "Produttività dello sviluppo del software" con un tale studio. Il che è principalmente il motivo per cui tutte le prove che dobbiamo sempre fare è ciò che le persone esperte ci dicono (e sfortunatamente, ognuna ha una visione diversa su varie metodologie).

C'è un motivo semplice per questo: le persone sono completamente diverse. Siediti in una squadra di 5 persone per un progetto di pochi mesi (che è più, suppongo, di quanto la maggior parte degli studi abbia mai gestito, vediamo qualcuno finanziare alcuni mesi di tempo per lo sviluppo), e sei destinato a diventare completamente risultati diversi. Il problema è, non c'è modo di svelare i diversi fattori qui:

1. Capacità dei singoli programmatori.
2. Dedizione/sforzo introdotti dai programmatori.
3. Esperienza con gli strumenti.
4. La capacità di chi agisce come capo squadra (basta seguire una metodologia non è sufficiente. Se qualcuno non sa come gestire una squadra, la metodologia non sarà davvero ben rappresentata).

E ci sono probabilmente molti altri fattori.

Quindi quello che sto cercando di dire è, non credere agli studi che hanno "provato" che una metodologia/strumento/qualcosa funziona meglio di altri. Sono quasi impossibili da fare.

Answer 6

Ciò che mi è stato dimostrato è il guasto statistico di waterfall, vale a dire scientific management applicato allo sviluppo del software. Agile, come movimento, è solo una risposta a questa evidenza empirica (vedi ad esempio i rapporti CHAOS).

Answer 7

No, non è scientificamente provato o provato in altro modo. Per "provare" significherebbe:

• Per dimostrare la sua validità da un punto di vista analitico.
• per dimostrare che funziona in pratica e quindi dedurre la sua validità

Un approccio analitico è irrealizzabile, dal momento che abbiamo a che fare con la gente qui piuttosto che sistemi semplici. Non è possibile formalizzare team e organizzazioni.

Gli studi empirici, d'altra parte, sono stati condotti, ma i risultati sono inconcludenti. Robert Glass mostra alcuni risultati interessanti nel suo libro Software Creativity 2.0, per esempio.

Quindi no, l'agilità non è provata. Neanche vicino. :-)

Answer 8

Questo interview with Linda Rising on InfoQ indirizza la tua domanda in una certa misura. Parla dell'efficacia dei placebo e delle nostre credenze in medicina e di come queste stesse cose possano riguardare lo sviluppo di software. Fondamentalmente, siamo nella comunità Agile dando a noi stessi una "pillola di zucchero"?

Estratto Intervista

scienza è su esperimenti, circa in possesso di un 'idea per un breve periodo di tempo e testarlo e poi l'esame dei risultati di quel test per scoprire se l'ipotesi regge . Questo è davvero ciò di cui parla Agile. Agile parla di piccoli esperimenti. Ora credo che tutto ciò che facciamo, non solo lo sviluppo del software, ma le nostre vite dovrebbero essere una serie di piccoli esperimenti.

Portiamo in ogni possibile stakeholder, portiamo clienti, portiamo gli utenti, i tester lavorano con gli sviluppatori. Stiamo sempre esaminando attentamente quelle pillole di zucchero. Funziona davvero? Cosa ne pensi? Sei soddisfatto dei risultati? Questa è l'unica cosa che ci salva - Agile stessa. Questa serie di piccoli esperimenti.

Answer 9

This paper analizza il ritorno sugli investimenti (ROI) di Agile vs metodi tradizionali. Si basa sui risultati effettivi degli studi pubblicati.

Dal astratto:

Agile Metodi ROI era quattro volte più di costosi metodi tradizionali, due volte meno di quelli economici, e la migliore Agile e tradizionale Metodi avuto uguali ROI.