Quando XP funziona

XP è stato progettato per progetti in cui i requisiti cambiano frequentemente. Se non sai esattamente cosa costruire, XP ti aiuta a scoprirlo.

Segnali di alta incertezza:

• I clienti non riescono ad articolare le loro esigenze con precisione
• Il mercato è in evoluzione
• Stai costruendo qualcosa di nuovo, non replicando qualcosa di noto
• Il feedback degli utenti cambia regolarmente le priorità
• I concorrenti stanno innovando, costringendoti ad adattarti

In questi ambienti, gli approcci tradizionali falliscono. La progettazione dettagliata iniziale diventa obsoleta prima dell'implementazione. I grandi rilasci mancano l'obiettivo perché i requisiti sono cambiati.

XP abbraccia il cambiamento. I piccoli rilasci ottengono feedback rapidamente. La progettazione semplice evita investimenti eccessivi. Il planning game si adatta continuamente. L'incertezza non è un problema—è prevista.

Se i tuoi requisiti sono davvero stabili e ben compresi, XP funziona comunque, ma la proposta di valore è diversa. Ottieni qualità e salute del team, ma i benefici dell'adattabilità sono meno pronunciati.

XP brilla quando il codice vivrà per anni. L'investimento nelle pratiche tecniche ripaga nel tempo.

Perché i sistemi di lunga durata beneficiano di XP:

• Test: Individuano le regressioni mentre il sistema evolve
• Refactoring: Mantengono il design pulito mentre i requisiti cambiano
• Ownership collettivo: Diffondono la conoscenza mentre i membri del team vanno e vengono
• Progettazione semplice: Evitano l'accumulo di complessità
• CI: Mantengono la disciplina di integrazione mentre il team cresce

Se stai costruendo un prototipo che verrà eliminato, l'investimento di XP nella qualità potrebbe non ripagare. Ma la maggior parte dei "prototipi" diventano sistemi di produzione. La maggior parte del codice "temporaneo" vive per anni.

La scommessa: Presumi che il tuo codice vivrà più a lungo di quanto pensi. Investire nella qualità fin dall'inizio. Se ti sbagli, hai perso un po' di tempo. Se hai ragione (e di solito ce l'hai), hai risparmiato anni di sofferenza.

XP richiede una stretta collaborazione. Il pair programming, i planning game e l'ownership collettivo funzionano solo quando le persone lavorano bene insieme.

Segnali che il tuo team è pronto:

• Le persone comunicano apertamente, anche sui problemi
• C'è fiducia tra i membri del team
• Le persone si aiutano a vicenda senza che venga chiesto
• I disaccordi vengono risolti in modo costruttivo
• Il team ha sicurezza psicologica

Se il tuo team manca di queste qualità, le pratiche XP sembreranno forzate e imbarazzanti. Potresti dover costruire la salute del team prima di adottare XP—o usare le pratiche XP per costruire gradualmente la salute del team.

XP può migliorare la collaborazione, ma non può forzarla. Un team di persone che non condivideranno il codice non abbraccerà improvvisamente l'ownership collettivo. Un team che ha paura di ammettere gli errori non beneficerà della trasparenza.

La cultura deve supportare le pratiche—o almeno essere disposta a cambiare.

XP richiede un cliente disponibile—qualcuno che possa rispondere alle domande, prendere decisioni sulle priorità e fornire feedback.

Senza disponibilità del cliente:

• Gli sviluppatori indovinano i requisiti (spesso sbagliando)
• Le priorità non sono chiare (tutto sembra importante)
• Il feedback arriva troppo tardi (le funzionalità sono costruite male)
• Il planning game non può funzionare

Disponibilità del cliente significa:

• Domande risposte in ore, non giorni
• Decisioni sulle priorità prese quando richiesto
• Feedback regolare sul lavoro consegnato
• Coinvolgimento nel processo di pianificazione

Se i tuoi clienti non sono disponibili, XP diventa difficile. Puoi usare un product owner come proxy, ma qualcuno deve svolgere efficacemente il ruolo del cliente.

La disfunzione organizzativa spesso impedisce la disponibilità del cliente. Il cliente è troppo occupato, troppo politico o troppo distante. Questi sono problemi organizzativi da risolvere, non problemi di XP.

Alcune pratiche XP presuppongono contesti moderni di sviluppo software. Potrebbero richiedere adattamenti in altri ambienti.

TDD presuppone:

• Puoi scrivere test automatizzati (non tutti gli ambienti lo supportano facilmente)
• I test vengono eseguiti rapidamente (test lenti rendono TDD doloroso)
• Esiste una cultura del testing (il team crede nel testing)

CI presuppone:

• Il codice può essere integrato frequentemente
• Build e test possono essere automatizzati
• Lo sviluppo basato su trunk è fattibile

Il pair programming presuppone:

• Il lavoro avviene al computer
• Due persone possono vedere lo stesso schermo
• Il lavoro beneficia della collaborazione in tempo reale

Nella maggior parte dello sviluppo software, questi presupposti sono validi. Ma sistemi embedded, codice dipendente dall'hardware o ambienti altamente regolamentati potrebbero richiedere l'adattamento delle pratiche.

I principi rimangono. Le pratiche specifiche possono cambiare.