Concetto: Pratiche agili e RUP
Questa guida esamina come applicare alcune delle "pratiche ottimali" identificate nella comunità agile per progetti basati su RUP che desiderano trarre vantaggio da alcune di dette pratiche.
Relazioni
Descrizione principale

Argomenti

Introduzione

Rational Unified Process (RUP) è un framework di processi che Rational Software ha rifinito negli anni e che è ha trovato vasto impiego in tutti i tipi di progetti software, piccoli o grandi che siano. Di recente, un numero crescente di processi "agili", quali eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) e Crystal Clear Methodology, sono riconosciuti sempre più come metodi efficaci per la progettazione di sistemi di dimensioni ridotte. (Per ulteriori informazioni su Agile Alliance, vedere www.agilealliance.org).

Le sezioni successive sono destinate ad assistere i team di progetto nel valutare alcune delle pratiche "agili" individuabili in uno di detti metodi per determinare come gli stessi sono risolti in maniera più completa dal processo di sviluppo software definito da RUP (per ulteriori informazioni su RUP, vedere Introduzione a RUP).

Panoramica

La comunità agile ha sintetizzato un numero di "pratiche migliori" applicabili specialmente a team di progetto piccoli colocalizzati. Sebbene RUP sia concepito per team di progetto di qualsiasi dimensione, può essere applicato con successo anche a progetti piccoli. In genere, RUP e i processi della comunità Agile hanno una visione simile delle pratiche migliori chiave necessarie per sviluppare software di qualità, ad esempio, l'applicazione di sviluppo iterativo e focalizzando sugli utenti.

La sezione successiva esamina come applicare alcune delle pratiche migliori identificate nella comunità agile per progetti basati su RUP che desiderano sfruttare alcune di dette pratiche.In questo caso, l'obiettivo è puntato in modo specifico sulle pratiche presentate dalla metodologia eXtreme Programming (XP). (Per ulteriori informazioni su XP, fare riferimento al sito Web: http://www.extremeprogramming.org.)

Pratiche XP

XP si compone di quattro "attività" base - codifica, verifica, ascolto e progettazione, che sono di fatto in linea con i dettami di RUP. Dette attività XP vengono eseguite utilizzando una serie di pratiche che richiedono l'esecuzione attività supplementari, che sono associate ad altre discipline in RUP. Le pratiche di XP, secondo quanto riportato nel testo Extreme Programming Explained, sono:

  • Planning game: determinare velocemente l'ambito del rilascio successivo, combinando le priorità di business e le stime tecniche. Quando la realtà impatta il piano, aggiornare il piano.
  • Small releases: avviare rapidamente la produzione di un sistema semplice, quindi rilasciare nuove versioni a breve.
  • Metaphor: guidare tutta la fase di sviluppo con una storia semplice da condividere che descrive le funzionalità del sistema.
  • Simple design: la progettazione del sistema deve essere sempre la più semplice possibile. Altre complessità possono essere rimosse non appena identificate.
  • Testing: i programmatori scrivono test di unità in maniera sistematica, che devono essere eseguiti senza errori per proseguire con lo sviluppo. I clienti scrivono test per dimostrare che le funzioni sono state ultimate.
  • Refactoring: i programmatori ristrutturano il sistema senza cambiarne le funzionalità per rimuovere duplicati, migliorare le comunicazioni e aggiungere flessibilità.
  • Pair programming: tutto il codici di produzione è scritto in coppie di programmatori presso un solo computer.
  • Collective ownership: il codice può essere modificato da chiunque, in qualsiasi momento ovunque nel sistema.
  • Continuous integration: integrare e progettare il sistema molte volte al giorno, ogni volta che si completa un compito.
  • 40-hour week: di regola, non lavorare più di 40 settimanali. Non lavorare mai in straordinario due settimane di seguito.
  • On-site customer: inserire nel team un utente reale, disponibile a tempo pieno per chiarimenti.
  • Coding standards: i programmatori scrivono tutto il codice in conformità con le regole con particolare enfasi sulla comunicazione tramite codice.

Le attività eseguite quale risultato della pratica di "planning game", ad esempio, mapperanno essenzialmente la disciplina di gestione del progetto del RUP. Alcuni argomenti RUP, quali distribuzione del software rilasciato, non rientrano nell'ambito di XP. La deduzione dei requisiti è ampiamente fuori la portata di XP, in quanto è il cliente a definire e fornire i requisiti. Inoltre, poiché per la sua capacità di affrontare progetti di sviluppo più semplici, XP può trattare poco le problematiche che invece RUP è in grado di trattare nel dettaglio in termini di disciplina di gestione della configurazione e delle modifiche e di disciplina dell'ambiente.

Pratiche XP compatibili con RUP

Nelle discipline in cui XP e RUP si sovrappongono, le seguenti pratiche descritte in XP potrebbero e, in alcuni casi già sono, impiegate in RUP:

  • The planning game: la guida XP sulla pianificazione può essere utilizzata per raggiungere molti degli obiettivi illustrati nella disciplina Gestione progetti di RUP for anche per progetti molto piccoli. Ciò è particolarmente utile per progetti per cui non è richiesto di produrre artefatti sulla gestione del progetto intermedi.
  • Test-first design and refactoring: queste sono buone tecniche da applicarsi nella disciplina di implementazione di RUP. La consuetutidine di XP di eseguire verifiche, che richiede un approcci test-first design, è particolarmente indicato per chiarire i requisiti a livello dettagliato. La sezione successiva illustrerà come il refactoring potrebbe non essere in grado di scalare nel caso di sistemi più grandi.
  • Continuous integration: RUP supporta questa pratica attraverso buil a livello di sottosistema e sistema (all'interno di un'iterazione). Componenti testati a livello di unità vengono integrati e testati nel contesto del sistema emergente.
  • On-site customer: molte attività RUP potrebbero trarre enorme vantaggio dalla presenza in sede del cliente quale parte integrante del team, riducendo il numero di documenti necessari in modo specifico per il componente distribuibile. Il mezzo di comunicazione tra cliente e sviluppatore preferito da XP è il dialogo diretto, che si affida alla continuità e alla familiarità per raggiungere il successo; tuttavia, quando un sistema, anche piccolo, è in fase di transizione, è necessario molto più del dialogo. XP utilizza questo metodo nel caso di un ripensamento, ad esempio, per i documenti di progettazione alla fine di un progetto. Sebbene non proibisca la produzione di documentazione o altri artefatti, XP consiglia di produrre solo quelli effettivamente necessari. RUP condivide questo approccio, ma descrive cosa è necessario disporre quando continuità e familiarità non sono ideali.
  • Coding standards: RUP propone linee guida per la programmazione di artefatti che da considerarsi quasi sempre obbligatori. (La maggior parte dei profili di rischio del progetto, in quanto fattore determinante per la personalizzazione, rende obbligatoria l'imposizione di standard di codifica.)
  • Forty-hour week: come in XP, anche RUP suggerisce di non esagerare con lo straordinario, anche se XP non impone un limite rigoroso di 40 ore, riconoscendo diversi livelli di tolleranza all'orario di lavoro. Gli ingegneri software sono noti per lavorare ore extra senza essere compensati, per la sola soddisfazione ottenuta dal progetto ultimato e i responsabili non devono interrompere questa abitudine in maniera arbitraria. Il responsabile non deve sfruttare questa pratica o imporla, mantenendo un registro di tutti gli orari lavoro effettio, anche se non è retribuito. Se il registro delle ore lavorate di un particolare individuo sembra sia particolarmente elevato per lungo periodo, è necessario investigare; tuttavia, queste sono problematiche da risolversi al momento in cui se ne presenta la circostanza, tra il responsabile e l'interessato, ascoltando anche eventuali considerazioni del del resto del team. Quaranta ore è un criterio-guida, sebbene deciso.
  • Pair programming: XP sostiene che la programmazione in coppia è vantaggiosa per la qualità del codice e una volta acquisito, questo metodo di lavoro è più piacevole. RUP non descrive la meccanica di produzione del codice in maniera granulare, sebbene sia certamente possibile utilizzare la programmazione in coppia in un processo basato su RUP. Alcune informazioni sulla programmazione in coppia, così come test-first design e refactoring, è offerta adesso su white paper. Ovviamente, l'utilizzo di una qualsiasi di dette pratiche non è un requisito in RUP, tuttavia in un ambiente di team, dove vige la cultura di comunicazione aperta, si può ipotizzare che i vantaggi ottenuto dalla programmazione in coppia, in termini di effetti sul costo totale del ciclo di vita sarebbero difficili da determinare. Collaboratori si riuniscono per discutere e risolvere problemi naturalmente in un team che funziona bene, senza essere obbligati.

L'idea che un buon processo debba essere applicato al microlivello spesso non viene accolta con piacere e potrebbe non adeguarsi alla cultura aziendale. L'applicazione rigorosa, pertanto, non è sostenuta da RUP. Tuttavia, in alcune circostanze, lavorare in coppia e altre pratiche da svolgersi in team sostenute da XP, ha i suoi vantaggi, in quanto ogni membro può aiutare l'altro; ad esempio:

  • nei primi giorni, quando si forma il team e i collaboratori incominciano a conoscersi
  • team con poca esperienza in alcune nuove tecnologie
  • team con personale composto da professionisti e principianti

Pratiche XP poco scalabili

Le seguenti pratiche XP non scalano facilmente su sistemi più grandi, tantomeno XP sostiene diversamente, quindi l'uso delle stesse è soggetto a questa condizione in RUP.

  • Metaphor: per sistemi più grandi e complessi, ridurre l'architettura a una metafora non è sufficiente. RUP offre un framework descrittivo più ricco per l'architettura che non è - come Extreme Programming Explained la descrive - "grandi contenitori e connessioni". Anche nella comunità XP, il valore della metafora è stato sminuito. La metafora non è più una pratica in XP e, fino ad ora, non è stata tuttavia sostuita da un'altra pratica.
  • Collective Ownership: è utile se i membri di un team responsabile di un piccolo sistema o di un sottosistema sia pratico di tutto il relativo codice. Ma la necessità di avere tutti i membri del team cono lo stesso livello di conoscenza dovrebbe dipendere dalla complessità del codice. Potrebbe essere più veloce e sicuro assegnare una correzione a un individuo o una coppia a lavoro sul segmento di codice rilevante. La conoscenza con anche il codice scritto nel modo migliore, in particolare se composto di algoritmi complessi, diminuisce rapidamente nel tempo.
  • Refactoring: in un grande sistema, l'esecuzione frequente del refactoring non sostituisce la mancanza di architettura. Extreme Programming Explained sostiene che la strategia progettuale di XP assomiglia a un algoritmo per scalare una collina. Vale a dire, rendere una progettazione semplice e renderla più complessa, quindi semplificarla di poco e renderla di nuovo più complessa. Il problema con questi algoritmi è raggiungere la condizione ottimale, dove grandi cambiamenti, anziché piccoli, possono fare la differenza. In RUP, l'architettura offre la visuale e l'accesso a una "montagna", per rendere un sistema grande e complesso, gestibile.
  • Small Releases: la velocità a cui il cliente può accettare e distribuire nuovi rilasci dipende su molti fattori, tra cui, in genere, le dimensioni del sistema, correlato con l'impatto sul business. Un ciclo bimensile potrebbe essere troppo breve per alcuni tipi di sistemi; la logistica della distribuzione potrebbe essere proibitiva.

Pratiche da impiegarsi con cautela

Infine, una pratica XP, Simple Design, che a prima vista potrebbe sembrare utilizzabile in RUP, deve essere rielaborata e gestita con cautela quando applicata in generale.

  • Simple Design
    XP si affida molto alle funzionalità: le "storie" dell'utente vengono selezionate, scomposte in compiti e quindi implementate. Secondo Extreme Programming Explained, la versione corretta del software progettato, è quella che esegue tutti i test in qualsiasi momento, non ha duplicati logici, esprime ogni intenzione di rilievo per i programmatori e il numero di classi e metodi è ridotto al minimo. XP non crede nell'aggiungere elementi che non hanno valore commerciale per il cliente.

    Il problema qui, simile a quello delle ottimizzazioni locali, è cercare di gestire quelli che RUP definisce come requisiti "non funzionali". Anche questi requisiti hanno valore commerciale per il cliente, ma sono più difficili da esprimere in "storie. Alcuni di ciò che XP definisce vincoli cadono in questa categoria. Anche RUP non supporta la progettazione di più di quanto necessario in modo eccessivo, tuttavia supporta la progettazione basata su un modello strutturale, elemento chiave per soddisfare anche i requisiti non funzionali.

    Pertanto, RUP concorda con XP che il "simple design" debba includere l'esecuzione di tutti i test, ma con la postilla che vengano inclusi test che dimostrano che software soddisferà anche i requisiti non funzionali. Si sottolinea che ciò si profila come un problema importante all'aumentare della dimensione e della complessità del sistema oppure quando l'architettura non ha precedenti o è sovraccarica di requisiti non funzionali. Ad esempio, quando è necessario eseguire la collazione dei dati, per lavorare in un ambiente distribuito ed eterogeneo, sembra che il codice diventi troppo complesso, tuttavia, sarà necessario per la produzione del programma.

Mappatura degli artefatti in un progetto piccolo

Quando si personalizza un RUP per un progetto piccolo e si riduce ilProdotto di lavoro in base ai requisiti, come si rapporta all'equivalente degli artefatti in un progetto XP? La Tabella 1 illustra un insieme tipico di artefatti RUP in un piccolo progetto RUP.

Artefatti XP
Artefatti RUP
(Esempio per progetti piccoli)
Storie
Documentazione supplementare dalla conversazione
Visione
Glossario
Modello del caso d'uso
Vincoli Specifichesupplementari
Testi di accettazione e verifica unità
Data test e risultati

 Pianodi test Scenario di testSuite di test (compreso  Script di test,  Dati test)
Logtest
Riepilogo valutazione test

Software (codice) Modello di implementazione
Rilasci  Prodotto (unità di distribuzione)
 Note di rilascio
Metafora Documento dell'architettura software
Progettazione (CRC, sketch UML)
Operazioni tecniche ed altri compiti
Documenti della progettazione a destinazione
Documentazione di supporto
Modello di progettazione
Standard di codifica  Linee guida specifiche per il programma
Area di lavoro
Framework dei test e tool
 Caso di sviluppo
 Configurazione dell'ambiente di test
Piano di rilascio
Piano di iterazione
Stime sulla storia e sui compiti
Piano di sviluppo software
Piano di iterazione
Piano e budget complessivi Scenario business
Elenco dei rischi
Relazione di avanzamento
Registrazione orario lavoro per compito
Dati della metrica (compresi risorse, ambito, qualità, tempo)
Risultati del controllo
Relazioni e note delle riunioni
Valutazione dello stato
Valutazione dell'iterazione
Relazione revisionale
Difetti (e dati associati) Richieste di modifica
Tool per la gestione del codice Archivio progetto
 Area di lavoro
Picco (soluzione)

Prototipi
Prototipo dell'interfaccia utente
Prova strutturale del concetto

XP in se (consigli e indicazioni)

Elenco idee prova
 Linee guida specifiche per programma

[Non incluse in XP]

Modello di dati
 Documentazione di supporto dell'utente.

Tabella 1: Mappatura da XP a RUP degli artefatti per un progetto piccolo

Sebbene la granularità degli artefatti varia in entrambi i framework, in genere gli artefatti per piccoli progetti in RUP, il tipo XP è in grado di affrontare facilmente, si mappano piuttosto bene a quelli di un progetto in XP.

Si sottolinea che la tabella include anche alcuni artefatti cui XP non si dedica. Tra cui Modello di dati e artefatti correlati alla distribuzione, quali Documentazione di supporto dell'utente.

Attività

RUP definisce un'Operazione come un lavoro eseguito da unRuolo, utilizzando e trasformando artefatti di input o producendo artefatti nuovi o modificati di output. RUP enumera dette attività e le suddivide in categorie in base allediscipline di RUP. Le discipline sono, tra le altre: requisiti, analisi e progettazione, distribuzione e gestione progetto.

Le attività sono correlate al tempo attraverso gli artefatti che producono e consumano: un'attività può avere inizio logico quando i suoi input sono disponibili e hanno raggiunto lo stato di maturazione appropriato. Vale a dire che le coppie di attività produttore-consumatore possono sovrapporsi nel tempo, se lo stato dell'artefatto lo consente; non devono essere sequenziate in maniera rigida. Le attività sono destinate a fornire linee guida rigorose su come produrre un artefatto e possono essere anche utilizzate per assistere il responsabile progetto con la pianificazione.

Intrecciate nel RUP come è stato descritto in termini di ciclo di vita, artefatti e attività, sono le "pratiche migliori": i principi progettuali del software che hanno provato di generare software di qualità costruito in base a pianificazione e budget prevedibili. RUP, attraverso le proprie attività e gli artefatti ad esse associati, supporta e realizza dette pratiche, sono temi che attraversano il RUP, che sostengono iprincipi chiavi che corroborano il RUP stesso. Si sottolinea che anche XP utilizza la nozione di "pratiche", ma come verrà illustrato di seguito, il concetto non è in linea perfetta con la definizione di pratiche migliori di RUP.

XP propone una visione semplice e coinvolgente dello sviluppo del software composto da quattro attvitià di base - codifica, verifica, ascolto e progettazione - da abilitare e strutturare in conformità con alcune delle pratiche di supporto (come esaminato in Extreme Programming Explained, Capitolo 9). In realtà, come segnalato in precedenza, le attività di XP sono più simili in termini di ambito alle discipline e non alle attività di RUP e la maggior parte di ciò che accade in un progetto XP, oltre alle quattro attività base, deriva dall'elaborazione e dall'applicazione delle sue pratiche.

Pertanto, un equivalente XP della attività di RUP esiste, ma le "attività" di XP non sono identificate o descritte formalmente come tali. Ad esempio, esaminando il Capitolo 4, "User Stories" (storie dell'utente) Extreme Programming Installed, l'intestazione richiede di definire i requisiti con storie scritte su cartoncini e prosegue con un misto di descrizioni del processo e di linee guida che definiscono cosa sono le storie dell'utente e come e da chi devono essere prodotte. Così per tutto il capitolo; in varie sezioni dei libri di XP, nelle intestazioni che sono misto di artefatti e attività, le "things produced" (elementi prodotti) e "things done" (elementi ultimati) sono descritte con vari gradi di regolamentazione e dettaglio.

L'apparente alto grado di regolamentazione di RUP è il risultato della propria completezza e il maggiore formalismo nel trattare le attività e relativi input e output. XP non manca di regolamentazione, forse nel tentativo di restare leggero, formalismo e dettaglio sono semplicemente omessi. La mancanza di specificità non è ne un punto di forza ne di debolezza, ma la mancanza di informazioni dettagliate in XP non deve essere confusa con semplicità. Non disporre di dettagli può essere accettabile per sviluppatori esperti, ma in molti casi, è vero il contrario per membri del team nuovi o che stanno familiarizzando con l'approccio adottato dal team nello sviluppo del software.

Con Attività, così come con Artefatti, è importante concentrare l'attenzione sull'obiettivo fissato. L'esecuzione di un'attività alla ceca non è mai buona prassi. Le attività e le linee guida ad esse associate sono da consultare per raggiungere gli obiettivi, ma non devono essere utilizzate come scusante per non determinare cosa si sta tentando raggiungere. Questo spirito è ben articolato in XP e si ritiene debba essere applicato ad ogni utente di RUP.

Ruoli

In RUP, leattività sono eseguite daruoli o più precisamente da individui o gruppi che assumono ruoli. Ai ruoli sono attribuite anche responsabilità per l'artefatti; il ruolo responsabile in genere crea l'artefatto e garantisce che eventuali modifiche eseguite da altri ruoli, ove consentite, non lo interrompano. Un individuo o un gruppo può assumere un solo ruolo o una serie di ruoli. Non è necessario mappare un ruolo a un'unica posizione o "slot" in un'organizzazione.

Extreme Programming Explained identifica sette ruoli applicabili ad XP - Programmatore, Cliente, Tester, Tracker, Coach, Consulente e Big Boss - ne descrive le responsabilità e le capacità che gli individui devono possedere per assumerli. Riferimenti sono anche fatti a questi ruoli in alcuni degli altri libri di XP. La differenza nel numero di ruoli in XP e RUP è facile da spiegare:

  • XP non si occupa di tutte le discipline esaminate da RUP.
  • I ruoli XP sono paragonabili più alle posizioni all'interno di un'organizzazione (possibilmente con più responsabilità) che ai ruoli RUP. Ad esempio, il Programmatore XP esegue più ruoli RUP - Implementatore, Esaminatore codice e Integratore - che richiedono capacità leggermente diverse.

Ruoli XP e RUP in un progetto piccolo

Quando i ruoli di RUP sono mappati a un progetto piccolo, il numero di ruoli XP simili cui corrispondono si riduce considerevolmente, ovvero il numero di posizioni o titoli è 5. La Tabella 3, estratta da un RUP, mostra questa mappatura con il corrispondente Ruolo XP.

Ruolo XP Esempio di membro del team in un piccolo progetto RUP Ruolo RUP
Coach
Consulente
Big Boss
Sally Slalom, Senior Manager Responsabileprogetto
 Responsabiledistribuzione
Esaminatore tecnico
Responsabileconfigurazione
Responsabile controllo modifiche
Cliente Stakeholder (come documentato in Visione)
Esaminatoregestione
Esaminatoretecnico (requisiti)
Cliente
Big Boss
Tracker
Tom Telemark, Senior Software Engineer Analista di sistema
Specificatore di requisiti
Progettista interfaccia utente
Architetto software
Esaminatore tecnico
Responsabile test
Analista test

Ruoli dello sviluppatore (con minor enfasi)

Programmatore
Tester

Susan Snow, Software Engineer

Henry Halfpipe, Junior Software Engineer

Progettista
Implementatore
Esaminatore tecnico
Integratore
Progettista test
Tester
 Redattore tecnico
Tracker Patrick Powder, Assistente amministrativo Responsabile della gestione del sito Web del Progetto, assistendo il ruolo di Responsabile progetto nel pianificare attività e assistendo il Responsabile controllo modifiche nel controllo delle modifiche apportate agli artefatti.  Secondo necessità, può offrire assistenza ad altri ruoli.

Tabella 3: Mappatura dei ruoli XP ai ruoli RUP in progetti piccoli

Utilizzo delle pratiche XP con RUP

RUP è un framework di processi da cui determinati processi possono essere configurati e quindi installati. RUP deve essere configurato, un passaggio obbiligatorio definito in RUP stesso. Nello specifico, si dovrebbe paragonare una versione personalizzata di RUP con una diXP, vale a dire con RUP personalizzato in base alle caratteristiche del progetto stabilite chiaramente e quelle sottese da XP. Un processo RUP personalizzato di questo genere potrebbe non accogliere molte delle pratiche di XP, come pair programming, test-first design e refactoring, tuttavia non sarebbe identico ad XP per l'enfasi data da RUP all'architettura, all'astrazione (in modellazione) e al rischio e relative strutture che si differenziano nel tempo (fasi ed iterazioni).

XP è diretto intenzionalmente all'implementazione di processi leggeri per progetti piccoli. Facendo così, include anche descrizioni, almeno nei testi, che non sono elaborati a pieno. In un'implementazione XP saranno sempre presenti elementi che devono essere individuati, inventati o definiti immediamente. RUP è in grado di accogliere progetti che si adattano e vanno oltre l'ambito di XP, per scala e tipologia. Come dimostrato da questo piano di sviluppo, RUP è abbastanza compatibile con la maggior parte delle pratiche descritte nella documentazione su XP.

Ricordare che l'essenza di XP è il concentrare l'attenzione sull'organizzazione, gli individui e la cultura. Ciò è importante in tutti i progetti ed è certamente applicabile ai progetti che si servono di RUP. Progetti piccoli possono trarre grande vantaggio dall'utilizzo contemporaneo di dette pratiche.

Riferimenti per il processo agile

  • eXtreme Programming (XP) (Per ulteriori informazioni, vedere http://www.extremeprogramming.org/more.html.):
    • Extreme Programming Explained: Embrace Change. Kent Beck esamina i concetti e la filosofia dietro extreme programming. Questo libro insegna cosa e perché, ma non come.
    • Refactoring Improving the Design of Existing Code. Martin Fowler redige il primo autorevole volume sul refactoring. Presentato come pattern. Propone numerosi esempi in Java. Questo libro insegna come eseguire il refactoring e perché.
    • Extreme Programming Installed. By Ron Jeffries, Chet Hendrickson, and Ann Anderson. Questo libro si occupa di specifiche pratiche XP in dettagli più granulari rispetto a Extreme Programming Explained. Questo libro insegna come programmare nello stile XP.
    • Planning Extreme Programming. By Kent Beck, and Martin Fowler. Questo libro illustra i pensieri più recenti su come pianificare il software in ambienti a consegna rapida. Questo libro insegna come eseguire un progetto XP.
    • Extreme Programming Examined. By Giancarlo Succi and Michele Marchesi. Documenti presentanti all'XP2000. Una raccolta esaustiva di documenti su molti argomenti.
    • Extreme Programming in Practice. By Robert C. Martin, James W. Newkirk. Un progetto reale che ha utilizzato XP descritto nel dettaglio.
    • Extreme Programming Explored. By William C. Wake. Basato sul noto sito Web XPlorations. Argomenti specifici sono esplorati nel dettaglio.
    • Extreme Programming Applied: Playing to Win. By Ken Auer and Roy Miller. Esperienze dai pionieri dell'applicazione dell'XP. Pubblicazione prevista per settembre.

Per ulteriori informazioni sugli altri membri della Agile Alliance vedere http://www.agilealliance.org.