Metodologia agile: differenze tra le versioni

Versione delle 10:59, 18 ott 2022

Versione attuale delle 17:31, 4 giu 2025

(2 versioni intermedie di 2 utenti non mostrate)

Riga 3:

L'uso del termine ''agile''<ref>Il termine agile va pronunciato in lingua inglese, sebbene coincida, come grafema, all'italiano.</ref> per riferirsi a metodi di sviluppo software fu introdotto dal ''Manifesto Agile'' pubblicato nel 2001.<ref name="Agile Manifesto">[http://agilemanifesto.org/iso/it/manifesto.html Manifesto per lo Sviluppo Agile di Software]</ref>

== SinossiRiassunto generale ==

I metodi agili si contrappongono al [[modello a cascata]] (''waterfall model'') e altri [[Modello di sviluppo del software|modelli di sviluppo]] tradizionali, proponendo un approccio meno strutturato e focalizzato sull'obiettivo di consegnare al cliente, in tempi brevi e frequentemente (''early delivery'' / ''frequent delivery'')<ref>[http://www.quickfocus.com/blog/benefits-frequent-product-delivery-agile-principles Benefits of Frequent Product Delivery: Agile Principles]</ref>, software funzionante e di qualità. Fra le pratiche promosse dai metodi agili ci sono la formazione di team di sviluppo piccoli, poli-funzionali e auto-organizzati, lo sviluppo [[Modello incrementale|iterativo e incrementale]], la [[pianificazione adattiva]], e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo.

Riga 23:

=== Obiettivi ===

L'obiettivo è la piena [[soddisfazione del cliente]] e non solo l'adempimento di un contratto. Il corretto uso di queste metodologie, inoltre, può consentire di abbattere i costi e i tempi di sviluppo del software, aumentandone la qualità.

Essa è esplosa proprio in concomitanza con la crisi successiva al boom di Internet prendendo spunto dai metodi applicati in piccole [[software house]].

Riga 46:

* '''Comunicazione stretta''' - Secondo Alistair Cockburn, probabilmente il primo teorico delle metodologie agili, questo è l'unico vero aspetto nodale che rende ''agile'' una metodologia. Per comunicazione stretta si intende la comunicazione interpersonale, fra tutti gli attori del progetto, cliente compreso. Ciò serve ad avere una buona analisi dei requisiti ed una proficua collaborazione fra programmatori anche in un ambito di quasi totale assenza di documentazione;

* '''Consegne frequenti''' - Effettuare rilasci frequenti di versioni intermedie del software permette di ottenere più risultati contemporaneamente: si ricomincia l'iterazione avendo già a disposizione un blocco di codice funzionante in tutti i suoi aspetti, si offre al cliente "qualcosa con cui lavorare" e lo si distrae così da eventuali ritardi nella consegna del progetto completo, si usa il cliente come se fosse un test visto che utilizzerà il software e riscontrerà eventuali anomalie, si ottengono dal cliente informazioni più precise sui requisiti che probabilmente non sarebbe riuscito ad esprimere senza avere a disposizione utilità e carenze del progetto;

* '''Cultura di Team''' (One-team culture) - Fondamentale nel seguire approcci Agili è la collaborazione e l'approccio mentale e pratico del team di sviluppo stesso. Il criterio di lavoro più adatto sarebbe quello di abbandonare la tradizionale ''blaming culture'' (che prevede la penalizzazione o la premiazione del singolo individuo che commetta un errore, oppure che si distinguesse dagli altri per meriti) orientandosi invece verso un [[modus operandi]] 'di gruppo', in trasparenza ed onestà, che andrà a premiare (o viceversa) il gruppo stesso unicamente sulla base del raggiungimento degli obiettivi di team (previsti per quell'intervallo temporale);

* '''Facilitated Workshop''' - Una pratica a supporto dei principi di comunicazione e collaborazione, unitamente al mantenimento del focus sugli obiettivi di business. Questa tecnica consiste nel prevedere incontri (workshop) <u>facilitati</u> durante il progetto: la presenza di un facilitatore neutrale (facilitator) garantirà il successo del meeting, mantenendo costantemente l'incontro in linea con i suoi obiettivi, mantenendo il contesto adatto (libertà di parola, assenza di pressioni tra i partecipanti, decisioni non forzate, ecc.), e garantendo che vengano trasmesse a tutte le parti interessate tutte le informazioni necessarie sia precedenti che derivanti (follow-up) dal workshop stesso;

* '''Formazione di una squadra e Proprietà del codice''' - La formazione del team di sviluppo è condizionata dalla scelta sulla gerarchia interna, ma segue regole precise che permettono di ottenere un team produttivo nell'ambito della metodologia scelta; la scelta dei membri del team è condizionata anche alla scelta della proprietà del codice, che può essere individuale o collettiva; nel primo caso la responsabilità sullo sviluppo è individuale, nel secondo dipende da tutto il team e quindi dal project manager;

Riga 67:

In senso lato il termine "agile" indica tutte quelle metodologie di sviluppo leggere e flessibili, che rompono con la precedente tradizione di [[ingegneria del software]] ([[modello a cascata]], [[modello a spirale]], etc.) basata su una raccolta delle specifiche e su una strutturazione sequenziale dello sviluppo software.

Le metodologie agili consentono invece di rivedere di continuo le specifiche adeguandole durante l'avanzamento dello sviluppo del software, mediante un [[framework]] iterativo e incrementale, e un forte scambio di informazioni e di pareri tra gli sviluppatori e con il committente.

Esempi di metodologie e framework agili:

* [[Agile Unified Process]],

Riga 99:

* [[Scrum (informatica)]]

* [[Sviluppo software]]

* [[Lean innovation management]]

== Altri progetti ==