Esistono studi sull'efficienza / efficacia di Agile vs Waterfall [chiuso]

In una riunione dell'altro giorno è stato affermato che l'agile era solo il 60% più efficiente nei tempi di sviluppo rispetto alla cascata. Non sto cercando di convalidare o confutare questa affermazione. Sono interessante scoprire se ci sono stati studi che hanno confrontato le 2 metodologie.

Ci sono studi là fuori che confrontano i due?

Il libro "Making Software: cosa funziona davvero e perché lo crediamo" contiene alcuni capitoli sui metodi Agile tra cui XP, Scrum, Dynamic Software Development e Lean, con un buon supporto scientifico. È di alta qualità, come ci si aspetterebbe da O'Reilly. Uno dei redattori era l'eccellente Greg Wilson , un autore di informatica, editore e presentatore di fiducia.

Il libro stesso sintetizza numerosi studi di ricerca, inclusi molti su agili. Una sezione riassume la ricerca tra cui "Due teste sono meglio di una? Sull'efficacia della programmazione delle coppie" di Dybå, T .; Arisholm, E .; Sjøberg, DIK; Hannay, JE; Shull, F .; e " Studi empirici sullo sviluppo di software agili: una revisione sistematica " di Tore Dybå e Torgeir Dingsøyr.

Il senso generale è che la maggior parte delle pratiche agili sono benefiche, ma che gli effetti della programmazione di coppia, TDD e altri inquilini agili non sono così forti come si potrebbe sperare. C'è persino una nota inquietante che TDD potrebbe in effetti creare dipendenza *.

Il libro è un ottimo modo per avere accesso a molte ricerche che sono state condotte, il tutto in un insieme coeso. Ci sono alcuni blog e altri siti web che recensiscono il libro.

* Questa non è necessariamente la mia opinione!

Per quanto non mi piaccia il titolo, credo che Balancing Agility and Discipline: A Guide for the Perplexed potrebbe contenere alcune informazioni rilevanti per te. Questo libro di due esperti di processo di ingegneria del software e di gestione di progetti software - Barry Boehm e Richard Turner. Questo libro esamina vari aspetti delle metodologie agili e basate su piani, li confronta e li contrappone e discute anche dell'integrazione per raggiungere una situazione "migliore di entrambi i mondi".

L'Appendice E di Bilanciamento di agilità e disciplina contiene una vasta gamma di informazioni empiriche relative ai costi e ai benefici di vari metodi agili e basati su piani. Tuttavia, non sembrano esserci dati sull'efficacia temporale. Ma guardando attraverso i dati, sembra (come sospettavo) che questa non sia una / o una scelta - alcuni progetti hanno subito uno sforzo ridotto, pianificazioni più veloci e minori difetti nell'applicazione di metodi agili. Tuttavia, altri progetti che hanno usato. La sezione discute una serie di diversi progetti in diversi settori, il tipo di processo che hanno utilizzato e ciò che hanno vissuto nel corso del progetto.

Ci sono molti casi studio citati nell'appendice E che forniscono questi dati. Ci sono troppi per me solo per iniziare a nominare in modo casuale, dal momento che molti sono focalizzati in un settore particolare o anche all'interno di una particolare organizzazione. Se esaminerai i casi, suggerirei di trovare quelli di natura simile al tuo team, progetto, organizzazione e industria per trarre conclusioni ragionevolmente valide.

In Rapid Development: Schedule Wild Software Schedules , Steve McConnell identifica una serie di fattori da considerare nella scelta di una metodologia del ciclo di vita: livello di comprensione dei requisiti, livello di comprensione dell'architettura, affidabilità desiderata, gestione dei rischi, vincoli di pianificazione, quantità di processo "correzioni dei corsi" generali, a metà progetto, capacità di fornire visibilità al cliente, capacità di fornire visibilità al management e raffinatezza del team di sviluppo e del management. Ce ne sono anche altri, come la cultura organizzativa, quindi probabilmente non esiste un elenco esaustivo da nessuna parte.

Anche dato lo stesso identico progetto, c'è anche il fattore squadra. Se prendi un team che ha costantemente distribuito software utilizzando la metodologia a spirale basata sul piano e li butti in Scrum, sperimenteranno una diminuzione della produttività, un aumento dei thrashing e dovranno superare un nuovo modello di processo prima che possano venire per avere successo. Anche se un'altra metodologia potrebbe essere più adatta, c'è sempre la necessità aziendale di fornire effettivamente il software. Ecco perché gli sforzi per il miglioramento dei processi sono spesso sforzi a lungo termine e non durante la notte - i cambiamenti importanti sono scioccanti per un team e (anche se la metodologia potrebbe essere più adatta sulla carta) può causare una diminuzione della produttività.

C'è molto di più della semplice efficacia o efficacia del processo e non puoi semplicemente guardare un'istantanea dello stesso team che lavora in un ambiente guidato da un piano e in un ambiente agile. È necessario considerare il contesto industriale e organizzativo, gli attributi del progetto, il team, il cliente e così via quando si prende una decisione.

Sulla base di quello che ho letto, non sarò d'accordo con la tua valutazione dei colleghi. Sono sicuro che puoi trovare alcuni casi di studio da qualche parte in cui un progetto agile era del 60% meno efficiente in termini di metrica delle prestazioni rispetto a un progetto simile basato su un piano. Tuttavia, ci sono anche studi che dimostrano che l'agile produce l'80% in meno di sforzi, il 50% in meno di tempo e l'elevata soddisfazione del cliente per il prodotto.

Non ho uno studio ma vorrei comunicare la mia esperienza.

L'efficacia di una qualsiasi delle metodologie menzionate dipende fortemente dagli analisti.

Quando hai un ottimo proprietario del prodotto, ad esempio SCRUM è sicuramente più veloce di un approccio a cascata con una cattiva specifica.

Agile con un cattivo proprietario del prodotto è sicuramente più lento della cascata con una grande specifica.

Tuttavia, il più delle volte, non conosciamo i requisiti esatti abbastanza presto e le metodologie agili hanno cicli di feedback più rapidi. Ciò significa che in terreni incerti l'agile è un metodo migliore per fornire un prodotto di alta qualità a costi ragionevoli. Ci sono numerosi altri vantaggi, ad esempio, i progetti agili sono più facili da annullare quando non funzionano e quindi possono ridurre al minimo le perdite.

Si potrebbe dire che le metodologie agili riducono il rischio, mentre la cascata, anche se a volte può essere più veloce, può essere una scommessa abbastanza monetaria.

agile era solo il 60% più efficiente nei tempi di sviluppo

Vero.

Ma questa è una misura zoppa.

I metodi agili di solito forniscono prima il valore reale.

Waterfall si attiene semplicemente a un programma a prescindere da ciò che viene consegnato e spesso non fornisce nulla di valore fino a quando non è trascorso un enorme arco di tempo.

Ulteriore.

È possibile misurare il "tempo di sviluppo" separatamente da "tempo di sviluppo e test".

Agile di solito include test. Quindi sembra più lento.

Lo sviluppo delle cascate può essere nettamente separato dai test. Quindi il codice è "pronto per il test" prima. Ma non è "fatto" fino a molto tempo dopo.

Così. Hanno assolutamente ragione. Per quello che hanno misurato.