eXtreme Programming

eXtreme Programming — di solito semplicemente XP — è il membro più esigente della famiglia agile. East Agile Tracker è costruito prima di tutto per XP; tutto il resto ne discende.

Questa pagina copre cosa sia XP, perché funzioni e come praticarlo con il tracker come superficie di pianificazione.

Cos’è XP

XP fu creato da Kent Beck alla fine degli anni ‘90. Il primo libro — Extreme Programming Explained: Embrace Change — fu pubblicato nel 1999. Iniziò, come molte cose, con un team frustrato che cercava di rilasciare un sistema di buste paga in Chrysler.

La scommessa di XP è che il modo giusto di gestire l’incertezza nel software sia fare le cose che funzionano, e farle più spesso. Testare? Testa di continuo. Integrare? Integra ogni ora. Parlare? Parla costantemente. Pianificare? Pianifica ogni iterazione, e ripianifica man mano che impari.

“XP è una metodologia leggera per team di piccole-medie dimensioni che sviluppano software a fronte di requisiti vaghi o in rapido cambiamento.” — Kent Beck

I cinque valori

XP nomina cinque valori a cui tutto il resto si appende:

1. Comunicazione — Il team parla. Quotidianamente. Del lavoro, della progettazione, degli ostacoli. Faccia a faccia quando possibile. I silos sono il nemico.
2. Semplicità — Fai la cosa più semplice che potrebbe funzionare. Puoi aggiungere complessità in seguito se ne hai davvero bisogno. Probabilmente non ne avrai bisogno.
3. Feedback — Dal codice (i test), dal team (pair programming, review), dall’utente (release frequenti). Ottienilo velocemente.
4. Coraggio — Dì la verità su progresso, stime e progettazione. Butta via il codice che non funziona. Rifattorizza ciò che ti sta frenando.
5. Rispetto — Tutti nel team — e ora, ogni agente del team — contribuiscono valore. Trattatevi di conseguenza.

Le pratiche

XP è famoso per le sue dodici pratiche originali, organizzate in quattro aree:

Pianificazione

• Planning Game — Il team e il cliente pianificano insieme: cosa viene dopo, in quale ordine, quanto è grande ogni pezzo.
• Small Releases — Rilascia spesso. Giorni, non mesi. Ottieni feedback su qualcosa di concreto.
• User Stories — I requisiti sono conversazioni, catturate come brevi storie dal punto di vista dell’utente. “Come utente, voglio X, così da Y.”

Progettazione

• Simple Design — La progettazione più semplice che passa i test ed esprime ogni concetto necessario. Niente di più.
• Refactoring — Migliora la progettazione del codice che già funziona. Costantemente.
• System Metaphor — Una storia condivisa di come funziona il sistema, usata per rendere coerenti le decisioni di progettazione.

Codifica

• Pair Programming — Due sviluppatori, una tastiera. Uno guida, uno naviga. Cambiate spesso.
• Collective Code Ownership — Chiunque può migliorare qualsiasi codice. Niente feudi.
• Continuous Integration — Integra e testa il codice molte volte al giorno. Cattura subito le rotture.
• Coding Standards — Uno stile concordato così che il codice si legga come se l’avesse scritto una sola persona.

Test

• Test-Driven Development (TDD) — Scrivi prima il test che fallisce, poi il codice che lo fa passare.
• Acceptance Tests — Il cliente definisce, in codice o in forma eseguibile, cosa significhi “done” per ogni storia.

Perché XP funziona

XP è scomodo. Il pair programming ti costringe a pensare ad alta voce. Il TDD ti costringe a sapere come appare il successo prima di scrivere il codice. L’integrazione continua uccide i tuoi amati branch a lunga durata. Le piccole release significano che non puoi nasconderti dietro una roadmap di sei mesi.

Funziona perché tutte queste cose accorciano i cicli di feedback. Più velocemente scopri di aver sbagliato, più economica è la correzione. XP riguarda, fondamentalmente, il rendere il ciclo di feedback il più stretto possibile.

Riguarda anche coraggio e rispetto. Puoi fare XP solo in un team che si fida abbastanza l’uno dell’altro da sbagliare ad alta voce.

Il modello disciplinato delle storie

East Agile Tracker codifica una teoria specifica della pianificazione. Tratta questa sezione come il manuale operativo del perché il modello dei dati sia fatto così — e come la guida sul campo su cosa fare (e non fare) nella pratica.

Perché i quattro tipi di storia contano

Tutto è una storia, ma ci sono quattro tipi, e la distinzione è tutto il punto:

• Le feature portano punti e sono l’unica cosa che “conta” verso la velocity. Questo ti costringe a suddividere il lavoro in valore osservabile dall’utente.
• I bug sono senza punti (zero). I difetti non guadagnano credito, il che rende visibile il costo della rilavorazione anziché premiarlo.
• I chore sono anch’essi senza punti — lavoro necessario senza valore diretto per l’utente (infra, refactoring, setup). Tenerli a zero spinge il team a raggrupparli nelle feature ovunque possibile, così l’inquadramento del valore rimane onesto.
• Le release sono marcatori a zero punti usati per ancorare le milestone e permettere allo strumento di proiettare una data.

L’effetto comportamentale è ciò che conta: quando i bug e i chore non fanno punteggio, un team tende naturalmente a esprimere il lavoro come funzionalità orientata all’utente e diventa acutamente consapevole del costo dei difetti. È una disciplina di pianificazione codificata nel modello dei dati.

Il singolo backlog ordinato

Tre zone, una regola.

• L’Icebox è il bacino di idee non prioritizzate.
• Il Backlog è un elenco rigorosamente ordinato, a priorità singola — nessun pareggio, nessun “P1/P1/P1.”
• La zona Current contiene l’iterazione (o le iterazioni) attiva.

Il product owner possiede l’ordine dall’alto al basso, e l’invariante è che la cima del backlog è sempre la cosa più importante e meglio specificata, con la chiarezza che legittimamente diminuisce man mano che si scende. Una storia vicina alla cima con criteri di accettazione vaghi è un bug di pianificazione. È consentito che l’Icebox sia un cimitero; il Backlog no.

Pianificazione automatica guidata dalla velocity

Questa è la parte che la maggior parte dei team reimplementa male altrove. La pianificazione in stile tracker calcola una velocity media mobile dai punti accettati di recente e tira automaticamente quel numero di punti di storie nell’iterazione successiva — non sei tu a “impegnarti” manualmente a uno sprint, lo fanno per te i dati empirici. Due conseguenze che vale la pena preservare:

• Stimi solo le feature, usando punti relativi (Fibonacci 1/2/3/5/8 o la nostra scala più stretta 0/1/2/3), non ore. La stima è una conversazione sul dimensionamento, non una promessa.
• Non manipoli la velocity. Gonfiare i punti per “sembrare veloci”, o assegnare punti ai chore, spezza la proiezione che rende onesto l’intero sistema. La velocity è uno strumento di misura, e non si manomette il proprio strumento.

Il vantaggio è che la proiezione della data di release diventa un calcolo anziché una negoziazione, e la conversazione con gli stakeholder passa da “puoi impegnarti a fare X entro venerdì” a “all’attuale velocity, questa release arriva intorno alla data Y — ecco il compromesso tra scope e data.”

Il ciclo di vita della storia e il ciclo di accettazione

La macchina a stati è Start → Finish → Deliver → Accept / Reject. Lo stato critico è Deliver: un ingegnere segna una storia come delivered, ma non è done finché il product owner non la accetta esplicitamente rispetto ai suoi criteri di accettazione — oppure la rifiuta, rimandandola indietro. Questo incorpora un ciclo di feedback dal cliente in ogni singola storia, invece di rinviare l’accettazione a una demo di fine sprint.

I criteri di accettazione appartengono alla storia prima che venga avviata, idealmente in forma Given/When/Then così da mapparsi direttamente sui test di accettazione. INVEST è il controllo di sanità su quanto una storia sia ben formata:

• Independent — può essere rilasciata senza altre storie.
• Negotiable — cattura l’intento, non una specifica congelata.
• Valuable — per un utente o uno stakeholder.
• Estimable — il team può dimensionarla.
• Small — sta comodamente in un’iterazione.
• Testable — ha criteri di accettazione che possono essere esercitati.

Cadenza

Le cerimonie di pianificazione sono leggere e regolari:

• Un Iteration Planning Meeting settimanale per assegnare punti alle nuove storie e fissare i criteri di accettazione in cima al backlog.
• Un breve daily standup focalizzato sul flusso e sui blocker.
• Una retrospettiva per iterazione per aggiustare il processo.

Le iterazioni sono di solito una o due settimane — abbastanza brevi da rendere economico scoprire una stima sbagliata.

Le pratiche ingegneristiche che fanno funzionare la pianificazione

La pianificazione in stile tracker è la metà visibile di XP; crolla senza la metà ingegneristica.

• Test-first / TDD e una vera suite di test di accettazione sono ciò che permette a “delivered” di significare qualcosa.
• L’integrazione continua e le piccole release frequenti mantengono breve il cycle time così che la velocity sia stabile anziché a singhiozzo.
• Il pair programming (o una review forte) mantiene basso il lavoro in corso — finisci prima di iniziare — che è la singola leva più importante sul cycle time.
• Un product owner disponibile è ciò che impedisce al ciclo accetta/rifiuta di bloccarsi.

Anti-pattern da tenere d’occhio

I fallimenti ricorrenti:

• Trattare il Backlog come un parcheggio invece che come un vero ordine di priorità.
• Stimare bug e chore per far sembrare migliore la velocity.
• Portarsi dietro storie enormi che non possono finire in un’iterazione. Suddividi finché ciascuna è rilasciabile in modo indipendente.
• Lasciare che le storie si accumulino in Delivered perché nessuno le accetta.

Ognuno di questi converte silenziosamente un sistema empirico di nuovo in pianificazione velleitaria. Il tracker non può impedirti di farli; può solo renderli visibili. Guarda la tua colonna Delivered alla fine di ogni iterazione — se sta crescendo, è il tuo segnale.

XP con East Agile Tracker

Il tracker è la superficie di pianificazione che i team XP desideravano dai tempi di Pivotal Tracker. Ogni concetto si mappa direttamente:

User Stories → Storie

Le user story XP sono le storie di East Agile Tracker. Scrivile nel tipo Feature. Usa la descrizione per la conversazione; usa i commenti per la discussione continua. I criteri di accettazione appartengono alla descrizione.

Planning Game → La board

Il Planning Game in XP è una conversazione tra business e team su priorità e dimensione. In East Agile Tracker:

1. La persona del prodotto scrive le storie nel Backlog e le ordina per priorità.
2. Il team stima le feature in punti (scala Fibonacci o East Agile).
3. Il sistema auto-pianifica le iterazioni dalla velocity.
4. Il team avvia le storie dalla cima della colonna Current.

Tutto qui. Il “gioco” vive nella conversazione; il tracker tiene solo il punteggio.

Small Releases → Release (il tipo di storia)

XP dice di rilasciare spesso. Release è uno dei quattro tipi di storia in East Agile Tracker. Crea una release per ogni milestone di rilascio; trascinala nell’iterazione in cui viene rilasciata. Le release saltano Started/Finished/Delivered e vanno dritte ad Accepted quando rilasci.

Continuous Integration → Macchina a stati della storia

La macchina a stati non è CI di per sé — quello è il tuo sistema di build — ma il percorso Finished → Delivered → Accepted rispecchia il ciclo di accettazione del cliente che XP descrive. Finisci il lavoro, consegnalo al cliente, accetta quando è confermato funzionante.

Velocity → “Il tempo di ieri”

XP la chiama il tempo di ieri (yesterday’s weather): quanto hai fatto nell’ultima iterazione è la migliore previsione di quanto farai in questa. East Agile Tracker calcola la velocity automaticamente — media delle iterazioni recenti, strategia configurabile — e la usa per auto-pianificare la capacità dell’iterazione successiva.

Acceptance Tests → Review

Le review delle storie nel tracker si mappano sull’accettazione. Assegna un revisore (il cliente, il product owner o anche un agente che ne fa le veci). Approva o rifiuta. Il rifiuto rimanda la storia a Started.

Pair Programming → Co-proprietà

I team XP fanno pair sul codice. Nel tracker, questo si manifesta come più owner su una storia. Assegna entrambi i partner alla storia; entrambi i nomi appaiono sulla card.

XP con gli agenti — la nuova pratica

XP fu scritto prima che gli agenti IA potessero contribuire in modo significativo al software. Pensiamo che questo sia l’aggiornamento più importante a XP in venticinque anni.

Nella nostra pratica — e per ciò per cui il tracker è costruito — un agente è un membro del team XP con nome. Ha un proprio ruolo, un proprio partner di pair (umano o agente) e una propria traccia di audit. Può fare tutto ciò che può fare un membro umano del team nella superficie di pianificazione: stimare, possedere storie, commentare, far transitare, accettare review.

I valori XP reggono ancora. Comunicazione: gli agenti comunicano leggendo lo stream di eventi e pubblicando commenti. Semplicità: gli agenti sono vincolati ai ruoli che concedi loro. Feedback: ogni azione dell’agente è nell’audit log, immediatamente revisionabile. Coraggio: sii onesto su cosa i tuoi agenti hanno fatto bene e cosa no. Rispetto: i compagni di squadra agenti contribuiscono valore — riconoscilo.

Non mettiamo gli agenti dentro il tracker a fare la codifica. Diamo la superficie di pianificazione a umani e agenti che lavorano insieme. Tu porti l’agente di codifica — Claude Code, Codex, il tuo — e lo colleghi al tracker tramite l’API. L’agente prende in carico le storie, fa il lavoro, commenta, fa transitare. Tu revisioni la traccia e accetti.

Questa è la Pianificazione Agile Inclusiva. È XP, con il team che ha davvero.

Letture di approfondimento

• Extreme Programming Explained — Il libro fondante di Kent Beck, 1999.
• Il Manifesto Agile — Da dove è iniziata la famiglia.
• Sviluppo agile — Il quadro più ampio.
• Istruzioni operative — Guida pratica al tracker.
• Guida API — Collegare il tuo agente di codifica.