Qualcuno può spiegare la metodologia agile in frasi semplici?
Qualcuno può spiegare la metodologia agile in frasi semplici?
Agile è un sacco di cose e pratiche, ma penso che il nucleo di esso sia solo uno sviluppo iterativo.
iterativo: Pensa a un mucchio di cascatelle molto piccole. Ovvero, il metodo waterfall (requisiti- > spec- > code- > test), ma invece di farlo nel corso di un anno o giù di lì, lo fai nel giro di poche settimane per un chunk gestibile del progetto complessivo. Alla fine di "iterazione / sprint / incremento", hai un set di funzionalità aggiuntive piccolo ma completo e testato.
Ciò ti consente di cambiare rapidamente il corso del progetto se si scopre che ciò che stai facendo non è ciò che il cliente vuole, o il business ha bisogno di cambiare, o qualsiasi altra cosa. Da qui il termine "agile".
Penso che nulla lo metta meglio del Manifesto Agile stesso:
Stiamo scoprendo modi migliori per sviluppare
software eseguendolo e aiutando gli altri a farlo.
Attraverso questo lavoro siamo arrivati a valutare:
Individui e interazioni su processi e strumenti
Software di lavoro su documentazione completa
Collaborazione con il cliente sulla negoziazione del contratto
Risposta per cambiare rispetto a un piano
Cioè, mentre c'è valore negli articoli su
a destra, valutiamo di più gli elementi a sinistra.
dal link
Per me l'idea più importante è questa:
Le modifiche ai requisiti stanno per accadere perché siamo costretti a progettare software al minimo della conoscenza di ciò che è necessario (l'inizio del progetto) ei requisiti diventeranno più chiari nel corso del progetto.
Gli approcci tradizionali (Waterfall) 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 i bisogni degli utenti, specialmente se le loro obiezioni sono soddisfatte con "Bene, hai firmato su di esso!"
I metodi agili sono progettati per abbracciare le inevitabili modifiche anziché proteggere il team di sviluppo da loro. Lo fa in diversi modi, tra i quali 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 i pianificatori più impegnativi.
In una frase questo appare come segue:
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
Questo viene dalla definizione di wikipedia e mi piace molto. Ho evidenziato i principi fondamentali.
Vorrei semplicemente aggiungere anche ciò che Agile NON è. Ci sono molti negozi là fuori che affermano di essere Agili ma in un modo che significa semplicemente che non sono interessati a pianificare i loro progetti e si aspettano che le cose vengano fatte in un periodo di tempo irragionevolmente breve.
Agile! = nessun piano di progetto. È difficile gestire le persone che pensano implicitamente che l'affermazione sia falsa perché tendono ad essere tipi di gestione e non sempre facili da contraddire.
Andy si è già collegato al Manifesto Agile, che penso riguardi solo.
Penso sia utile guardare da dove proviene anche il Manifesto Agile. C'erano un certo numero di metodologie là fuori che avevano alcuni elementi comuni e molte motivazioni simili: Extreme Programming (XP), Scrum, DSDM, Adaptive Software Development, Crystal, Sviluppo guidato dalle caratteristiche, Programmazione pragmatica (lista da Alistair Cockburn ). Le persone che proponevano quelle metodologie decisero di trovare un termine di marketing per coprire le cose che avevano in comune, in modo che la forza di ciò che stavano dicendo sarebbe stata migliorata.
È interessante notare che (secondo ciò che qualcuno mi ha detto) c'erano un certo numero di nomi sulla lista che avrebbero potuto essere scelti al posto di "Agile" - uno dei quali era "Adattivo". Personalmente penso che come una singola parola riassume meglio ciò che è agile in realtà meglio di "agile"!
L'utilizzo di una metodologia agile si riduce all'enfatizzazione della fornitura di prodotti di qualità rispetto ad altri aspetti dello sviluppo del prodotto e alla consapevolezza che il feedback da parte della comunità degli utenti è una parte vitale della creazione di prodotti di qualità.
Confrontalo con un approccio di sviluppo tradizionale / a cascata che enfatizza la progettazione in anticipo, la documentazione e la definizione dell'interfaccia mentre de-enfatizza l'implementazione e la transizione del prodotto dallo sviluppo al rilascio.
Secondo me c'è una qualità intrinseca che un team può costruire in un prodotto, vedo questo prendendo la forma di verificare che un prodotto funzioni come previsto dal team di sviluppo e possa ragionevolmente adattarsi a miglioramenti prevedibili. Ci sono anche fattori di qualità basati interamente sulla percezione che misurano quanto bene un prodotto soddisfa le esigenze dei suoi utenti.
Gli approcci agili tendono a fornire prodotti iterativamente , incorporando feedback degli utenti e feedback degli sviluppatori in ogni iterazione e promuovono erogare ogni incremento di funzionalità quando raggiunge redditività minima come funzione di forzatura per ottenere feedback degli utenti frequenti e contrastare la tendenza delle attività di sviluppo a protrarsi per lunghi periodi di tempo senza il feedback dei suoi utenti. A mio parere, altri aspetti di un approccio agile tendono a supportare questi principi chiave.
Leggi altre domande sui tag development-process agile