Tra gli approcci che stanno cambiando il modo di lavorare, figurano metodi e strumenti di supporto al processo di produzione del software. In tale ambito si colloca l’eXtreme Programming (XP), tra le più note metodologie agili di Project Management
Lo sviluppo del software ha subito notevoli trasformazioni nel corso della storia dell’informatica, partendo da procedure confuse e non organizzate, fino ad arrivare a processi strutturati di sviluppo definiti dall’ingegneria del software.
Un processo di sviluppo è l’insieme delle metodologie, delle buone prassi e delle procedure che permettono la creazione, la documentazione e la manutenzione di un sistema software in maniera efficiente ed efficace. Extreme programming è un particolare processo di sviluppo software che si inserisce nel contesto delle metodologie Agili.
Le metodologie agili nel project management hanno lo scopo di definire modalità e pratiche molto leggere nella gestione dei progetti ed utilizzano un set di documentazione minimo ma funzionale e facilmente mantenibile, in contrapposizione ai processi tradizionali di gestione fortemente burocratizzati che pongono l’accento su un processo rigido e una documentazione molto dettagliata.
L’XP, nel processo di sviluppo del software, promette di:
- mantenere la controllabilità del processo pur riducendo il lavoro di supporto;
- convogliare lo sforzo sulla mera produzione dell’applicazione, evitando la produzione di semilavorati diversi da quelli necessari alla realizzazione delle applicazioni;
- fornire i meccanismi affinché gli sviluppatori possano acquisire, durante lo sviluppo, la consapevolezza che ciò che stanno costruendo soddisferà pienamente le esigenze del committente
Filosofia e valori dell’XP
Extreme programming è un processo di sviluppo basato su quattro valori fondanti:
- Comunicazione – tra cliente e team di sviluppo e all’interno dello stesso team, come risorsa necessaria affinché tutte le informazioni siano correttamente elaborate al fine di ottenere un sistema più aderente possibile alle esigenze del cliente
- Feedback – frequenti e costanti da parte del cliente, durante tutta la vita del progetto per riuscire a governare i possibili ed inevitabili cambiamenti
- Semplicità – per mantenere il design del sistema e il codice più puliti possibile, in modo da favorire le modifiche e la manutenzione
- Coraggio – nel modificare il sistema, per l’uso di pratiche di verifica del corretto funzionamento del sistema anche dopo numerose modifiche
Extreme programming è la metodologia ideale per chi vuole:
- Avere un sistema di sviluppo estremamente rapido
- Coinvolgere al massimo il cliente nel processo
- Essere scrupoloso nella prevenzione dei malfunzionamenti
- “Abbracciare il cambiamento” senza aver paura di modificare il codice
- Coinvolgere al massimo gli sviluppatori dando a tutti l’accesso al codice
- Mettere al centro il rispetto delle persone e dei loro dei bisogni personali, sociali e psicologici
Lo sviluppo del progetto
Con l’XP lo sviluppo del progetto viene diviso in sottoparti con rilasci successivi. Il lavoro dei programmatori procede organizzando quattro attività fondamentali che si ripetono per tutto il corso del progetto:
- coding – scrittura del codice dell’applicazione
- testing verifica delle funzionalità
- listening osservazione dell’ambiente, inteso come bisogni del committente, opportunità tecnologiche,trend di mercato
- design progetto dell’applicazione
La costruzione dell’applicazione procede in maniera iterativa, cogliendo le reazioni dei committenti e riprogettando, in maniera adeguata, le sue funzionalità e i meccanismi adottati per ottenerle.
Le prassi fondamentali di XP
Extreme programming è un processo di sviluppo adattivo che si implementa attraverso una serie di pratiche di codifica, di design e socio-psicologiche che aiutano i programmatori a rendere il loro lavoro il più efficiente possibile.
Pratiche di codifica
Uso di standard per la codifica (Coding standards)
Il codice deve rendere esplicito il meccanismo logico con cui è stato creato, in modo che ciascun sviluppatore sia in grado di capire e modificare ogni linea di codice scritta dagli altri. Il codice, inteso come principale strumento di comunicazione, deve, pertanto, essere scritto in maniera uniforme e omogenea.
Verifica di ogni funzionalità (Testing)
Ogni funzionalità va sottoposta a verifica, in modo che si possa acquisire una ragionevole certezza sulla sua correttezza. Ciò sia a livello di sistema (test di sistema) sia a livello del singolo metodo (test di unità). I test di sistema sono costruiti sulla base delle storie concordate con il committente che dice l’ultima parola sulla convalida del sistema. I test di unità devono poter essere rieseguiti automaticamente con l’uso di opportuni strumenti.
Ristrutturazione del codice (Refactoring)
Un’applicazione necessita di continue riprogettazioni per eliminare le parti divenute superflue e per adattare il sistema alle nuove esigenze. Ogni volta che si presenta la possibilità di eliminare parti superflue o di semplificarne l’organizzazione, l’intera struttura del codice va adattata ai nuovi principi progettuali.
Pratiche di design
Progetti semplici (Simple design)
La struttura dell’applicazione deve essere semplice. L’architettura del sistema deve essere comprensibile da tutte le persone coinvolte nel progetto. Non devono esserci parti superflue o duplicazioni. Solo quando nuove circostanze lo richiederanno, verranno progettati nuovi componenti, eventualmente riprogettando anche quelli già esistenti.
Rilasci frequenti (Short releases)
La vita e lo sviluppo dell’applicazione sono scanditi dai rilasci di versioni del prodotto funzionanti. Ogni rilascio realizza uno degli scenari d’uso (storie) che il sistema deve soddisfare e rappresenta il punto conclusivo di un’iterazione di sviluppo e l’inizio di una nuova pianificazione. Per poter tener conto di cambi di prospettiva, errori di valutazione, nuovi requisiti, restrizioni di bilancio, ogni iterazione dovrebbe durare non più di qualche settimana (in genere, da due a quattro).
Integrazione continua (Continuous integration)
Deve essere costantemente possibile ottenere una versione funzionante dell’applicazione sulla quale operare le verifiche. Una piattaforma pronta per l’integrazione deve essere sempre disponibile per i programmatori.
Pratiche sociali, psicologiche e organizzative
Programmazione a coppie (Pair programming)
Due programmatori che lavorano al medesimo terminale scrivono il codice. Le coppie non sono fisse, ma si compongono associando le migliori competenze per la risoluzione di uno specifico problema. Il lavoro in coppia permette, scambiandosi periodicamente i ruoli, di mantenere mediamente più alto il livello d’attenzione.
Pianificazione delle attività (Planning the game)
Lo sviluppo dell’applicazione è accompagnato dalla stesura di un piano di lavoro. Il piano è definito e, continuamente aggiornato, a intervalli brevi e regolari dai responsabili del progetto, secondo le priorità aziendali e le stime dei programmatori,che partecipano, in modo attivo, alla pianificazione.
Gli utenti finali dell’applicazione presentano gli obiettivi da raggiungere descrivendo una serie di scenari (storie) che il sistema deve soddisfare. Gli sviluppatori stimano il tempo necessario per la realizzazione di ogni storia. Le storie vengono ordinate da utenti e responsabili secondo la loro priorità di realizzazione, dopo che gli sviluppatori ne hanno stimata la rispettiva difficoltà. Dalla sintesi di queste valutazioni i responsabili del progetto generano la pianificazione delle attività, misurando e controllando l’andamento delle attività rispetto alla pianificazione stessa. Questo processo viene ripetuto dopo ogni rilascio per pianificare il successivo.
Partecipazione del committente (Onsite customer)
Il committente deve essere coinvolto nello sviluppo perché è l’unica fondamentale fonte di convalida del sistema. Partecipa perciò alla stesura dei test di sistema e verifica, periodicamente, che il sistema realizzato corrisponda effettivamente alle proprie esigenze.
Collettivizzazione del codice (Collective ownership)
Il codice dell’applicazione può essere liberamente manipolato da qualsiasi sviluppatore, perché è scritto rispettando regole condivise da tutti. Naturalmente ogni modifica non deve pregiudicare la correttezza dei test.
Conclusioni
Le raccomandazioni dell’XP si inquadrano nel solco delle proposte di processi di produzione di software agili e flessibili che in quanto tali, forniscono un bagaglio concettuale utile al progettista di oggi.
