User Story

Le user story non sono documenti di requisiti. Sono segnaposto per conversazioni.

Ron Jeffries ha sintetizzato questo concetto nelle "3 C":

Card: Una breve descrizione che sta su una scheda. "Come utente, voglio reimpostare la mia password per poter riottenere l'accesso al mio account."

Conversazione: Il dialogo tra sviluppatori e clienti che definisce i dettagli. Cosa significa "reimpostare"? Link via email? Codice SMS? Domande di sicurezza?

Conferma: I criteri di accettazione che indicano quando la story è completata. "Dato un'email valida, quando clicco su 'reimposta password', allora ricevo un'email con un link di reimpostazione entro 1 minuto."

La card non è il requisito. La conversazione è il requisito. La card è solo un promemoria per avere la conversazione.

Il formato classico della story è:

Come [tipo di utente] Voglio [una certa capacità] In modo da [valore di business]

Ad esempio:

• Come acquirente, voglio filtrare i prodotti per prezzo in modo da poter trovare articoli nel mio budget.
• Come amministratore, voglio esportare i dati utente in CSV in modo da poter analizzare le tendenze in Excel.
• Come ospite, voglio completare l'acquisto senza creare un account in modo da poter comprare rapidamente.

La clausola "in modo da" è cruciale. Spiega perché la funzionalità è importante. Questo aiuta gli sviluppatori a prendere buone decisioni sull'implementazione e aiuta i product owner a dare priorità.

Story sbagliate omettono il perché:

• "Come utente, voglio un pulsante blu." (Perché? Cosa fa?)
• "Implementare la funzionalità di ricerca." (Per chi? Quale valore?)

Story corrette collegano le funzionalità al valore:

• "Come cliente abituale, voglio riordinare il mio ultimo acquisto in modo da poter comprare di nuovo senza cercare."

L'acronimo INVEST descrive le qualità delle buone story:

Independent (Indipendente): Le story possono essere sviluppate in qualsiasi ordine. Nessuna dipendenza tra story.

Negotiable (Negoziabile): L'ambito è flessibile. I dettagli vengono negoziati attraverso la conversazione.

Valuable (Di valore): Ogni story fornisce valore agli utenti. Nessuna "story tecnica" senza beneficio per l'utente.

Estimable (Stimabile): Il team può stimare quanto è grande. Se no, la story necessita chiarimenti o suddivisione.

Small (Piccola): Una story dovrebbe richiedere meno di una settimana di lavoro. Idealmente pochi giorni.

Testable (Testabile): Ci sono criteri di accettazione chiari. Puoi verificare quando è completata.

Quando una story viola INVEST, correggila:

• Story dipendenti: Combinale o rompi la dipendenza
• Story grandi: Suddividi in pezzi più piccoli
• Story non stimabili: Prima fai uno spike per ridurre l'incertezza
• Story non testabili: Chiarisci i criteri di accettazione

Le story grandi devono essere suddivise. Ma come?

Suddividi per fase del flusso di lavoro: "L'utente può completare il checkout" →

• L'utente può aggiungere articoli al carrello
• L'utente può inserire l'indirizzo di spedizione
• L'utente può inserire le informazioni di pagamento
• L'utente può confermare ed effettuare l'ordine

Suddividi per variazione di dati: "L'utente può pagare l'ordine" →

• L'utente può pagare con carta di credito
• L'utente può pagare con PayPal
• L'utente può pagare con gift card

Suddividi per operazione: "L'utente può gestire il proprio profilo" →

• L'utente può visualizzare il proprio profilo
• L'utente può modificare il proprio nome
• L'utente può cambiare la propria email
• L'utente può eliminare il proprio account

Suddividi per prestazioni: "La ricerca restituisce risultati rapidamente" →

• La ricerca restituisce risultati (qualsiasi velocità)
• La ricerca restituisce risultati in meno di 2 secondi

Ogni story suddivisa dovrebbe essere rilasciabile in modo indipendente. Se non puoi rilasciare il supporto parziale per carte di credito (solo Visa, non Mastercard), è comunque una suddivisione—consegni valore in modo incrementale.

Vale la pena ripeterlo: le story non sono specifiche.

I documenti di requisiti tradizionali cercano di specificare ogni dettaglio in anticipo. Questo fallisce perché:

• Non puoi conoscere tutti i dettagli prima di iniziare
• I documenti scritti vengono interpretati in modo diverso da lettori diversi
• Le specifiche diventano obsolete man mano che la comprensione cambia
• Scoraggiano la conversazione

Le story abbracciano l'incertezza. La card cattura l'intento. La conversazione riempie i dettagli al momento giusto. La conferma verifica la comprensione.

Il cliente rimane coinvolto per tutto il tempo. Quando gli sviluppatori hanno domande, chiedono al cliente—non al documento. Questo mantiene il team allineato e si adatta all'apprendimento.

Le story incoraggiano anche a rimandare le decisioni. Non devi decidere ogni caso limite in anticipo. Gestisci prima il percorso principale. Quando incontri un caso limite, fai una conversazione in quel momento.

Questo è l'approccio XP ai requisiti: quanto basta, al momento giusto, attraverso la conversazione.