Il Planning Game

Il planning game di XP si basa su un principio semplice: Il business decide cosa costruire. Gli sviluppatori decidono come costruirlo.

Questa separazione è fondamentale:

• Il business comprende valore, priorità e tempistiche. Sa quali funzionalità contano per i clienti e quando sono necessarie.
• Gli sviluppatori comprendono sforzo, complessità e vincoli tecnici. Sanno cosa è difficile e cosa è facile.

Nessuno dei due può fare il lavoro dell'altro. Il business non può stimare lo sforzo tecnico. Gli sviluppatori non possono decidere le priorità di business. Il planning game li riunisce con ruoli chiari.

Il business sceglie:

• Quali funzionalità costruire
• In quale ordine costruirle
• Quando rilasciare

Gli sviluppatori forniscono:

• Stime per ogni funzionalità
• Opzioni tecniche e compromessi
• Valutazioni del rischio

La pianificazione del rilascio risponde a: Cosa sarà incluso nel prossimo rilascio e quando verrà consegnato?

XP dice che puoi fissare due di queste tre variabili:

• Ambito: Quali funzionalità sono incluse
• Tempistiche: Quando avviene il rilascio
• Risorse: Chi ci lavora

Non puoi fissarle tutte e tre. Qualcosa deve essere flessibile.

Rilascio a data fissa: "Consegniamo il 1° marzo. Quanto riusciamo a fare?" L'ambito è negoziabile.

Rilascio ad ambito fisso: "Ci servono queste funzionalità. Quando possiamo consegnarle?" La data è negoziabile.

Il processo del planning game:

1. Il business elenca le funzionalità desiderate in ordine di priorità
2. Gli sviluppatori stimano ogni funzionalità
3. In base alla velocity, si calcola quante funzionalità entrano entro la data (o quanto tempo serve per completare l'ambito)
4. Il business aggiusta le priorità se necessario
5. Ci si impegna su un piano, ma ci si aspetta di ripianificare

Ripianifica regolarmente. Man mano che impari di più, aggiorna il piano di rilascio. XP non presume che il piano iniziale sia sacro.

La pianificazione dell'iterazione è più dettagliata. Avviene all'inizio di ogni iterazione (di solito settimanale o bisettimanale).

Il processo:

1. Il business presenta le storie con priorità più alta per l'iterazione
2. Gli sviluppatori suddividono le storie in task (blocchi da 2-4 ore)
3. Gli sviluppatori si assegnano i task in base a interesse e competenza
4. Il team si impegna su ciò che completerà in questa iterazione

Regole chiave:

• Solo il business stabilisce la priorità
• Solo gli sviluppatori stimano e si impegnano
• Non impegnarsi eccessivamente (lascia margine per l'imprevisto)
• Includi il lavoro tecnico (infrastruttura, refactoring) nel piano

Durante l'iterazione:

• Traccia i progressi in modo visibile (/learn/kanban/visualizing-work/board-anatomy, burndown)
• Se fuori rotta, segnalalo immediatamente
• Non aggiungere ambito a metà iterazione (proteggi la concentrazione)
• Se in anticipo, prendi la storia successiva

La pianificazione dell'iterazione è più leggera della pianificazione del rilascio. Le storie sono già stimate. Il focus è sulla suddivisione in task e sull'impegno su quantità realistiche.

I piani cambiano. XP se lo aspetta e integra l'adattamento.

Quando aggiustare:

• Le stime erano sbagliate (la storia era più grande del previsto)
• Le priorità sono cambiate (il cliente ha scoperto nuovi requisiti)
• La capacità del team è cambiata (malattia, turnover)
• Le dipendenze esterne sono fallite (API non pronta)

Come aggiustare:

1. Porta a galla il problema immediatamente (trasparenza)
2. Quantifica l'impatto (siamo indietro di 2 storie)
3. Proponi opzioni (ridurre ambito, estendere o ridurre qualità—ma mai la qualità)
4. Il business decide (ha la proprietà della priorità)

Cosa non cambia mai: La qualità. XP non scambia qualità per ambito o tempistiche. Se sei indietro, consegni meno—non peggio.

Il planning game presume un aggiustamento continuo. Il piano iniziale è un punto di partenza, non un impegno a un risultato esatto. Come dice Kent Beck: "Lo scopo della pianificazione è pianificare, non il piano."

Il planning game richiede un cliente—qualcuno che rappresenta le priorità di business.

Potrebbe essere:

• L'utente finale effettivo (ideale ma raro)
• Un product owner (terminologia Scrum)
• Un product manager
• Un business analyst

Il cliente deve:

• Essere disponibile per rispondere alle domande (idealmente ogni giorno)
• Prendere decisioni sulle priorità rapidamente
• Accettare compromessi quando le cose cambiano
• Fornire criteri di accettazione per le storie

Il "cliente on-site" di XP originariamente significava qualcuno fisicamente presente con il team. Nei team distribuiti moderni, "on-site" potrebbe significare "su Slack" o "nello standup giornaliero." La chiave è la disponibilità, non la posizione fisica.

Senza un cliente, la pianificazione fallisce. Gli sviluppatori indovinano la priorità. L'ambito si espande perché nessuno decide cosa è fuori. Il team costruisce la cosa sbagliata.