Site icon Ryadel

Extreme Programming (XP): cos'è e come funziona

7 Good Reasons To Use React JS for Web Development

Qualche settimana fa abbiamo parlato di Lean Development, un sistema di principi e pratiche di sviluppo software basato sul pensiero snello e sulla riduzione degli sprechi. In questo articolo ci dedicheremo all'approfondimento di un'altra metodologia di sviluppo software appartenente al vasto insieme di metodologie Agile: la Programmazione Estrema, più nota come Extreme Programming o XP.

Indroduzione

Extreme Programming (abbreviato in XP) è una metodologia Agile di sviluppo del software che enfatizza la scrittura di codice di qualità e, nel contempo, la rapidità di risposta ai cambiamenti di requisiti. Si tratta di una delle prime metodologie agili a essersi affermate nella comunità software, incontrando un particolare successo a fine anni '90 e inizio 2000.

Sviluppata quasi interamente da Kent Beck mettendo insieme diverse tecniche già in uso, la Programmazione Estrema è, a detta di molti, la metodologia che più di ogni altra ha favorito l'affermazione, la diffusione e l'applicazione dei concetti Agile - originariamente pensati per l'industria manifatturiera, ovvero basata sugli impianti di produzione - all'interno dello sviluppo del software.

Elementi distintivi

La Programmazione Estrema, come detto, appartiene alla famiglia delle metodologie Agili, e come tale prescrive lo sviluppo iterativo e incrementale strutturato in brevi cicli di sviluppo.

I suoi elementi distintivi sono:

  • Pair programming: due programmatori lavorano insieme su una sola workstation, il driver è colui che scrive il codice mentre il navigator ragiona sull'approccio e pensa se può funzionare.
  • Planning Game: riunione di pianificazione che avviene una volta per iterazione (o sprint).
  • Test Driven Development: scrivere i test automatici prima di scrivere il codice.
  • Whole Team: coinvolgere il committente (o l’utente finale) nella verifica, test e feedback.
  • Continuous integration: integrare i cambiamenti apportati al codice il più rapidamente possibile (con appositi software di version control e aggiornamenti molto frequenti).
  • Refactoring: riscrivere il codice senza alterarne le funzionalità esterne, cambiando l'architettura, in modo da renderlo più semplice e generico.
  • Small Releases: frequenti rilasci di funzionalità che creano del valore concreto.
  • Coding Standards: adozione di uno standard di scrittura del codice, ovvero un set di regole concordate che l’intero team di sviluppo accetta di rispettare.
  • Collective Code Ownership: ciascuno sviluppatore è responsabile di tutto il codice.
  • Simple Design: utilizzare un approccio KISS alla progettazione.
  • System Metaphor: utilizzare metafore per descrivere il sistema (user stories, epics, etc.).
  • Sustainable Pace: ciascuno sviluppatore non dovrebbe lavorare più di 40 ore a settimana.

Altri principi degni di nota includono: il divieto ai programmatori di sviluppare codice non strettamente necessario, l'enfasi sulla chiarezza e la semplicità del codice, la preferenza per strutture gestionali non gerarchiche, e l'importanza data alla comunicazione diretta e frequente tra sviluppatori e cliente.

Perché "estrema?"

Il termine Extreme Programming, e ancor più la sua traduzione in lingua italiana (Programmazione Estrema), può facilmente portare fuori strada e spingere gli sviluppatori a farsi un'idea non corretta su questa metodologia: ovviamente, non c'è nulla di realmente estremo nella sua applicazione. Il significato della parola riguarda il fatto che i dodici principi su cui si basa la metodologia non sono altro che un'estensione di diverse good practices già in vigore presso la maggior parte degli sviluppatori (e adottate da tutti i moderni corsi di programmazione che insegnano come diventare web developer), che vengono però portate all'estremo.

Un esempio perfetto per comprendere il concetto è dato dalla regola Test Driven Development, che prevede l'utilizzo sistematico degli Unit Test: l'applicazione "estrema" degli Unit Test significa che  questi ultimi cessano di essere semplicemente degli utili strumenti da utilizzare di tanto in tanto per diventare parte integrante dello sviluppo di codice. Nello specifico, uno sviluppatore di software che adotta la metodologia Extreme Programming applicherà la regola Test Driven Development convertendo tutti i requisiti software in casi di test specifici: poiché il codice non è ancora stato implementato, la condizione iniziale di ciascuno di questi test sarà fail (o red, dal colore convenzionalmente assegnato al test che fallisce), per poi diventare pass (green) a implementazione avvenuta.

Il lavoro dello sviluppatore diventa quindi il seguente:

  • Trasformare gli item di sviluppo in casi di test, ciascuno dei quali avrà condizione iniziale fail (red).
  • Scrivere il nuovo codice (o modificare il codice esistente) implementando la funzionalità richiesta, così da portare il test in una condizione di pass (green).
  • Migliorare il codice sviluppato (refactoring), senza modificarne le funzionalità e avendo cura di mantenere il test in condizione di pass (green).

Il susseguirsi di queste tre fasi dà vita a un vero e proprio processo iterativo, come rappresentato dall'immagine seguente:

Extreme Programming (XP): cos'è e come funziona

Uno sviluppo "sostenibile"

Un'altra caratteristica distintiva dell'Extreme Programming è quella di essere l'unica metodologia Agile che enfatizza non soltanto l’empowerment degli sviluppatori (Whole Team e Collective Code Ownership), ma anche la sostenibilità del lavoro (Sustainable Pace): una particolarità particolarmente importante in un periodo come quello attuale, in cui i team di sviluppo sono spesso costretti (dal business, dal mercato, dagli utenti, etc.) a sostenere periodi di sviluppo intensi e prolungati (i cosiddetti crunch).

Inserire la Sustainable Pace all’interno della metodologia di lavoro responsabilizza negativamente la scelta di ricorrere a un crunch, che diventa in tal modo una violazione del metodo di lavoro del tutto analoga, in linea di principio, ad altre deroghe generalmente considerate più pericolose (ad es. sulla sicurezza).

Conclusioni

Per il momento è tutto: ci auguriamo che questo articolo possa essere utile a tutti gli sviluppatori e ai project manager interessati ad approfondire e/o adottare questa metodologia di sviluppo. Alla prossima!

Exit mobile version