Prima di parlare di Sviluppo agile, bisogna parlare di insuccesso, ossia tutte le situazioni che puntualmente si presentano e concorrono per far fallire un progetto software.

Ci sono alcuni fattori, infatti, che maggiormente pesano sull’insuccesso dei progetti e sono :

  1. La stima di costi e risorse. Spesso si sottovaluta il progetto sotto stimando le risorse,  i costi del progetto rischiano di lievitare senza controllo. A questo proposito non è detto che inserendo nuove risorse al progetto, questo riprende vita, anzi le persone devono essere formate sul progetto in corso, quindi le risorse impiegate devono investire energie per la formazione sottraendo enerigia allo sviluppo. Quindi i costi aumentano e lo sviluppo rallenta.
  2. Il progetto è cosi complesso che richiede spesso sforzi importanti di analisi. Il costo e l’investimento per l’analisi di fattibilità è tale che non si prende in considerazione l’investimento sul progetto vero e proprio,  quindi il progetto fallisce prima di cominciare.
  3. Rigidità burocratica, il progetto può risultare irrigidito o burocratizzato da troppi orpelli non sempre utili. E’ meglio impiegare gli sviluppatori per fare codice funzionante che report e grafici.
  4. Bassa la capacità di reazione al cambiamento, può accadere che il contesto cambi, quello che i project manager chiamano lo scope, se non correggiamo la rottta in tempo rischiamo che, a progetto finito, risultiamo fuori mercato.
  5. Le continue modifiche richieste dal committente in fase di sviluppo fanno slittare i tempi del progetto e quindi la data del rilascio viene continuamente posticipata.  Il risultato conseguente è crescita sia dei costi che dell’impazienza del committente, privo di riscontri del suo investimento.

Ingegneria del software, storicamente, ci propone due approcci per gestire lo sviluppo di progetti o prodotti ma molto spessi non evitano i rischi sopracitati. Queste metodologie vengono etichettate come pesanti, vedremo il perchè in seguito.

Il primo approccio e un classico del project management il modello Waterfall, (cascata) che prevede un grafico di Gaant con le relazioni tra le varie attività e le tempistiche delle stesse.

 

modello pesante Waterall

modello pesante Waterall

 

Il secondo metodo è quello cosiddetto a spirale. Questo approccio prevede una serie di cicli in cui si svolgono le fasi di pianificazione, scrittura dei test, implementazione del codice, e cosi via fino al rilascio del prodotto o progetto che sia.

 

modello pesante a Spirale

modello pesante a Spirale

 

Questo modo di lavorare prevede un dialogo continuo con il committente, qualora questo dialogo dovesse venir meno quest’ultimo, come nel caso precedente,  non la sensazione di progresso del progetto. Un altro rischio è quello di aumentare troppo e in maniera non prevista il numero di iterazioni del ciclo produttivo facendo slittare la data del rilascio, con le conseguenze gia descritte in precedenza.

L’approccio “pesante”,  soprattutto nelle piccole e medie realtà, provoca un overhead ai sistemi aziendali tali che risulta dominante sull processo di sviluppo. Il tempo impiegato per decidere come il sistema deve essere sviluppato risulta maggiore del tempo impiegato per lo sviluppo e test del progetto. Le principali critiche infatti a tali approcci sono :

  • Inefficienza in determinati contesti
  • Rigidità
  • Lentezza
  • Produzione di grandi quantità di documenti e diagrammi

Nel febbraio del 2001, alcuni tra i maggiori progettisti software e guru del calibro di Martin Fowler, padre dei design pattern, e Ward Cunningham, inventore del wiki, si riunirono per trovare assieme una soluzione per superare gli ostacoli della progettazione classica.  Nasce cosi il Manifesto dello sviluppo Agile, i cui principi sono :

  1. persone e interazioni più che processi e strumenti
  2. software funzionante più che documentazione
  3. collaborare con i clienti più che definire il contratto
  4. rispondere ai cambiamenti più che aderire al progetto

Quel gruppo di pensatori è oggi noto come Agile Alliance e sono (in ordine alfabetico): Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

Nascono molte metodologie innovative per lo sviluppo del software, che prendono il nome di agili perchè consentono di rivedere le specifiche iniziali del progetto in corso d’opera, coinvolgono più possibile il committente.  Tutte queste metodologie difatto sono basate su gli stessi obiettivi espressi dal manifesto :

  • limitare il rischio di fallimento
  • soddisfare il cliente
  • abbattere i costi di sviluppo

Tra le principali e più conosciute si può citare Extreme Programming, SCRUM, Kanban, Feature Driven Development, Crystal.

I metodi agili, quindi, si prestano dei processi di sviluppo empirici questo perchè si adattano in corso d’opera al processo a seconda di quanto accade durante il progetto.  In definitiva, il movimento agile mira a fornire strumenti per creare ambienti di sviluppo dinamici, che rispondono velocemente ed a costi sostenibili alle mutevoli richieste di mercato.

I detrattori degli approcci agili denunciano una progettazione spesso limitata e carenza di struttura e di documentazione.  C’è chi sostiene, inoltre, che tali metodi, per funzionare, richiedano team di soli sviluppatori senior molto responsabili e soprattutto un forte cambiamento culturale dell’azienda.

Annunci