Metodi agili

In un contesto (odierno) in cui le aziende lavorano in un ambiente globale dal cambiamento rapido, esse devono cogliere nuove opportunità e rispondere a nuovi mercai alle condizioni economiche variabili e alla presenza di prodotti e servizi concorrenti. Il software è parte essenziale delle operazioni aziendali, esso deve trarre vantaggio dalle nuove opportunità. La rapidità dello sviluppo e della consegna è quindi il requisito più critico per la maggior parte dei sistemi software aziendali. Spesso è praticamente impossibile ottenere un insieme completo di requisiti stabili, i requisiti cambiano perché per i clienti è impossibile prevedere come un sistema influenzerà le pratiche operative, come interagirà con gli altri sistemi e quali operazioni degli utenti dovranno essere automatizzate. I requisiti reali diventano chiari solo dopo che il sistema è stato consegnato e utilizzato dagli utenti, fattori esterni possono indurre a modificare ulteriormente i requisiti.

I metodi agili sono particolarmente indicati per sviluppare applicazioni nelle quali i requisiti del sistema cambiano rapidamente durante il processo di sviluppo. Interessante per consentire una consegna rapida ai clienti che possono quindi proporre requisiti nuovi o modificati da includere in successive iterazioni del sistema. I metodi agili suggeriscono che il software deve essere sviluppato e consegna in modo incrementale. I principi agili sono utili per due tipi di sviluppo di sistemi:

  • Lo sviluppo di prodotti di piccole e medie dimensioni
  • Lo sviluppo personalizzato di sistemi all'interno di un'organizzazione dove c'è un chiaro impegno da parte del cliente di essere coinvolto nel processo di sviluppo.

Principi agili:
...

  • Adottare un metodo agile non significa evitare del tutto la modellazione, bensì lo scopo della modellazione è quello di agevolare la comprensione e la comunicazione, non di documentare.
  • Non si deve modellare o applicare UML per eseguire per intero o per buona parte la progettazione del software. É norma rimandare problemi di progettazione semplici o diretti alla fase di programmazione e risolverli nel corso della programmazione e dei test.
  • Va utilizzato uno strumento più semplice possibile, che aiutino la creatività con il minimo dispendio di energie, ad esempio: bozza di UML alla lavagna
  • La modellazione non va fatta da soli, ma piuttosto a coppie (o in tre) con lo scopo di scoprire, capire e condividere ciò che si è compreso.
  • Solo il codice verificato dimostra il vero progetto, tutti i diagrammi precedenti sono suggerimenti incompleti, ed è meglio considerarli come semplici esplorazioni usa e getta
  • La modellazione per progettazione OO (Object Oriented) dovrebbe essere eseguita dali stessi sviluppatori che si occuperanno della programmazione, creare modelli da passare ad altri programmatori significa seguire pratiche a cascata, opposte alla filosofia agile.

Extreme programming è uno dei metodi agili più noti.

Tra le pratiche innovative dei metodi agili:

  • Storie utente, sono scenari d'uso in cui potrebbe trovarti un utente del sistema. Il cliente del sistema lavora a stretto contatto con il team di sviluppo e descrive questi scenari con altri membri del team.
  • Refactoring, non ha senso progettare per il cambiamento, le modifiche previste non si avverano mai, le modifiche dovranno sempre essere apportate al codice che si sta sviluppando, il codice è costantemente rifattorizzato, lo sviluppo incrementale deteriora la struttura del software.
  • Sviluppo con test iniziali, lo sviluppo non può procedere finchè tutti i test non sono stati superati, sviluppo guidato dai test
  • Programmazione a coppie, programmatori siedono realmente alla stessa postazione di lavoro per sviluppare il software, supporta l'idea della proprietà e della responsabilità comune del sistema, revisione informale, incentiva il refactoring

Lo sviluppo agile deve essere gestito in modo che venga fatto il miglior uso del tempo e delle risorse a disposizione del team. Il metodo agile Scrum cerca di risolvere questo problema.

Problemi pratici con i metodi agili
...

  • L'informalità dello sviluppo agile è incompatibile con l'approccio legale alla definizione dei contratti che di solito si usano nella grandi società.
  • I metodi agili sono più indicati per lo sviluppo di nuovo software, non per la manutenzione del software, eppure la maggior parte dei costi del software nella grandi società proviene dalla manutenzione dei loro sistemi software esistenti.
  • I metodi agili sono ideati per piccoli team fisicamente vicini, eppure la maggior parte dello sviluppo del software oggi coinvolge team distribuiti in tutto il mondo.

La scalabilità dei metodi agili richiede che alcune pratiche basate sui piani siano integrate con le pratiche agili (ad esempio: più documentazione, più rappresentanti del cliente, strumenti comuni per i team e allineamento delle release).