XP - Extreme programming

L’extreme programming o XP è un metodo agile orientato alla realizzazione di applicazioni informatiche e adatto a piccole equipe flessibili, ma può costituire comunque un modello utile per il project management in genere e per il problem solving.
L’XP spinge all’estremo concetti semplici. E’ una metodologia agile di sviluppo del software che enfatizza la scrittura di codice di qualità e la rapidità di risposta ai cambiamenti di requisiti.
Adotta uno sviluppo iterativo e incrementale per brevi cicli. Evita codice non strettamente necessario. Dà importanza alla comunicazione diretta fra sviluppatori e cliente.
Il metodo è costituito da programmazione a coppie, collaudo di singole unità di software, modifica di porzioni interne di codice senza modificare il comportamento esterno, sviluppo guidato dalle verifiche, integrazione continua delle modifiche.

XP - Extreme programming

Il flusso di un progetto di extreme programming parte dai racconti degli utenti (user stories), che vengono raccolti per conoscere i loro problemi, bisogni, abitudini. Questi materiali, che sono spesso più dettagliati dei requisiti tecnici, servono a creare i test di accettazione con cui verificare se le richieste degli utenti sono state soddisfatte. Gli sviluppatori valutano di quanto tempo un racconto ha bisogno per trasformarsi in codice di programmazione. Se servono più di tre settimane il racconto va suddiviso in sotto-racconti. Al di sotto di una settimana il racconto si combina con altri racconti. Con un’ottantina di racconti si può creare un buon piano di consegne (release plan), con cui si pianifica nel tempo lo sviluppo delle varie storie. Si aggiunge agilità al processo di sviluppo con cicli iterativi di sviluppo (una dozzina di iterazioni che vanno da una a tre settimane). Le iterazioni vengono pianificate di volta in volta, per aderire meglio alle richieste di cambiamento dei clienti. In ogni iterazione si deve cercare di completare la parte che si sta sviluppando, invece di lasciare più parti tutte incomplete.
La velocità del progetto si misura con il numero di racconti che vengono sviluppati in una iterazione. Una iterazione si basa sulla velocità ottenuta nell’iterazione precedente. Se per la nuova iterazione occorre meno tempo può aumentare la velocità dell’intero progetto. Se la velocità cambia in più di una iterazione va rinegoziato il piano di rilascio dell’intero progetto. Tracciare il lavoro fatto in ciascuna iterazione è l’unico modo per far procedere il progetto lungo uno sviluppo prevedibile.
La metafora di sistema è un insieme di nomi non tecnici che definisce la struttura architetturale del sistema. Se emerge qualche problema lo si isola con un picco architetturale (architectural spike), ossia un programma semplificato che affronta solo quel problema senza preoccuparsi di fornire un prodotto usabile. Una volta risolto il problema, i risultati del picco si possono buttare.

cicli xp

Un elemento chiave dell’XP è la progressiva riduzione dei cicli di feedback, con cui è possibile garantire una continua rispondenza alle richieste del cliente. Il piano di rilascio del prodotto completo prevede un feedback a distanza di mesi; il piano del ciclo di iterazione accetta un feedback dopo settimane; il test di accettazione del prodotto prima di sottoporlo al cliente arriva dopo alcuni giorni; la riunione in piedi all’inizio di ogni ciclo giornaliero richiede un giorno; la negoziazione a coppie, in cui si confrontano competenze e punti di vista diversi sullo stesso problema, richiede qualche ora; i test unitari automatici che controllano piccole parti di codice richiedono qualche minuto; la programmazione a coppie ha un feedback continuo.

In tal modo i feedback agiscono a qualsiasi livello di dettaglio della programmazione, e individuano subito malfunzionamenti o fraintendimenti delle richieste del cliente.

I principi che caratterizzano un progetto estremo sono:

  • comunicazione tra manager e clienti e tra clienti e sviluppatori;
  • coraggio nell’affrontare sfide, contraddizioni, cambiamenti richiesti dai clienti;
  • feedback, dai continui test unitari alle verifiche dei cicli di sviluppo: il cliente è sempre presente, a qualsiasi livello di dettaglio del programma e le correzioni sono immediate;
  • rispetto per i programmatori che devono essere a loro agio e per i clienti che devono essere soddisfatti;
  • semplicità nel design e nell’implementazione.