Extreme Programming: in cosa consiste?

Avete già sentito parlare di Extreme Programming? Quanto ne sapete su questo metodo per lo sviluppo software?

Nata nell’universo agile e nel project management, questa metodologia ha conosciuto le luci della ribalta a cavallo degli anni Novanta e Duemila. Ma in cosa consiste di preciso?

In questo articolo ci soffermiamo sui principi che la regolano, sui pro e contro che offre e sulle tecniche da seguire per metterla in atto.

L’Extreme Programming, letteralmente programmazione estrema, è una metodologia agile utilizzata per lo sviluppo software.

Partendo da un approccio customer centered, questo metodo offre un framework che mira a produrre una scrittura del codice di qualità elevata e una miglior qualità per l’intero team coinvolto nel progetto.

Elaborato da Kent Beck, informatico statunitense noto anche per aver progettato il test driven development, questo metodo ha avuto un ruolo di rilievo nel grande successo dei metodi agili.

Pensato in un primo momento soprattutto per l'ambito informatico, il metodo è oggi molto popolare perché risulta funzionale per tutti i tipi di progetti, di tutte le dimensioni e in tutti i settori, in tutto il mondo. A detta di molti, questa metodologia offre le sue migliori prestazioni all’interno di team di piccole e medie dimensioni, che non superano la ventina di persone.

I principi alla base dell’extreme programming sono gli stessi conosciuti nell’universo agile: reattività dinanzi ai cambiamenti, flessibilità, collaborazione, qualità del lavoro, qualità del testing, ecc.

☝️ La differenza risiede nel fatto che queste caratteristiche sono accentuate all’estremo.

Vediamo ora i suoi valori fondamentali:

• Comunicazione: è essenziale che ciascun membro del team comunichi quotidianamente con i suoi colleghi e con il cliente. Un flusso continuo di scambio di informazioni può essere un mezzo essenziale per risolvere i problemi.
• Semplicità: spesso, il modo più semplice per raggiungere un risultato è anche quello più efficace. Bisogna quindi privilegiare il semplice e l’essenziale. Ne consegue che il team di sviluppo deve concentrarsi esclusivamente sulle task strettamente necessarie. Le modifiche supplementari potranno essere apportate in un secondo momento.
• Feedback: lo scambio di informazioni tra il team incaricato del progetto e il cliente è essenziale. Ogni fase del progetto dev’essere inviata al cliente il più rapidamente e frequentemente possibile. Ogni richiesta di modifica dev’essere presa immediatamente in considerazione.
• Rispetto: il rispetto per il lavoro delle persone coinvolte deve costituire una conditio sine qua non. Il management, il team responsabile del progetto e il cliente lavorano insieme e devono rispettarsi l’un l’altro.
• Coraggio: il cambiamento richiede coraggio. Per imparare a padroneggiare una nuova tecnica, è consigliabile ricominciare da capo un’iterazione non validata o rivedere l’organizzazione di un progetto. Solo in questo modo si può uscire vincenti da una situazione complessa.

A livello concreto, i 5 valori fondamentali visti sopra si declinano in 12 regole fondamentali. Queste sono raggruppabili in 4 aree.

• Pair programming: consiste in un meccanismo volto a controllare la qualità del lavoro. Si lavora per binomio: mentre un collega scrive il codice, l’altro lo controlla. Per lavorare su una workstation comune, è molto importante assicurarsi che il duo abbia un livello di esperienza simile.
• Planning game (o poker planning ): la pianificazione si svolge in collaborazione con il cliente. Quest'ultimo esprime le funzionalità che desidera ottenere. Il team valuta il tempo necessario per la loro attuazione. Infine, si prioritizzano le varie task. Questa riunione ha, solitamente, cadenza settimanale.
• Test-Driven Development: la scrittura del test (sia unitario che di accettazione) avviene prima ancora di iniziare lo sviluppo della parte funzionale. Questa tecnica permette di individuare possibili errori in netto anticipo.
• On-Site Customer: idealmente, almeno un rappresentante del cliente dev’essere parte integrante del team, per avere una visione globale del risultato ricercato e poter rispondere alle domande del team.

• Sustainable pace: gli straordinari sono banditi. Se sono necessari, va rivista la programmazione a monte. Un dipendente stanco lavora male e commette più errori. È bene non superare mai le 40 ore settimanali!

• Refactoring (o design improvement): il progetto viene costantemente migliorato. L'obiettivo è lavorare su basi solide e avere delle condizioni di lavoro ottimali. Nel codice vengono quindi costantemente rimosse ripetizioni e elementi superflui.
• Small releases: Le release devono essere il più frequenti possibile, per dare al cliente la possibilità di esporre critiche e proposte in maniera continuativa. Così gli errori sono individuati e corretti più rapidamente.
• Continuous integration: non appena un'attività è completata, viene immediatamente integrata nel prodotto. Così, si evita il lavoro supplementare necessario per integrare tutti gli elementi prima della consegna finale. I test facilitano questa integrazione: quando tutti i test sono positivi, l'iterazione è completata.

• Collective Code Ownership: la responsabilità del progetto è collettiva. Ciò implica che ciascun membro può intervenire su tutte le sezioni del progetto, comprese quelle sulle quali non ha lavorato. L’obiettivo? Un’efficacia e una rapidità al top.
• Coding standards: poiché tutti lavorano congiuntamente, è essenziale facilitare il lavoro di tutti utilizzando gli stessi termini, lo stesso stile e delle modalità per comunicare ben definite.
• Simple Design: la progettazione semplice permette di avere un codice comprensibile a tutti. Si punta al nocciolo della questione, con un focus esclusivamente sulle necessità dei clienti.
• System Metaphor: per descrivere il progetto nella maniera più semplice possibile, si fa ricorso a metafore. L’obiettivo è che i nuovi collaboratori possano comprendere rapidamente tutti gli aspetti analizzati.

Se si verificano le giuste condizioni, l’extreme programming può offrire risultati sorprendenti.

Ecco alcuni punti di forza:

• un codice pulito e lineare,
• un software stabile grazie allo sviluppo iterativo continuo,
• la possibilità di apportare costantemente delle modifiche.

I punti di debolezza sono invece i seguenti:

• necessità di un budget mediamente più alto,
• necessità di coinvolgimento del cliente,
• necessità di autodisciplina e pianificazione elevate.

Grazie a questo metodo, manager, sviluppatori e clienti lavorano congiuntamente. Questo approccio collaborativo spinge tutto il team (whole team) ad applicare il massimo di semplicità e reattività, e garantisce un controllo versione continuo.

Nella pratica però, si tratta di un metodo complesso da implementare, poiché richiede molta autodisciplina e una buona comunicazione interna. Se però le giuste condizioni sono rispettate, questo metodo può produrre dei grandi risultati.

E voi, avete già visto applicare questo metodo in azienda? Quali sono le vostre impressioni in materia? Aspettiamo i vostri feedback! 😉