Le Pratiche XP: Una Panoramica

XP non è un menu in cui scegli i tuoi preferiti. Le pratiche sono progettate per rafforzarsi a vicenda. Rimuovine una e le altre diventano più difficili o meno efficaci.

Per esempio:

• Il Refactoring è sicuro perché hai test completi
• Il Design semplice è possibile perché puoi fare refactoring quando cambiano i requisiti
• La Proprietà collettiva funziona perché hai standard di codifica
• L'Integrazione continua è fattibile perché hai rilasci piccoli e test

Questa natura interconnessa è il motivo per cui "fare TDD ma non refactoring" o "pair programming senza test" spesso fallisce. Stai rimuovendo un muro portante.

Detto questo, devi iniziare da qualche parte. Discuteremo l'adozione incrementale nel Modulo 5.

Queste sono le pratiche fondamentali che la maggior parte dei team XP adotta:

Pratiche di Pianificazione:

• User Story: Requisiti come spunti di conversazione
• Planning Game: Il business sceglie cosa, gli sviluppatori scelgono come
• Rilasci Piccoli: Consegnare valore frequentemente
• Pianificazione dell'Iterazione: Suddividere le story in task per ogni iterazione

Pratiche di Sviluppo:

• Test-Driven Development (TDD): Scrivi prima il test
• Pair Programming: Due sviluppatori, una tastiera
• Refactoring: Migliorare il codice senza cambiare il comportamento
• Design Semplice: La cosa più semplice che funziona
• Integrazione Continua: Integrare e testare molte volte al giorno

Pratiche di Team:

• Whole Team: Tutti quelli necessari per consegnare, in una stanza
• Proprietà Collettiva del Codice: Chiunque può modificare qualsiasi codice
• Standard di Codifica: Convenzioni di codice concordate
• Ritmo Sostenibile: Niente straordinari come regola

Tratteremo ciascuna di queste in profondità nei moduli successivi.

Queste pratiche sono potenti ma richiedono maggiore maturità o condizioni specifiche:

• Coinvolgimento Reale del Cliente: Il cliente effettivo, non solo un proxy
• Analisi delle Cause Radice: Correggere il sistema, non solo il sintomo
• Codice Condiviso: Tutto il codice è visibile a tutti gli sviluppatori
• Codice e Test: Codice e test sono gli unici artefatti permanenti
• Base di Codice Singola: Un branch, non molti
• Deploy Giornaliero: Rilasciare in produzione ogni giorno
• Contratto a Scope Negoziato: Contratti che abbracciano il cambiamento
• Pay-Per-Use: Feedback diretto dai clienti reali

Queste non sono "XP avanzato". Sono pratiche che funzionano bene nel contesto giusto ma potrebbero essere inappropriate o impossibili in altri.

Un modo per comprendere le pratiche XP è attraverso i loro cicli di feedback:

Secondi: Unit test Minuti: Pair programming Ore: Integrazione continua Giorno: Standup Settimana: Pianificazione dell'iterazione, demo al cliente Mese/Trimestre: Rilascio, retrospettiva

A ogni scala, XP crea opportunità per imparare e adattarsi. Questo è intenzionale. Più velocemente impari, più velocemente puoi correggere la rotta.

Se non stai ricevendo feedback a ciascuna di queste scale, manca qualcosa.

Questo potrebbe sembrare travolgente. Non cercare di adottare tutto in una volta.

La maggior parte dei team inizia con:

1. TDD o almeno scrivere test
2. Integrazione Continua
3. Iterazioni (o sprint se si usa Scrum)
4. Retrospettive

Questi formano le fondamenta. Una volta che funzionano, aggiungi:

• Pair programming (inizia solo con i problemi difficili)
• Refactoring (inizia con il codice più disordinato)
• Rilasci piccoli (inizia rilasciando più frequentemente)

Tratteremo le strategie di adozione nel Modulo 5. Per ora, comprendi semplicemente il panorama.