Storia dell'utente

Una user story è una breve descrizione di un requisito espressa dal punto di vista della persona che ne trarrà beneficio, convenzionalmente scritta sotto forma di ruolo, capacità desiderata e motivazione. È nata nell'ambito della programmazione estrema (Extreme Programming) ed è diventata il formato dominante per descrivere il lavoro nello sviluppo iterativo.

Il suo scopo viene spesso frainteso. La storia non è una specifica; è un promemoria per avviare una conversazione. La formulazione originale descriveva le storie come dei segnaposto per una discussione tra le persone che desiderano la funzionalità e le persone che la svilupperanno, e il testo scritto esiste per garantire che la discussione avvenga, non per sostituirla. I team che considerano la scheda come un requisito completo hanno adottato il formato e scartato il meccanismo.

La clausola motivazionale è l'elemento più importante e quello che più spesso viene scritto con superficialità. Specificare il motivo per cui si desidera una determinata funzionalità permette al team di proporre soluzioni diverse e spesso migliori per la stessa esigenza, e consente di de-prioritizzare onestamente un lavoro quando la motivazione di fondo si rivela inefficace. Le descrizioni dei requisiti in cui la clausola motivazionale si limita a ribadire la funzionalità, come ad esempio la necessità di un pulsante per poterlo premere, non comunicano nulla ed eliminano la possibilità di avviare una discussione in merito.

Le dimensioni contano perché una storia deve essere completabile all'interno di un'iterazione e fornire qualcosa che l'utente possa effettivamente sperimentare. Le storie troppo grandi non possono essere completate o valutate, mentre le storie scomposte in livelli tecnici, come la creazione separata di una tabella di database o di un componente di interfaccia, non forniscono nulla di osservabile singolarmente. La suddivisione verticale, in cui ogni storia attraversa ogni livello per produrre una funzionalità snella ma completa, è ciò che preserva la capacità di dimostrare e apprendere.

Il formato è una convenzione, non un requisito, e una rigida adesione produce assurdità. Il lavoro tecnico senza un utente diretto, come l'aggiornamento di una dipendenza o il miglioramento dell'osservabilità, non si adatta al modello e forzarlo crea un utente artificiale che desidera un aggiornamento della libreria. Documentare tale lavoro in modo chiaro, specificandone le motivazioni, è più onesto e utile che distorcerlo per conformarsi a un formato.

I criteri di accettazione sono ciò che rende una storia verificabile e ne costituiscono a pieno titolo parte integrante, anziché un elemento separato. Essi definiscono le condizioni in base alle quali la storia sarà considerata completa, inclusi i casi limite e i percorsi di errore che la forma narrativa omette. Senza di essi, la completezza diventa una questione di opinione e il disaccordo emerge solitamente in fase di revisione, quando è più costoso risolverlo.

Le storie si accumulano formando un arretrato che diventa ingestibile se non viene mai eliminato. Gli elementi scritti molti mesi fa descrivono un prodotto e un mercato che nel frattempo sono cambiati, e un arretrato di diverse centinaia di storie è un documento che nessuno legge, anziché un piano. Eliminare periodicamente le storie che non verranno realisticamente realizzate è scomodo, ma decisamente più utile che mantenerle indefinitamente.

Poiché il valore dipende dalla conversazione piuttosto che dall'artefatto, l'efficacia è determinata dalla partecipazione delle persone giuste. In pratica il formato viene utilizzato all'interno sviluppo del prodotto con il bisogno sottostante evidenziato attraverso ricerca dell'utente piuttosto che essere date per scontate, e le organizzazioni che sviluppano questa capacità internamente di solito stabiliscono la pratica di scrittura e perfezionamento all'interno di un reparto prodotti in modo che le storie nascano da problemi comprovati.