Principi XP

I valori ti dicono cosa è importante. Le pratiche ti dicono cosa fare. Ma come li colleghi? È qui che entrano in gioco i principi.

I principi sono il ponte. Sono più concreti dei valori ma più astratti delle pratiche. Quando devi decidere se adottare una pratica o modificarla per il tuo contesto, i principi ti guidano.

XP ha molti principi, ma ci concentreremo su quelli più importanti.

Il software è fatto da persone, per le persone.

Questo principio ci ricorda che gli sviluppatori non sono risorse intercambiabili. Le persone hanno bisogni:

• Sicurezza (fisica e psicologica)
• Realizzazione (fare un lavoro significativo)
• Appartenenza (far parte di un team)
• Crescita (imparare e migliorare)
• Intimità (relazioni strette e di fiducia)

Le pratiche XP dovrebbero soddisfare questi bisogni. Il pair programming soddisfa i bisogni di appartenenza e intimità. Lo sviluppo guidato dai test soddisfa i bisogni di realizzazione e sicurezza. Il ritmo sostenibile protegge la salute fisica e mentale.

Quando una pratica non ti convince, chiediti: "Sta violando i bisogni umani?"

Il denaro conta. Il tempo ha valore. Le opzioni hanno valore.

XP prende sul serio l'economia:

• Valore temporale del denaro: una funzionalità consegnata oggi vale più della stessa funzionalità tra sei mesi
• Opzioni: mantenere aperte le scelte ha valore (da qui l'evitare l'eccessivo impegno)
• Costo del ritardo: aspettare per consegnare valore ha costi reali

Questo principio supporta i rilasci piccoli (consegnare valore presto), il design incrementale (non investire troppo in anticipo) e la pianificazione iterativa (rispondere a ciò che impari).

Supporta anche il ritmo sostenibile: gli sviluppatori esausti commettono errori costosi.

Ogni pratica dovrebbe beneficiare tutti i coinvolti.

Le migliori pratiche XP sono vantaggiose per tutti:

• I test aiutano lo sviluppatore (fiducia), il team (documentazione) e gli sviluppatori futuri (rete di sicurezza)
• Il pair programming aiuta entrambi i partner (apprendimento, individuazione degli errori) e il codice (qualità)
• Il codice semplice aiuta l'autore (più veloce da scrivere) e i lettori (più facile da capire)

Evita pratiche che aiutano un gruppo a spese di un altro. La documentazione scritta solo per conformità, mai letta dagli sviluppatori, non rispetta il beneficio reciproco. Anche il codice scritto per essere ingegnoso piuttosto che chiaro lo viola.

Se una pratica crea risentimento, probabilmente viola il beneficio reciproco.

I pattern che funzionano a una scala spesso funzionano anche ad altre.

XP applica gli stessi pattern a scale diverse:

• Rosso-verde-refactoring (test): fallo fallire, fallo passare, rendilo pulito
• Pianifica-esegui-studia-agisci (iterazioni): pianifica il lavoro, esegui il lavoro, studia i risultati, aggiusta
• Raccogli-raggruppa-vota (rétro): raccogli dati, trova pattern, decidi azioni

Quando trovi qualcosa che funziona, provalo a scale diverse. Il planning game funziona per la pianificazione del rilascio e la pianificazione dell'iterazione. I principi della revisione del codice funzionano per la revisione del design e la revisione dell'architettura.

Parti da dove sei e migliora continuamente.

XP non richiede la perfezione dal primo giorno. Richiede movimento. Inizia con ciò che puoi fare oggi e migliora da lì.

• Non hai test? Scrivi un test per il prossimo bug che risolvi.
• Non fai pair programming? Provalo per un'ora domani.
• Niente integrazione continua? Fai commit più frequentemente.

L'obiettivo non è "fare XP". L'obiettivo è migliorare. XP è una direzione, non una destinazione.

Questo principio supporta anche il fallire in sicurezza. Gli esperimenti che non funzionano sono opportunità di apprendimento, non fallimenti.

Consegna valore continuamente, non in grandi lotti.

Questo principio allinea XP con il pensiero lean e Kanban. I grandi lotti nascondono i problemi. I piccoli lotti li fanno emergere rapidamente.

• Storie piccole (giorni, non settimane)
• Rilasci frequenti (settimanali, non trimestrali)
• Integrazione continua (ore, non giorni)
• Test immediato (secondi, non ore)

Il flusso riduce il lavoro in corso, che riduce il cambio di contesto, che migliora la concentrazione e la qualità. Inoltre, fornisce valore ai clienti prima e feedback più velocemente.

La qualità non è negoziabile.

Sembra ovvio, ma le implicazioni sono profonde. XP dice che puoi scambiare ambito o tempi, ma mai la qualità.

Questo significa:

• I test non sono opzionali quando il tempo stringe
• Il refactoring non è un lusso
• Il debito tecnico non è accettabile
• "Rilascia ora, sistema dopo" non è un piano

Perché? Perché la qualità è il fondamento della velocità. La scarsa qualità crea bug che ti rallentano. La scarsa qualità crea codice difficile da modificare. La scarsa qualità crea sistemi costosi da mantenere.

La qualità è il modo più veloce per andare veloci.

Fai il passo più piccolo che faccia progredire.

I grandi cambiamenti sono rischiosi. I piccoli cambiamenti sono sicuri. XP preferisce sempre i piccoli passi:

• Scrivi un test che fallisce prima di scrivere qualsiasi codice
• Fai refactoring di una cosa alla volta
• Integra dopo piccole modifiche, non grandi
• Rilascia piccoli incrementi, non grandi rilasci

I piccoli passi non significano progresso lento. Mille piccoli passi possono coprire più terreno di dieci grandi salti—e con meno possibilità di cadere.

Quando sei bloccato, chiediti: "Qual è la cosa più piccola che posso fare adesso che faccia progredire?"