Le Origini di XP

Nel 1996, Kent Beck fu assunto per salvare un progetto di gestione stipendi in difficoltà presso Chrysler chiamato C3 (Chrysler Comprehensive Compensation). Il progetto era nei guai—il classico sviluppo waterfall aveva prodotto un sistema che non funzionava e non poteva essere riparato.

Beck non si limitò a sistemare il progetto. Sintetizzò decenni di saggezza dell'ingegneria del software in una metodologia coerente. Prese pratiche che gli sviluppatori esperti sapevano funzionare—testing, code review, sviluppo iterativo—e le portò ai loro estremi logici.

Se il testing è buono, testa costantemente. Se la code review è buona, rivedi continuamente tramite pair programming. Se l'integrazione è buona, integra più volte al giorno. Se le iterazioni brevi sono buone, rendile ancora più brevi.

Il progetto C3 fu rilasciato. Ancora più importante, creò un modello che avrebbe rimodellato lo sviluppo software.

Nel 1999, Kent Beck pubblicò "Extreme Programming Explained"—spesso chiamato "il White Book" per la sua copertina. Questo divenne il documento fondante di XP e uno dei primi manifesti agile.

Il libro fu controverso. Pair programming tutto il tempo? Nessun grande design iniziale? Clienti in sede? Molti nel settore pensavano che Beck fosse pazzo. Ma i team che provarono XP riportarono risultati notevoli:

• Drasticamente meno bug che raggiungevano la produzione
• Ritmo sostenibile invece di marce della morte
• Software funzionante invece di promesse documentali
• Sviluppatori felici che si sentivano in controllo

Due anni dopo, nel 2001, Beck si unì ad altri sedici professionisti del software a Snowbird, Utah. Insieme scrissero l'Agile Manifesto. L'influenza di XP è visibile ovunque—individui sui processi, software funzionante, collaborazione con il cliente, risposta al cambiamento.

XP fu la prima metodologia agile completa, e per molti versi rimane la più rigorosa.

La visione tradizionale dello sviluppo software era che il cambiamento è costoso. Il costo di correggere un bug cresce esponenzialmente dai requisiti al design alla codifica al testing alla produzione. Pertanto, dovresti fare tutto il possibile per farlo bene la prima volta—da qui l'enfasi del waterfall sul design iniziale completo.

Beck propose un'alternativa radicale: E se potessi appiattire la curva del costo del cambiamento?

Se hai:

• Test automatizzati completi (i cambiamenti possono essere validati istantaneamente)
• Design semplice (meno da cambiare)
• Ownership collettiva del codice (chiunque può fare cambiamenti)
• Integrazione continua (i cambiamenti sono integrati immediatamente)
• Competenze di refactoring (il codice può evolversi in sicurezza)

Allora il costo del cambiamento diventa approssimativamente costante nel tempo. E se il cambiamento è economico, non hai bisogno di prevedere il futuro. Puoi abbracciare il cambiamento come vantaggio competitivo.

Questa è l'intuizione fondamentale di XP: le pratiche tecniche possono rendere il cambiamento economico, e il cambiamento economico cambia tutto.