Il Cliente On-Site

XP originariamente richiedeva un cliente on-site—un utente reale o il suo rappresentante, fisicamente presente con il team.

Perché così estremo?

Lo sviluppo software è un continuo prendere decisioni:

• Come dovrebbe comportarsi questo caso limite?
• Quale di questi due design è migliore per gli utenti?
• Vale la pena correggere questo bug o è una limitazione nota?
• Cosa è più importante: la funzionalità A o la funzionalità B?

Se il cliente non è disponibile, gli sviluppatori indovinano. Indovinano male. Costruiscono la cosa sbagliata. Oppure aspettano, bloccando i progressi finché non ottengono una risposta.

Clienti disponibili:

• Sbloccano le decisioni in minuti, non giorni
• Colgono i malintesi presto
• Prendono decisioni sulle priorità nel contesto
• Costruiscono fiducia attraverso una stretta collaborazione

Il ruolo del cliente XP comporta sia diritti che responsabilità.

Diritti del cliente:

• Conoscere il costo stimato di ogni storia
• Conoscere la velocity del team e quando le cose saranno completate
• Cambiare le priorità in qualsiasi momento (entro i confini dell'iterazione)
• Cancellare il progetto e ottenere un sistema funzionante (qualunque cosa sia stata fatta)
• Vedere i progressi attraverso software funzionante, non solo report

Responsabilità del cliente:

• Essere disponibile a rispondere rapidamente alle domande
• Prendere decisioni sulle priorità quando richiesto
• Fornire criteri di accettazione per le storie
• Accettare compromessi quando lo scope supera la capacità
• Dare feedback sul software consegnato prontamente

Questa è una partnership. Il cliente non è uno stakeholder distante che lancia requisiti oltre il muro. È un membro del team che prende decisioni quotidianamente.

In pratica, il "cliente reale" è spesso non disponibile. Ha un lavoro. Non può stare con gli sviluppatori tutto il giorno.

Entra in scena il proxy del product owner—qualcuno che rappresenta il cliente:

• Product manager
• Business analyst
• Product owner (terminologia Scrum)
• Esperti interni della materia

Il modello proxy funziona quando:

• Il proxy comprende veramente le esigenze degli utenti
• Il proxy ha l'autorità per prendere decisioni
• Il proxy è genuinamente disponibile (non sovraimpegnato)
• I clienti reali forniscono input regolare (demo, sessioni di feedback)

Il modello proxy fallisce quando:

• Il proxy non comprende il dominio
• Il proxy non può prendere decisioni senza escalation
• Il proxy è troppo occupato per essere disponibile
• I clienti reali non vedono mai il software

I test di accettazione sono il modo in cui clienti e sviluppatori verificano di comprendersi a vicenda.

Per ogni storia, il cliente definisce i criteri di accettazione:

• Dato [questo contesto]
• Quando [questa azione accade]
• Allora [questo dovrebbe essere il risultato]

Questi diventano test eseguibili. Quando i test passano, la storia è completata. Nessun dibattito sul fatto che sia "veramente completata".

Benefici:

• Requisiti non ambigui (se il test passa, funziona)
• Documentazione vivente (i test descrivono cosa fa il sistema)
• Sicurezza di regressione (i test colgono quando il comportamento cambia)
• Coinvolgimento del cliente (scrivere criteri richiede riflessione)

Nell'XP moderno, i test di accettazione sono spesso scritti in collaborazione tra cliente e sviluppatori. Il cliente descrive il comportamento; gli sviluppatori aiutano a tradurlo in forma testabile.

I team moderni sono spesso distribuiti. Il cliente "on-site" è un canale Slack, una chiamata Zoom o un messaggio asincrono.

Farlo funzionare da remoto:

• Sovracomunicare (assumere che nulla sia ovvio)
• Usare il video per l'interazione faccia a faccia quando possibile
• Creare modi a basso attrito per fare domande (chat invece di email)
• Registrare le decisioni così sono ritrovabili dopo
• Rispettare i fusi orari (non aspettarsi risposte istantanee alle 3 del mattino)

Coinvolgimento asincrono del cliente:

• Scrivere domande chiare con contesto
• Offrire opzioni piuttosto che domande aperte
• Stabilire aspettative per i tempi di risposta
• Usare documenti per decisioni complesse (più facili da rivedere in modo asincrono)

Il principio rimane: minimizzare il tempo tra domanda e risposta. Il lavoro remoto rende questo più difficile ma non impossibile.