Extreme Programming

Da Wikipedia, l'enciclopedia libera.

L'Extreme Programming (espressione inglese per programmazione estrema, spesso abbreviato in XP) è una metodologia agile e un approccio all'ingegneria del software formulato da Kent Beck, Ward Cunningham e Ron Jeffries. Beck scrisse il primo libro sull'XP, Extreme Programming Explained, pubblicato nel 1999.

Tra gli aspetti caratteristici dell'extreme programming vi sono la programmazione a più mani (generalmente in coppia), la verifica continua del programma durante lo sviluppo per mezzo di programmi di test e la frequente reingegnerizzazione del software, di solito in piccoli passi incrementali, senza dover rispettare fasi di sviluppo particolari.

Regole[modifica | modifica sorgente]

Le dodici regole (o pratiche) che sono alla base di Extreme Programming possono essere raggruppate in quattro aree:

Feedback a scala fine

  • Pair Programming - Due programmatori lavorano insieme su una sola workstation, uno sta alla tastiera e l'altro ragiona sull'approccio e pensa se può funzionare. Questo rende il codice prodotto di migliore qualità. I due programmatori devono avere la stessa esperienza.
  • Planning Game - è una riunione di pianificazione che avviene una volta per iterazione, tipicamente una volta a settimana.
  • Test Driven Development - i test automatici (sia unitari che di accettazione) vengono scritti prima di scrivere il codice.
  • Whole Team - in XP, il "cliente" non è colui che paga il conto, ma la persona che realmente utilizza il sistema. Il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali o Jour fixe).

Processo continuo

  • Continuous Integration - Integrare continuamente i cambiamenti al codice eviterà ritardi più avanti nel ciclo del progetto, causati da problemi d'integrazione.
  • Refactoring o Design Improvement - riscrivere il codice senza alterarne le funzionalità esterne, cambiando l'architettura, in modo da renderlo più semplice e generico.
  • Small Releases - consegna del software avviene tramite frequenti rilasci di funzionalità che creano del valore concreto.

Comprensione condivisa

  • Coding Standards - Scegliere ed utilizzare un preciso standard di scrittura del codice. Questo rappresenta un insieme di regole concordate, che l'intero team di sviluppo accetta di rispettare nel corso del progetto.
  • Collective Code Ownership - significa che ognuno è responsabile di tutto il codice; quindi contribuisce alla stesura chiunque sia coinvolto nel progetto.
  • Simple Design - i programmatori dovrebbero utilizzare un approccio del tipo "semplice è meglio" alla progettazione software. Progettare al minimo e con il cliente.
  • System Metaphor - descrivere il sistema con una metafora, anche per la descrizione formale. Questa può essere considerata come una storia che ognuno - clienti, programmatori, e manager - può raccontare circa il funzionamento del sistema.

Benessere dei programmatori

  • Sustainable Pace - il concetto è che i programmatori o gli sviluppatori software non dovrebbero lavorare più di 40 ore a settimana.

Modello dei processi[modifica | modifica sorgente]

James Donovan Wells individua quattro linee guida:

  • Comunicazione (tutti possono parlare con tutti, persino l'ultimo dei programmatori con il cliente);
  • Semplicità (gli analisti mantengano la descrizione formale il più semplice e chiara possibile);
  • Feedback (sin dal primo giorno si testa il codice);
  • Coraggio (si dà in uso il sistema il prima possibile e si implementano i cambiamenti richiesti man mano).

Individua inoltre quattro fasi di progetto, ognuna delle quali con le sue regole interne:

  • Pianificazione (User Stories, Release Planning, Small Releases, Project Velocity, Load Factor, Iterative Development, Iteration Planning, Move People Around, Daily Stand Up Meeting, Fix XP);
  • Progettazione (Simplicity, System Metaphor, CRC Cards, Spike Solution, Never Add Early, Refactoring);
  • Sviluppo (Customer Always Available, Standards, Unit Test First, Pair Programming, Sequential Integration, Integrate Often, Collective Code Ownership, Optimize Last, No Overtime);
  • Testing (Unit Test Framework, Bug's found, Functional Test o Acceptance Tests).

Ruolo di XP nell'ingegneria del software[modifica | modifica sorgente]

Su Extreme Programming c'è da dire che, essendo una metodologia molto famosa, è anche molto controversa. In effetti si può notare che, per quanto particolareggiata, è comunque una metodologia leggera non troppo differente dalle altre. Deve sicuramente la sua fortuna al lavoro dell'autore che ha saputo coglierne gli aspetti positivi e trasmetterli, anche quando i progetti gestiti sono falliti, fra questi il primo in assoluto. D'altronde è Kent Beck stesso ad ammettere questi fallimenti, anzi a considerarli parte integrante della filosofia di fondo della metodologia ed a confermare che di tutte le pratiche di Extreme Programming, la più importante è il carisma del project manager.

Extreme Programming però ha dato un impulso importante alla diffusione delle metodologie leggere ed alla discussione sulle singole pratiche e sulle conseguenze dei loro utilizzi. Da questo punto di vista la bibliografia su Extreme Programming è vastissima ed è utile sfruttarne le risorse disponibili per una riflessione approfondita sui particolari delle metodologie leggere in generale.

Bibliografia[modifica | modifica sorgente]

Voci correlate[modifica | modifica sorgente]

Altri progetti[modifica | modifica sorgente]

Collegamenti esterni[modifica | modifica sorgente]