Cos'è la metodologia agile? [chiuso]

Qualcuno può spiegare la metodologia agile in frasi semplici?

Agile è un sacco di cose e pratiche, ma penso che il nucleo sia solo lo sviluppo iterativo.

Iterativo: pensa a un mucchio di cascate molto piccole. Cioè, il metodo a cascata (requisiti-> spec-> codice-> test), ma invece di farlo nel corso di circa un anno, lo fai nel corso di alcune settimane per un pezzo gestibile del totale progetto. Alla fine di 'iterazione / sprint / incremento', hai una serie piccola ma completa e testata di funzionalità aggiuntive.

Ciò ti consente di cambiare rapidamente il corso del progetto se si scopre che ciò che stai facendo non è ciò che il cliente desidera, o le esigenze aziendali devono cambiare, o altro. Da qui il termine "agile".

Penso che nulla lo metta meglio del Manifesto Agile stesso:

Stiamo scoprendo modi migliori per sviluppare
software facendolo e aiutando gli altri a farlo.
Attraverso questo lavoro siamo arrivati ​​a valutare:

Individui e interazioni su processi e strumenti
Software funzionante su documentazione completa
Collaborazione con i clienti sulla negoziazione del contratto
Risposta al cambiamento dopo un piano

Cioè, mentre c'è valore negli articoli a
destra, valutiamo di più gli oggetti a sinistra.

da http://agilemanifesto.org/

Per me l'idea più importante è questa:

Le modifiche ai requisiti accadranno perché siamo costretti a progettare software al nadir della conoscenza di ciò che è necessario (l'inizio del progetto) e i requisiti diventeranno più chiari nel corso del progetto.

Gli approcci tradizionali (a cascata) cercano di mitigare questo cambiamento bloccando tutti in un contratto all'inizio del progetto facendoli firmare su specifiche complete. Questo può funzionare come un CYA, ma non rende nessuno felice di offrire qualcosa che non soddisfa le esigenze degli utenti, specialmente se le loro obiezioni vengono soddisfatte con "Bene, hai firmato!"

I metodi agili sono progettati per abbracciare gli inevitabili cambiamenti invece di proteggere il team di sviluppo da essi. Lo fa in vari modi, tra cui il principale è lo sviluppo iterativo e il coinvolgimento continuo delle parti interessate nel processo. Nella mia esperienza, alla fine lascia tutti più coinvolti, anche se può essere più scomodo per alcuni tipi di gestione che sono pianificatori hardcore.

In una frase sembra questo:

Lo sviluppo software agile è un gruppo di metodologie di sviluppo software basate sullo sviluppo iterativo e incrementale , in cui i requisiti e le soluzioni evolvono attraverso la collaborazione tra team auto-organizzanti e interfunzionali .

Questo deriva dalla definizione di Wikipedia, e mi piace molto. Ho sottolineato i principi fondamentali.

Vorrei solo aggiungere ciò che NON è Agile. Ci sono molti negozi là fuori che dichiarano di essere Agili, ma in un modo questo significa che non sono interessati a pianificare i loro progetti e si aspettano che le cose vengano fatte in un periodo irragionevolmente breve.

Agile! = Nessun piano di progetto. È difficile gestire le persone che implicitamente pensano che questa affermazione sia falsa perché tendono ad essere tipi di gestione e non sempre facili da contraddire.

Andy si è già collegato al Manifesto Agile, che a mio avviso copre quasi tutto.

Penso che sia utile esaminare anche la provenienza del Manifesto Agile. C'erano una serie di metodologie là fuori che avevano alcuni elementi comuni e molte motivazioni simili: Extreme Programming (XP), Scrum, DSDM, Sviluppo software adattivo, Crystal, Sviluppo guidato da funzionalità, Programmazione pragmatica (elenco da Alistair Cockburn ). Le persone che propongono tali metodologie hanno deciso di escogitare un termine di marketing per coprire le cose che avevano in comune in modo che la forza di ciò che stavano dicendo fosse migliorata.

È interessante notare che (secondo quello che qualcuno mi ha detto) c'erano alcuni nomi nella lista che avrebbero potuto essere scelti al posto di "Agile" - uno dei quali era "Adattivo". Personalmente penso che come una sola parola riassuma meglio ciò che agile è in realtà meglio di "agile"!

L'uso di una metodologia agile si basa sull'enfasi sulla consegna di prodotti di qualità rispetto ad altri aspetti dello sviluppo del prodotto e sulla consapevolezza che il feedback da parte della comunità degli utenti è una parte vitale della creazione di prodotti di qualità.

Contrastalo con un approccio di sviluppo tradizionale / a cascata che enfatizza la progettazione iniziale, la documentazione e la definizione dell'interfaccia, mentre disenfatizza l'implementazione e passa il prodotto dallo sviluppo al rilascio.

A mio avviso, la qualità intrinseca che un team può integrare in un prodotto, lo vedo assumere la forma di verificare che un prodotto funzioni come previsto dal team di sviluppo e possa ragionevolmente accogliere miglioramenti prevedibili. Esistono anche fattori di qualità basati interamente sulla percezione che misurano la capacità di un prodotto di soddisfare le esigenze dei suoi utenti.

Gli approcci agili tendono a fornire prodotti in modo iterativo , incorporando feedback degli utenti e feedback degli sviluppatori in ciascuna iterazione, e promuovono la fornitura di ogni incremento di funzionalità quando raggiunge la redditività minima come funzione di forzatura per ottenere feedback frequenti degli utenti e contrastare la tendenza delle attività di sviluppo a continuare lunghi periodi di tempo senza feedback da parte dei suoi utenti. A mio avviso, altri aspetti di un approccio agile tendono a supportare questi principi chiave.

• L'accentuazione della frequente collaborazione con i clienti genera feedback degli utenti, pur rimanendo flessibile alle modifiche dei requisiti, consente allo sviluppo del prodotto di integrare regolarmente tali feedback
• La frequente integrazione nelle configurazioni e negli ambienti di implementazione pertinenti va di pari passo con l'identificazione costante di quali configurazioni e ambienti rimangono rilevanti al fine di garantire che il prodotto rimanga prezioso e pertinente per gli utenti che forniscono feedback
• L'auto-organizzazione e la promozione di team interfunzionali parla della creazione di responsabilità personale all'interno del team e del potenziamento del team per determinare il modo migliore per rimuovere i blocchi stradali in modo efficiente senza essere trattenuti da ruoli prestabiliti e gerarchia di gestione all'interno del team