Lo sviluppo software di applicazioni informatiche è sempre più complesso. Integrazioni tra sistemi, sicurezza, disponibilità su dispositivi molto diversi, sono solo alcuni dei requisiti che un buon software deve avere oggi.
A tutto questo si aggiunge il fatto che per mantenere la propria competitività, le aziende si devono poter adattare alle esigenze del mercato e dei propri clienti con la massima rapidità, pena scomparire!
In questo scenario è evidente che investire grandi capitali nello sviluppo di software per il cui sviluppo sono necessari anni di lavoro, non è più una prospettiva sostenibile per nessuna azienda che voglia puntare al successo.
Che cos’è il manifesto Agile
Sviluppare con la metodologia Agile significa un sacco di cose, ma la più importante è che, tenuto fermo l’obiettivo principale (end-point), lo sviluppo del software si adatta al contesto rilasciando progressivamente le sue funzionalità.
Il team di lavoro (fatto dal cliente e dagli sviluppatori) si autogestisce dandosi traguardi intermedi che, nel realizzare la migliore soluzione “possibile”, tengano conto delle esigenze di tutti. Per questo più che sulle tecnologie, quando si sviluppa in modalità Agile, ci si concentra sulla relazione e sul facilitare i processi.
Nell’approccio Agile il software finale viene prodotto un pezzetto alla volta attraverso quelli che in gergo tecnico si chiamano “sprint”.
Ogni sprint in genere è composto dalle seguenti fasi (tra parentesi la traduzione per chi non mastica questo linguaggio):
- Plan (Pianificazione)
- Design (Progettazione)
- Build (Scrittura del codice)
- Test (Prova del codice)
- Review (Revisione)
- Launch (Rilascio in produzione)
I vantaggi del metodo Agile rispetto allo sviluppo tradizionale
Il vantaggio è immediatamente percepibile. Immaginate di dover sviluppare un ERP aziendale e di aver stimato di dedicare a questa attività un anno di tempo.
Con lo sviluppo “classico” quello che accade è che, dopo una estenuante analisi, il team di programmatori “scompare” per riapparire con il prodotto finito dopo un anno.
Ammesso e non concesso che dopo un anno si sia realmente al traguardo, qualunque cosa sia successa nel frattempo non verrà considerata.
In questo scenario, sia che ci siano stati cambiamenti nelle necessità del committente o mal interpretazioni delle necessità da parte degli sviluppatori, quello che sarà certo è che il committente si troverà in mano qualcosa di non perfettamente aderente alle sue esigenze.
Immaginiamo adesso di fare un grosso sforzo iniziale e di dividere il nostro software in dodici parti interconnesse ma funzionalmente indipendenti. In questo modo sarà possibile pensare il nostro software come se fosse fatto di 12 sotto-programmi a cui “idealmente” attribuire un mese di sviluppo. Ora, nella realtà le cose non sono così precise e “matematiche”, ma l’esempio rende bene l’idea del differente approccio.
Avere 12 sotto-programmi ci permetterà di sviluppare in maniera più efficiente, in quanto il confronto costante e reiterato nel tempo con il cliente farà sì che eventuali cambi di rotta o malfunzionamenti vengano individuati immediatamente, evitando pericolose derive.
Ecco che il processo di consegna degli step di sviluppo non sarà più un confronto in cui, da un lato i programmatori cercano di convincere il cliente della bontà delle loro scelte e, dall’altro, il cliente di spiegare che con quel software non riuscirà a migliorare le sue performance lavorative.
La sinergia tra cliente e team di sviluppo e la presenza di figure che facilitano i processi, fa sì che nella modalità “Agile” i problemi vengano affrontati e risolti prima che diventino “tragedie”.
Contattaci per scoprire come possiamo fare la differenza insieme!
