Nel 1999 fu pubblicato Extreme Programming Explained, nel quale l'autore Kent Beck presenta un nuovo modo di sviluppare software, che permette di limitare i rischi di fallimento strettamente legati all'attività di progettazione.
Sono Diego Purpo e insieme scopriremo l'Extreme Programming.
L'Extreme Programming, comunemente chiamato XP, è una metodologie agile, probabilmente la più famosa, e come tale cerca di rispondere agli obiettivi fissati dal Manifesto dello Sviluppo Software Agile.
In particolar modo mira alla realizzazione di un processo di sviluppo leggero e flessibile, adatto a rispondere, in tempi brevi e con costi ridotti, alle mutevoli richieste del committente, anche in fase avanzata del progetto.
l'XP propone l'utilizzo di 12 pratiche agili già affermate, non ne introduce di nuove, e suggerisce di usarle al massimo delle loro potenzialità, da qui il termine "extreme".
Esaminiamo alcune di queste pratiche nel dettaglio.
Tra le pratiche consigliate, il Pair Programming prevede l'impiego di 2 programmatori sullo stesso task, su un solo computer ed una sola tastiera. Il driver scrive il codice ed il navigator osserva e controlla ogni riga prodotta. I 2 ruoli sono spesso alternati.
Small Releases prevede il rilascio continuo di build, piccoli aggiornamenti funzionanti e non dipendenti da future implementazioni. Il cliente avrà, in tal modo, la percezione dell'evoluzione del progetto.
Altra pratica è il Planning Game, una riunione tra team e clienti, da tenere prima di ogni iterazione. Obiettivo del Planning game è creare un momento di raccolta durante il quale il cliente definisce una lista di richieste, ordinata per priorità. I progettisti rispondono in termini di costi e tempi.
Alla fine il meeting produce la definizione di un nuovo set di attività, sulla base delle informazioni raccolte durante la fase di dibattito.
Altra peculiarità dell'XP è il Test Driven Development. Le Unit Test, solitamente preparate a codice ultimato, nel caso dell'XP sono scritte ancor prima di iniziare lo sviluppo. Il Test Driven Development assicura robustezza, in quanto tutto il codice applicativo prodotto è stato effettivamente testato.
Il Simple design introduce l'approcio "simple is best". A task ultimato uno sviluppatore dovrebbe chiedersi se esista un modo più semplice per realizzare lo stesso compito, e, in caso di risposta affermativa, provvedere all'alleggerimento del codice.
Tale pratica stimola il Refactoring, nel caso in cui il processo di semplificazione coinvolga parti complesse di codice.
Altre pratiche hanno impatto sulla scelta dei nomi delle classi e dei metodi e sul code style, cioè seguire una convezione o uno standard per la codifica.
Spesso le metodologie agili contemplano pratiche non strettamente legate all'ambito tecnico, ma più orientate alla gestione delle risorse umane. XP non fa eccezione. A questo proposito sono consigliabili strutture Open Space rispetto ai cubicoli ed ritmo di lavoro sostenibile, non più di 40 ore settimanali.
L'Extreme Programming riscuote molto successo nel mondo dello sviluppo e dell'ingegneria del software, ma ha anche i suoi detrattori. Essi evidenziano alcuni fattori critici nel metodo, vediamo quali.
C'è chi sostiene che l'XP funzioni solo con sviluppatori di alto profilo, capaci di progettare applicazioni scalabili da subito o in grado di applicare un buon refactoring.
Il Pair Programming dimezzerebbe il numero di task eseguibili in parallelo, mentre il test driven development costringe a scrivere suite di test ovvero altro codice da scrivere e mantenere.
L'estremismo dell'XP non sempre è apprezzato, ma gli va riconosciuto il merito di evidenziare pratiche agili di successo. Tra queste, può valere la pena sperimentare in ambiente produttivo quelle che più si avvicinano alla filosofia aziendale
