L’eXtreme Programming (XP) porta risultati, ma è adatto a te?

Se il termine eXtreme Programming (programmazione estrema) ti fa pensare agli X Games e agli sport d’azione, non sei troppo lontano dalla realtà. L’eXtreme Programming (XP) è, infatti, un modo piuttosto estremo di programmare. Come altri metodi di sviluppo software Agile, XP utilizza uno sviluppo adattabile e basato su test per l’ingegneria del software. Ma a differenza di altri metodi, l'Extreme Programming ha regole rigorose e valori guida che governano il modo in cui il lavoro viene svolto. 

Cos'è l'eXtreme Programming (XP)?

L’eXtreme Programming è una metodologia Agile per la gestione dei progetti che punta sulla velocità e sulla semplicità con cicli di sviluppo brevi e meno documentazione. La struttura del processo è determinata da cinque valori guida, cinque regole e 12 pratiche XP (che analizzeremo più avanti in questo articolo). 

Come altre metodologie Agile, XP è una metodologia di sviluppo software suddivisa in sprint di lavoro. I framework Agile seguono un processo iterativo: si completa e si rivede il framework dopo ogni sprint, lo si perfeziona per la massima efficienza e lo si adatta ai requisiti in evoluzione. Come per altre metodologie Agile, la progettazione di XP consente agli sviluppatori di rispondere alle storie dei clienti, adattarsi e cambiare in tempo reale. Ma XP è molto più disciplinato, poiché utilizza frequenti revisioni del codice e test unitari per apportare modifiche rapidamente. È anche altamente creativa e collaborativa, dando la priorità al lavoro di squadra durante tutte le fasi di sviluppo.

Programmazione estrema e Scrum

Scrum è un altro tipo comune di metodologia Agile gestita da uno Scrum master. Simile a XP, Scrum esegue sprint basati sulle storie degli utenti per sviluppare nuove funzionalità di prodotti o software. Tuttavia, XP è più rigida di Scrum, con regole e linee guida rigorose che incoraggiano il contatto costante tra gli sviluppatori e il cliente. Inoltre, puoi utilizzare Scrum per qualsiasi processo che richieda iterazione e input del cliente, mentre la programmazione XP è più limitata.

Chi ha creato la programmazione estrema?

Le origini di XP risalgono alla fine degli anni '90, quando Kent Beck la creò per gestire lo sviluppo di un sistema software per le buste paga per Chrysler chiamato progetto C3. L’obiettivo di XP era (ed è tuttora) quello di rimuovere la resistenza alla modifica del codice all’interno dei progetti di sviluppo. Nei metodi di sviluppo software più tradizionali, spesso il codice viene lasciato così com'è una volta scritto (tranne che per il debug). Con XP, il codice viene esaminato così attentamente che gli sviluppatori possono decidere di riscriverlo interamente dopo una singola iterazione. 

Quando si dovrebbe usare l’Extreme Programming?

Poiché l’XP si concentra sullo sviluppo di software, in genere viene utilizzata solo dai team di progettazione. Anche nei team di sviluppo software, funziona solo in determinate situazioni. Per ottenere il massimo valore dall’XP, è meglio usarla quando: 

• Gestisci un team di piccole dimensioni. A causa della sua natura altamente collaborativa, XP funziona meglio su team più piccoli di meno di 10 persone. 

• Sei in costante contatto con i tuoi clienti. XP incorpora i requisiti dei clienti durante tutto il processo di sviluppo e si affida a loro anche per i test e le approvazioni.

• Hai un team adattabile che può abbracciare il cambiamento (senza rancore). Per sua stessa natura, l’Extreme Programming richiederà spesso a tutto il team di buttare via il proprio duro lavoro. Ci sono anche regole che consentono ad altri membri del team di apportare modifiche in qualsiasi momento, il che non funziona se i membri del team potrebbero prenderla sul personale.

• Conoscano bene gli aspetti tecnici della programmazione. XP non è per principianti. È necessario essere in grado di lavorare e apportare modifiche rapidamente.

Ciclo di vita di XP

Il ciclo di vita di XP incoraggia l'integrazione continua, in cui il membro del team integra quasi costantemente, con cadenza oraria o giornaliera. Ma il ciclo di vita completo si articola come segue:

• Estrai il lavoro non finito dalle storie utente 

• Dai la priorità agli elementi più importanti 

• Iniziare la pianificazione iterativa  

• Incorporare una pianificazione onesta  

• Mantenere una comunicazione costante con tutti gli stakeholder e responsabilizzare il team  

• Rilasciare il lavoro  

• Ricevere feedback 

• Ritorno alla fase di pianificazione iterativa e ripetizione, se necessario

I 5 valori dell’Extreme Programming

L’XP è guidata dai valori. Invece di utilizzare motivatori esterni, XP consente al team di lavorare in modo meno complicato (concentrandosi sulla semplicità e sulla collaborazione rispetto a progetti complessi), tutto basato su questi cinque valori.

1. Semplicità

Prima di iniziare qualsiasi lavoro di programmazione estrema, chiediti innanzitutto: qual è la cosa più semplice che funziona? La parte “che funziona” è un elemento di differenziazione chiave: la cosa più semplice non è sempre pratica o efficace. In XP, l’obiettivo è portare a termine prima il lavoro più importante. Ciò significa che devi cercare un progetto semplice che sai di poter realizzare.

2. Comunicazione

XP si basa su una reattività rapida e una comunicazione efficace. Per lavorare, i membri del team devono essere aperti e onesti tra loro. Quando sorgono problemi, ci si aspetta che tu parli. perché spesso gli altri membri del team hanno già una soluzione. E se non l’hanno, ne troverete una più velocemente come gruppo di quanto fareste da soli.

3. Feedback

Come altre metodologie Agile, XP incorpora le user story e il feedback direttamente nel processo. L’obiettivo di XP è produrre lavoro in modo rapido e semplice, quindi condividerlo per ottenere un feedback quasi immediato. In quanto tale, gli sviluppatori sono in contatto quasi costante con i clienti durante tutto il processo. In XP, si lanciano frequentemente nuove versioni per ottenere approfondimenti in anticipo e spesso. Quando ricevi un feedback, adatti il processo per incorporarlo (anziché il progetto). Ad esempio, se il feedback evidenzia un tempo di latenza non necessario, si modificherà il processo per far sì che un paio di sviluppatori migliorino il tempo di latenza invece di modificare il progetto nel suo complesso.

4. Coraggio

La metodologia XP richiede una certa dose di coraggio. Ci si aspetta sempre che tu fornisca aggiornamenti onesti sui tuoi progressi, il che può renderti piuttosto vulnerabile. Se manchi una scadenza in XP, il tuo team leader probabilmente non vorrà discuterne il motivo. Invece, gli dirai che hai mancato la Scadenza, ti assumerai le tue responsabilità e tornerai al lavoro. 

Se sei un team leader, la tua responsabilità all'inizio del processo XP è quella di impostare le aspettative di successo e definire il "completamento". Spesso non si pianifica il fallimento perché il team si concentra sul successo. Tuttavia, questo può essere spaventoso, perché le cose non vanno sempre come previsto. Ma se le cose cambiano durante il processo XP, il tuo team dovrà adattarsi e cambiare di conseguenza. 

5. Rispetto

Considerando quanto la metodologia XP dia la priorità alla comunicazione e all'onestà, è logico che il rispetto sia importante. Affinché i team comunichino e collaborino in modo efficace, devono essere in grado di esprimere il proprio disaccordo. Ma ci sono modi per farlo con gentilezza. Il rispetto è una buona base che porta alla gentilezza e alla fiducia, anche in presenza di molta onestà. Per la programmazione estrema, le aspettative sono: 

• rispetto reciproco tra i clienti e il team di sviluppo; 

• Rispetto reciproco tra i membri del team. 

• Riconoscimento del fatto che tutti i membri del team apportano qualcosa di prezioso al progetto.

Le cinque regole della metodologia eXtreme Programming

I valori dell’eXtreme Programming sono gli aspetti più filosofici. Le regole, invece, sono gli usi pratici per il modo in cui il lavoro viene svolto. Avrai bisogno di entrambi per gestire un team XP efficace. 

1. Pianificazione

Nelle fasi di pianificazione di XP, si determina se il progetto è fattibile e adatto a questa metodologia. Per farlo, esaminerai:

• Le user story, per vedere se corrispondono al valore della semplicità e verificare che il cliente sia disponibile per il processo. Se la user story è più complessa o è stata creata da un cliente anonimo, probabilmente non sarà adatta a XP.

• Il valore aziendale e la priorità del progetto, per assicurarti che questo sia in linea con il principio di “portare a termine prima il lavoro più importante”. 

• In quale fase di sviluppo ti trovi. XP è la metodologia migliore per lo sviluppo in fase iniziale e non funzionerà altrettanto bene per le iterazioni successive.

Una volta confermato che il progetto è adatto per la metodologia XP, ‌crea un programma di rilascio, ma ricorda che dovresti rilasciare presto e spesso per ottenere feedback. Per farlo:

• Suddividi il progetto in iterazioni e crea un piano per ciascuna di esse. 

• Stabilisci scadenze realistiche e un ritmo sostenibile. 

• Condividi gli aggiornamenti in tempo reale, per consentire al tuo team di essere onesto e trasparente. 

• Condividi aggiornamenti in tempo reale che aiutano il team a identificare, adattarsi e apportare modifiche più rapidamente. 

• Utilizza uno strumento di project management per creare una Bacheca Kanban o una cronologia per monitorare i tuoi progressi in tempo reale. 

2. Gestione

Uno degli elementi chiave dell’XP è lo spazio fisico. I puristi della metodologia XP consigliano di utilizzare uno spazio di lavoro aperto in cui tutti i membri del team lavorano in un'unica stanza aperta. Poiché la metodologia XP è così collaborativa, trarrai vantaggio dall’avere uno spazio in cui poterti riunire fisicamente. Ma questo non è sempre pratico al giorno d'oggi. Se lavori in un team da remoto, prendi in considerazione l'utilizzo di una piattaforma che incoraggi il lavoro asincrono per la collaborazione a distanza. In questo modo, tutti i membri possono continuare a lavorare al progetto insieme, anche se non sono fisicamente insieme.

Come in altre metodologie Agile, utilizza le riunioni giornaliere per fare il punto della situazione e incoraggiare una comunicazione costante e aperta. È consigliabile utilizzare sia un ciclo settimanale che un ciclo trimestrale. Durante il ciclo trimestrale, tu e il tuo team esaminerete le storie che guideranno il vostro lavoro. Studierete anche il processo XP, cercando lacune o opportunità per apportare modifiche. Quindi, lavorerai in cicli settimanali, ognuno dei quali inizia con una riunione con il cliente. Il cliente sceglie la storia utente su cui vuole che i programmatori lavorino quella settimana. 

In qualità di manager o team leader, il tuo obiettivo sarà mantenere l’avanzamento del lavoro, misurare il ritmo, spostare i membri del team per risolvere bug o problemi man mano che si presentano o modificare il processo XP per adattarlo al tuo progetto e all’iterazione attuali. Ricorda che l'obiettivo di XP è essere flessibili e agire, quindi il tuo lavoro sarà altamente focalizzato sul lavoro attuale del team e reattivo a qualsiasi cambiamento.

3. Progettazione

Quando hai appena iniziato con la programmazione estrema, inizia con il design più semplice possibile, sapendo che le iterazioni successive lo renderanno più complesso. Non aggiungere funzionalità iniziali in questa fase per mantenere il progetto il più semplice possibile.

I team che utilizzano la metodologia XP spesso usano le schede CRC (Class-Responsibility-Collaboration) per mostrare come interagisce ogni oggetto nel design. Compilando ogni campo della scheda, otterrai un'interazione visiva di tutte le funzioni mentre si relazionano e interagiscono. Le schede CRC includono: 

• Classe (raccolta di oggetti simili)

• Responsabilità (relative alla classe)

• Collaboratori (classe che interagisce con questa)

Le CRC sono utili per stimolare il processo e individuare potenziali problemi. Indipendentemente da come progetti, ti consigliamo di utilizzare un sistema che riduca i potenziali colli di bottiglia. Per farlo, assicurati di cercare i rischi in modo proattivo. Non appena emerge una potenziale minaccia, assegna a uno o due membri del team il compito di trovare una soluzione nel caso in cui la minaccia si concretizzi.

4. Scrittura di codice

Uno degli aspetti più singolari dell’XP è che si rimane in costante contatto con il cliente durante tutto il processo di codifica. Questa collaborazione ti consente di testare e incorporare il feedback all'interno di ogni iterazione, invece di aspettare fino alla fine di uno sprint. Ma le regole di codifica sono piuttosto rigide. Alcune di queste includono:

• Tutto il codice deve soddisfare gli standard di codifica.

• Utilizzo di un test unitario per definire i requisiti e sviluppare tutti gli aspetti del progetto.

• Programmazione in coppia: due sviluppatori lavorano insieme contemporaneamente sullo stesso computer. Questo non aggiunge tempo, ma piuttosto utilizza il doppio della concentrazione per produrre risultati di altissima qualità. 

• Utilizzare integrazioni continue per aggiungere nuovo codice e testarlo immediatamente.

• Solo una coppia può aggiornare il codice in un dato momento, per ridurre gli errori.

• Proprietà collettiva del codice: qualsiasi membro del team può modificare il codice in qualsiasi momento.

5. Test

Dovresti eseguire test durante tutto il processo di programmazione estrema. Tutto il codice dovrà superare i test unitari prima di essere rilasciato. Se durante questi test si scoprono bug, si creeranno nuovi test aggiuntivi per correggerli. Successivamente, la stessa user story su cui si sta lavorando viene configurata in un test di accettazione. Durante questo test, il cliente esamina i risultati per vedere come è stata tradotta la user story nel prodotto.

Quali sono le 12 pratiche di Extreme Programming?

Per affinare ulteriormente il processo, XP utilizza anche una serie di 12 pratiche durante tutto il processo. Si basano sul manifesto Agile, ma sono adattate alle esigenze di XP:

1. Il gioco della pianificazione: la pianificazione XP viene utilizzata per guidare il lavoro. I risultati della pianificazione dovrebbero essere ciò che speri di realizzare, entro quando e cosa farai dopo.

2. Test del cliente: quando si completa una nuova funzionalità, il cliente svilupperà un test di accettazione per determinare quanto sia vicina alla sua user story originale.

3. Piccole versioni: XP utilizza piccole versioni di routine per ottenere approfondimenti durante tutto il processo. Spesso, le versioni vengono rilasciate direttamente ai clienti, anche se possono essere rilasciate internamente.

4. Design semplice: il sistema XP è progettato per la semplicità: produrrai solo ciò che è necessario e niente di più. 

5. Programmazione in coppia: tutta la programmazione viene eseguita da una coppia di sviluppatori che siedono fianco a fianco. Non esiste il lavoro in solitario nella programmazione estrema.

6. Sviluppo guidato dai test (TDD): la dipendenza di XP dal feedback richiede test approfonditi. Attraverso cicli brevi, i programmatori rilasciano test automatizzati e quindi reagiscono immediatamente.

7. Refactoring: è qui che presterai attenzione ai dettagli più fini del codebase, rimuovendo i duplicati e assicurandoti che il codice sia coerente. Ciò si traduce in design buoni e semplici.

8. Responsabilità collettiva: qualsiasi coppia di programmatori può modificare il codice in qualsiasi momento, indipendentemente dal fatto che lo abbia sviluppato o meno. XP produce codice come team e il lavoro di tutti è conforme agli standard collettivi più elevati.

9. Integrazione continua: i team XP non aspettano che le iterazioni siano completate, ma integrano costantemente. Spesso, un team XP effettua l'integrazione più volte al giorno.

10. Ritmo sostenibile: l'intensità del lavoro in XP richiede di impostare un ritmo sostenibile. I team dovrebbero decidere quanto lavoro possono produrre in questo modo al giorno e alla settimana, e utilizzare tale informazione per fissare le scadenze di lavoro.

11. Metafora: la metafora è, letteralmente, una metafora. Viene decisa dal team e utilizza il linguaggio per descrivere come dovrebbe funzionare il team. Ad esempio, siamo formiche che lavorano insieme per costruire il formicaio. 

12. Standard di codifica: i team XP seguono un unico standard. Nello stesso modo in cui gli scrittori devono assumere la voce di un marchio per dare l'impressione che sia sempre la stessa persona a scrivere, gli sviluppatori XP codificano nello stesso modo unificato in modo che sembri che sia sempre lo stesso sviluppatore a scrivere.

Intensa, ma efficace

A questo punto, probabilmente avrai capito che l'eXtreme Programming è, beh, estremo. Il processo è rigoroso e altamente strutturato, ma i risultati potrebbero valerne la pena. Il processo di sviluppo unico di XP, che incorpora il feedback dei clienti e una programmazione intensa e collaborativa, si traduce in un software di alta qualità. 

Semplifica la pianificazione e la gestione della programmazione estrema con uno strumento di gestione del lavoro che si aggiorna e si adatta in tempo reale, proprio come il tuo lavoro.