Extreme Programming (XP) è una metodologia di sviluppo software agile. Come altre metodologie agili, XP ha i suoi strumenti, processi e ruoli unici. Il creatore di XP, il developer americano Kent Beck, non ha inventato nulla di completamente nuovo, ma ha invece preso le migliori pratiche dello sviluppo agile e le ha amplificate all’estremo, da cui il nome Extreme Programming.
L’autore della metodologia, Kent Beck, ha guidato il progetto Chrysler Comprehensive Compensation System alla fine degli anni ’90, dove ha applicato per la prima volta le pratiche di XP. Ha documentato la sua esperienza e il concetto creato nel libro “Extreme Programming Explained,” pubblicato nel 1999. Questo libro è stato seguito da altri che dettagliavano le pratiche di XP. I contributori allo sviluppo della metodologia includono Ward Cunningham, Martin Fowler e altri.
Contrariamente ad altre metodologie agili, XP è utilizzato esclusivamente nello sviluppo software. Non può essere applicato ad altre attività commerciali o alla vita quotidiana come Scrum, Kanban o Lean.
Lo scopo di XP è affrontare i requisiti in continua evoluzione per il prodotto software e migliorare la qualità dello sviluppo. Pertanto, XP è adatto per progetti complessi e incerti.
XP ruota attorno a quattro attività fondamentali: codifica, test, progettazione e ascolto. Inoltre, l’Extreme Programming ha valori fondamentali: semplicità, comunicazione, feedback, coraggio e rispetto.
13 Pratiche di Extreme Programming
1. L’Intero Team
Tutti i partecipanti al progetto che usano XP lavorano come un’unica squadra. Questa squadra deve includere un rappresentante del cliente, preferibilmente un reale utilizzatore finale esperto del settore. Il cliente definisce i requisiti del prodotto e prioritizza le funzionalità. Gli analisti commerciali possono assistere il cliente. Dal lato degli esecutori, il team comprende sviluppatori, tester, a volte un coach che guida il team e un manager che fornisce le risorse.
2. Gioco di Pianificazione
La pianificazione in XP avviene in due fasi: pianificazione del rilascio e pianificazione delle iterazioni.
- Pianificazione del Rilascio: Il team di programmazione incontra il cliente per determinare le funzionalità desiderate per il prossimo rilascio, tipicamente tra 2 – 6 mesi. Poiché i requisiti del cliente sono spesso vaghi, gli sviluppatori li chiariscono e li suddividono in compiti che possono essere completati in un giorno o meno. Il cliente deve comprendere l’ambiente operativo in cui il prodotto funzionerà.
Le attività sono registrate su schede e il cliente le prioritizza. Gli sviluppatori stimano quindi il tempo richiesto per ciascun compito. Una volta che i compiti sono descritti e stimati, il cliente rivede la documentazione e approva l’inizio dei lavori. Per il successo del progetto, è fondamentale che il cliente e il team di programmazione giochino sullo stesso campo: il cliente sceglie funzionalità realmente necessarie all’interno del budget, e i programmatori allineano adeguatamente i requisiti del cliente con le loro capacità. - Pianificazione delle Iterazioni: Condotta ogni due settimane, a volte con una frequenza maggiore o minore. Il cliente è presente per definire le funzionalità per la prossima iterazione e apportare modifiche ai requisiti del prodotto.
3. Piccole Rilascio
I rilasci di XP sono frequenti ma con funzionalità limitate. Questo approccio facilita il test e il mantenimento dell’operabilità del sistema e fornisce al cliente funzionalità che hanno valore commerciale ad ogni iterazione.
4. Test del Cliente
Il cliente specifica test di accettazione automatizzati per verificare le funzionalità del prodotto. Il team scrive questi test e li utilizza per testare il codice.
5. Proprietà Collettiva del Codice
In XP, qualsiasi sviluppatore può modificare qualsiasi parte del codice, poiché il codice non appartiene al suo autore, ma all’intero team.
6. Integrazione Continua
Nuove parti di codice vengono integrate nel sistema immediatamente — i team XP rilasciano una nuova versione ogni poche ore o anche più frequentemente. Questa pratica garantisce che l’impatto delle recenti modifiche sul sistema sia visibile immediatamente. Se un nuovo pezzo di codice rompe qualcosa, identificare e correggere l’errore è molto più facile.
7. Standard di Codifica
Con la proprietà collettiva del codice, adottare standard di codifica comuni è fondamentale per far apparire il codice come se fosse stato scritto da un singolo professionista. I team possono sviluppare i propri standard o adottarne di esistenti.
8. Metafora del Sistema
La metafora del sistema è un confronto con qualcosa di familiare per creare una visione condivisa all’interno del team. Tipicamente, la persona che sviluppa l’architettura e vede il sistema nel suo insieme concepisce la metafora.
9. Ritmo Sostenibile
I team XP lavorano alla massima produttività mantenendo un ritmo sostenibile. L’Extreme Programming scoraggia il lavoro straordinario e promuove una settimana lavorativa di 40 ore.
10. Sviluppo Guidato dai Test (TDD)
Una delle pratiche più impegnative in XP. I programmatori scrivono test prima di scrivere il codice da testare. Questo approccio garantisce che ogni pezzo di funzionalità sia completamente coperto dai test. Quando gli sviluppatori inviano il codice, i test unitari vengono eseguiti immediatamente e tutti i test devono superare, garantendo che il team stia procedendo nella giusta direzione.
11. Programmazione a Coppie
Immagina due sviluppatori che lavorano su un computer su un singolo pezzo di funzionalità. Questa pratica è la programmazione a coppie, la pratica più controversa in XP. Il detto “due teste sono meglio di una” illustra bene la sua essenza. Dalle due soluzioni a un problema, viene scelta la migliore, il codice è ottimizzato immediatamente e gli errori vengono catturati prima che si verifichino, portando a un codice pulito compreso da entrambi gli sviluppatori.
12. Design Semplice
Il design semplice in XP significa fare solo ciò che è necessario ora, senza cercare di prevedere future funzionalità. Il design semplice e il refactoring continuo creano un effetto sinergico: quando il codice è semplice, è più facile ottimizzare.
13. Refactoring
Il refactoring è il processo continuo di miglioramento del design del sistema per soddisfare nuovi requisiti. Include la rimozione di duplicati nel codice, l’aumento della coesione e la riduzione del coupling. XP impone il refactoring costante, quindi il design del codice rimane sempre semplice.
Vantaggi e Svantaggi di XP
XP è controversa e spesso criticata da coloro che non sono riusciti a implementarla. Tuttavia, i suoi benefici sono evidenti quando il team utilizza completamente almeno una pratica di XP.
I benefici di aspirare a XP includono:
- Soddisfazione del Cliente: I clienti ottengono il prodotto di cui hanno bisogno, anche se inizialmente non hanno una visione chiara.
- Flessibilità: Il team apporta rapidamente modifiche al codice e aggiunge nuove funzionalità grazie al design del codice semplice, alla pianificazione frequente e ai rilasci.
- Affidabilità: Il codice funziona sempre grazie ai test costanti e all’integrazione continua.
- Manutenibilità: Il team può mantenere facilmente il codice perché è scritto secondo uno standard unico e costantemente refactorato.
- Produttività: Pace di sviluppo rapida grazie alla programmazione a coppie, assenza di straordinari e coinvolgimento del cliente.
- Codice di Alta Qualità
- Mitigazione del Rischio: I rischi dello sviluppo sono ridotti poiché la responsabilità è distribuita uniformemente e il progetto non è compromesso dall’uscita o dall’arrivo di membri del team.
- Efficienza dei Costi: I costi di sviluppo sono inferiori poiché il team si concentra sul codice piuttosto che sulla documentazione e sui meeting.
Nonostante i suoi vantaggi, XP non sempre funziona e presenta diverse debolezze:
- Coinvolgimento del Cliente: Il successo dipende dal coinvolgimento del cliente, che può essere difficile da raggiungere.
- Tempistiche Imprevedibili: È difficile prevedere i costi temporali del progetto poiché l’elenco completo dei requisiti è sconosciuto all’inizio.
- Dipendenza dal Livello di Abilità: XP dipende fortemente dal livello di abilità dei programmatori e funziona meglio con professionisti esperti.
- Resistenza della Direzione: La direzione spesso si oppone alla programmazione a coppie, mettendo in discussione la necessità di pagare due programmatori invece di uno.
- Costo: Meeting frequenti con i programmatori possono essere costosi per i clienti.
- Cambiamenti Culturali: Implementare XP richiede significativi cambiamenti culturali.
- Mancanza di Struttura: La mancanza di struttura e documentazione di XP la rende inadeguata per progetti di grandi dimensioni.
- Requisiti Non Funzionali: I requisiti funzionali sono difficili da descrivere come storie utente nelle metodologie agili.
Principi di XP
Nel suo primo libro, Kent Beck ha delineato i seguenti principi di XP: semplicità, comunicazione, feedback e coraggio. In una successiva edizione, ha aggiunto un quinto principio — rispetto.1. Semplicità
Lo sviluppo XP inizia con la soluzione più semplice che soddisfa l’attuale bisogno funzionale. I membri del team considerano solo ciò che deve essere fatto ora e non incorporano funzionalità che potrebbero essere necessarie in futuro.
2. Comunicazione
La comunicazione in XP avviene dal vivo piuttosto che attraverso la documentazione. Il team comunica attivamente tra di loro e con il cliente.
3. Feedback
Il feedback in XP è implementato in tre modi:
- Feedback di Sistema: Attraverso il costante testing dei moduli.
- Feedback del Cliente: Il cliente è parte del team e partecipa alla scrittura dei test di accettazione.
- Feedback del Team: Durante la pianificazione, riguardo le stime di tempo di sviluppo.
4. Coraggio
Alcune pratiche di XP sono così non convenzionali che richiedono coraggio e costante autocontrollo.5. Rispetto
Il rispetto in XP significa rispettare il team e avere rispetto di se stessi. I membri del team non dovrebbero apportare modifiche che interrompono la compilazione, i test dei moduli, o rallentano il lavoro dei colleghi. Ogni membro si sforza di raggiungere la massima qualità del codice e del design.
Implementazione di XP e Flusso di Lavoro
Kent Beck raccomanda di implementare XP per risolvere i problemi del progetto. Il team seleziona il problema più urgente e lo risolve utilizzando una delle pratiche di XP. Poi affrontano il problema successivo, utilizzando un’altra pratica. Questo approccio assicura che i problemi motivino l’adozione di XP e il team padroneggi gradualmente tutti gli strumenti della metodologia.
Per implementare XP in un progetto esistente, adotta gradualmente le sue pratiche nelle seguenti aree:
- Testing: Il team crea test prima di scrivere nuovo codice e refactorizza gradualmente il vecchio codice.
- Design: Il team refactorizza continuamente il vecchio codice, tipicamente prima di aggiungere nuove funzionalità.
- Pianificazione: Il team deve interagire strettamente con il cliente.
- Gestione: I manager assicurano che tutti i membri del team seguano le nuove regole.
- Sviluppo: Inizia organizzando le postazioni di lavoro per la programmazione a coppie e incoraggia le coppie a programmare la maggior parte del tempo.
Esempio di Flusso di Lavoro Utilizzando XP
Chi Usa XP
Secondo un sondaggio di VersionOne del 2016, solo l’1% delle aziende agili utilizza XP nella sua forma pura. Un altro 10% utilizza un ibrido di Scrum e XP.Sebbene XP non sia la metodologia più comune, le sue pratiche sono usate dalla maggior parte delle aziende che impiegano metodologie agili. Ad esempio, Pivotal Software, Inc. attribuisce il suo successo a XP.
Pivotal Software, Inc.
Pivotal Software, Inc. sviluppa analisi aziendali basate su big data e fornisce servizi di consulenza. I loro prodotti sono utilizzati da corporation come Ford, Mercedes, BMW, GAP, Humana, grandi banche, agenzie governative e compagnie d’assicurazione.
Pivotal sostiene che le metodologie agili sono essenziali per lo sviluppo moderno. Tra le varianti agili, hanno scelto XP, un approccio vincente per i clienti e i team di programmazione. La loro giornata lavorativa inizia con riunioni stand-up e termina alle 18:00— niente straordinari. Pivotal utilizza giochi di pianificazione, programmazione a coppie, test costanti, integrazione continua e altre pratiche di XP.
Cosa Leggere per Comprendere XP
- “Extreme Programming Explained,”, “Planning Extreme Programming,”, “Test-Driven Development” di Kent Beck: Questi libri del creatore di XP forniscono una comprensione approfondita della metodologia e dei suoi vantaggi.
- “Refactoring: Improving the Design of Existing Code” di Martin Fowler: Un libro di un co-autore di XP che spiega i principi e le tecniche del refactoring.
- “Extreme Programming Applied: Playing to Win” di Ken Auer e Roy Miller: Una guida pratica alle pratiche di XP con esempi.
Strumenti per Implementare XP nei Team
Redmine
Un gestore di compiti gratuito e open-source con funzionalità come supporto per più progetti, gestione flessibile delle attività, grafici di Gantt, tracciamento del tempo, gestione della documentazione e creazione di attività tramite email.
Basecamp
Un servizio semplice e user-friendly per il lavoro di progetto collaborativo, incluso un gestore di compiti, bacheche di messaggi, chat integrata, archiviazione file e calendario.
Jira
Un servizio robusto progettato per gli sviluppatori di progetti agili, che combina un tracciatore di bug e uno strumento di gestione dei progetti con molte funzionalità e opzioni di sincronizzazione.
Worksection
Un servizio sicuro per il lavoro di progetto, che consente la definizione di attività e il controllo dei processi, il tracciamento della corrispondenza, la personalizzazione dei filtri, il tracciamento del tempo e delle finanze e la gestione dei file.
Conclusione
L’Extreme Programming è una metodologia agile focalizzata sulla produzione di codice funzionale di alta qualità con un’architettura semplice. Il suo scopo è ridurre l’incertezza nei progetti e rispondere in modo flessibile ai requisiti del prodotto che cambiano.
XP è esclusivamente per lo sviluppo software e non può essere adattata ad altre attività commerciali.
È una delle metodologie più difficili da implementare a causa delle sue tredici pratiche. Tuttavia, le sue pratiche sono ampiamente utilizzate in progetti agili, dimostrando la loro efficacia.
Gli autori consigliano di padroneggiare gradualmente le pratiche di XP mentre si risolvono i problemi del progetto. Se si vedono i benefici, continuare nello stesso spirito. Non c’è obbligo di implementare XP in modo totale o nulla. Dopotutto, le metodologie agili dovrebbero essere flessibili nell’applicazione — adattandosi alle esigenze specifiche del team di progetto.