I metodi agili sono stati definiti per rispondere all’esigenza di dover affrontare lo sviluppo di software in continuo cambiamento. Durante lo sviluppo si hanno vari passaggi:

• comprensione dei prerequisiti
• scoperta di nuovi requisiti o cambiamento dei vecchi

Questa situazione rendeva difficile lo sviluppo secondo il vecchio metodo waterfall portando al fallimento di diversi progetti.

I metodi agili ammettono che i requisiti cambino in modo “naturale” durante il processo di sviluppo software e per questo assumono un modello di processo circolare, con iterazioni della durata di un paio di settimane .

Rappresentazione grafica del modello agile.

Potenzialmente dopo un’iterazione si può arrivare ad un prodotto che può essere messo in “produzione”. Dopo ogni rilascio si raccolgono feedback per poter rivalutare i requisiti e migliorare il progetto.

Si hanno quindi aspetti comuni nei metodi agili e nel loro processo:

• enfasi sul team, sulla sua qualità e sulla sua selezione
• il team è self organizing, non esiste un manager ma è il team stesso a gestire lo sviluppo
• enfasi al pragmatismo, focalizzandosi su una documentazione efficace evitando di produrre documenti inutili e difficili da mantenere
• enfasi sulla comunicazione diretta, sostituendo i documenti suddetti con meeting e riunioni periodiche
• enfasi sull’idea che nulla sia definitivo: la perfezione non deve essere seguita fin da subito, ma saranno gli step a portare al raggiungimento di una perfezione finale (anche dal punto di vista del design)
• enfasi sul controllo costante della qualità del prodotto, anche tramite
  • continuous testing: test automatici dopo ogni modifica
  • analisi statica e dinamica del codice al fine di trovare difetti nello stesso
  • refactoring

I metodi agili sono molto “elastici” e permettono la facile definizione di nuovi metodi facilmente adattabili al singolo progetto.

Scrum

Uno dei più famosi, tra i vari metodi agili, è scrum.

In questo caso la parte di sviluppo e iterazione prende il nome di sprint ed ha una durata tra una e quattro settimane, per avere un rilascio frequente e una veloce raccolta di feedback.

I requisiti sono raccolti nel cosiddetto product backlog, con priorità basata sulla base delle indicazioni del committente. Ad ogni sprint si estrae dal product backlog lo sprint backlog, ovvero il requisito da implementare nello sprint. Si ottiene quindi di volta in volta un pezzo di prodotto finale, testato e documentato. Durante le settimane di sprint si effettua anche un meeting giornaliero utile per mantenere alti i livelli di comunicazione e visibilità dello sviluppo. Durante il meeting ogni sviluppatore risponde a tre domande: