Suzanne Robertson

Dicembre 2016

Anatomia di una storia Quando la user story diventa poco utile

Le storie giuste parlano di valore di business e non di soluzioni. Ecco perché bisogna mettere da parte l’utente, prendere in considerazione il quadro generale e soprattutto non chiamarle più “user story”

La metodologia Agile ha sicuramente portato numerosi vantaggi e molte buone idee, tra cui, purtroppo, non vi sono le user story. Entrambe le definizioni correnti di user story, indicata come “segnaposto” per una conversazione o per i requisiti, sono accettabili. Però, se la “storia” va considerata un segnaposto, allora deve segnare il posto giusto, e deve guidare la conversazione nella giusta direzione. Purtroppo, molte storie non lo fanno. Oggi, il problema fondamentale dello sviluppo del software è che la principale causa del fallimento di un progetto è un fallimento dei requisiti. Questo “fallimento dei requisiti” copre l’intera gamma: non scoprire le funzionalità necessarie; non capire le sfumature dell’usabilità richiesta; non trasmettere in modo adeguato le esigenze agli sviluppatori; e, spesso, non scoprire il vero problema da risolvere. Purtroppo, spesso la user story contribuisce direttamente al problema requisiti.

Ma come mai le user story si rivelano scarse quando si tratta di requisiti?

Cominciamo con l’idea stessa di “utenti”. Quando qualcuno scrive una user story, spesso presume già il tipo di soluzione da adottare, presume chi la utilizzerà, e presume le funzionalità della soluzione. In altre parole, chi scrive la “storia” pensa di conoscere la soluzione, ma probabilmente non capisce il problema che questa dovrà risolvere, se davvero conosce qual è il vero problema.

Se guardiamo al numero impressionante di progetti che forniscono soluzioni non corrette, possiamo concludere con sicurezza che questi progetti non sono riusciti a comprendere correttamente il problema, ma nonostante questo hanno spinto per realizzare una soluzione.

 

LE PARTI DELLA STORIA – Nella sua forma più comune, la user story è così: “In qualità di [ruolo] – voglio [funzionalità] – in modo che [il valore di business]”. Una storia come questa non indica sempre, e il più delle volte non lo fa, quale problema di business sta cercando di risolvere. La ragione è questa: “voglio” è quasi sempre seguito da una soluzione presunta: “Voglio accedere al mio account dal cellulare”; “Voglio fare drag e drop sugli appuntamenti programmati”; “Voglio un display che mostri gli orari dei treni”; e così via. Queste sono soluzioni, e soprattutto danno scarse indicazioni sul fatto che risolvano o meno il vero problema di business. L’ultimo elemento della storia, la giustificazione, cioè “in modo che [il valore di business]”, potrebbe dare una migliore indicazione di quale sia il problema. Però, indicando una soluzione, è probabile che il valore di business giustifichi semplicemente (ed erroneamente) la soluzione.

La giustificazione potrebbe sembrare valida, ma raramente lo è: “Come cliente di banca – voglio l’accesso online al mio conto – in modo da poter controllare il mio saldo 24 ore su 24”. Il “perché” giustifica la soluzione online, ma essere in grado di controllare il conto in banca 24 ore su 24 non risolve alcun problema reale di business sia per il cliente sia per la banca. Vedere il saldo di oggi non ci dice quanto possiamo permetterci di spendere prima del prossimo accredito di stipendio. Forse, controllare il saldo discrezionale è più utile, perché senza conoscere le uscite per il resto del mese, il saldo corrente è di scarsa utilità. La soluzione non è il punto di partenza, in particolare quando si tratta semplicemente di una presunzione.

 

BUSINESS STORY O USER STORY? – L’unico software utile che si può sviluppare è quello che contribuisce al business che lo impiega. Così, invece di occuparsi di utenti, è meglio iniziare le storie occupandosi di business. Quindi, parleremo di “business story”, indicandola, con lo stesso formato, così:

“In qualità di [cliente esterno o altro ente esterno] – posso [raggiungere un obiettivo di business] – in modo che [valore per il cliente/ente esterno/ business]”. Si noti che la business story non tenta di fornire una soluzione al problema, ma parla di un obiettivo di business che fornisce valore a un cliente esterno, e quindi per l’azienda che lo fornisce. Per illustrare meglio questo concetto, si può rivisitare l’esempio bancario, guardando questa volta il problema dal punto di vista di business, omettendo ogni possibile soluzione al problema. La storia diverrà così: “Come cliente di banca – posso consultare spesso e comodamente il mio conto e la sua attività – in modo da essere sicuro di conoscere sempre la mia posizione finanziaria”.

Questa storia offre un valore reale: se la banca consente ai clienti di avere sempre il controllo della propria situazione bancaria, allora è in grado di attirarne di nuovi e di soddisfare quelli esistenti. Ma c’è dell’altro in questa storia: non dà alcun dettaglio su come il “consultare spesso e comodamente” debba essere raggiunto – ma questo è un fatto positivo. Ora abbiamo una storia che non solo occupa il posto giusto per una conversazione, ma ha spostato la conversazione verso la progettazione: “Ora che abbiamo capito il problema, qual è la soluzione migliore?”. Ecco perché le storie giuste parlano di valore al business, e non di soluzioni. Perché se bisogna fornire un valore reale, allora questo valore deve essere rivolto verso l’esterno.

I flussi di dati da e verso il mondo esterno sono collegati a eventi di business, che sono il driver fondamentale di tutte le attività di business. È possibile scrivere una business story per ciascun evento, e deve fornire valore sia per il cliente esterno sia per il proprietario, in modo che ora la conversazione sulla storia possa concentrarsi sulla migliore soluzione di business per ottenere tale valore. Ci sono naturalmente altri modi per descrivere la risposta a ciascuno degli eventi di business: se si desidera utilizzare storie, allora suggeriamo di scrivere una storia sull’attività da svolgere, e di evitare tutto ciò che ha a che fare con una soluzione, in quanto la soluzione diventerà evidente in maniera automatica una volta che si siano correttamente indicate le esigenze di business reali. All’inizio, questo potrebbe portare via più tempo rispetto al saltare dritti verso la soluzione presunta, ma va tenuto a mente che sia secondo Gartner sia secondo altri, la maggior parte delle soluzioni presunte sono quelle sbagliate. E prendendosi il tempo necessario per comprendere il vero problema, la soluzione che ne deriverà automaticamente apporterà un vero valore di business, senza bisogno di essere rielaborata prima che diventi accettabile.

 

Come scrivere storie migliori

Ma allora come si possono scrivere storie migliori? Si può iniziare a non chiamarle o a non pensarle come “user story”. E per un momento si può mettere da parte l’utente e prendere in considerazione il quadro generale, i clienti esterni e chi ha in mano l’organizzazione che metterà in pratica la soluzione, per pensare al business e alle esigenze del business. Non scriviamo “voglio”, ma “ho bisogno di essere in grado di”, o più semplicemente “posso”. Entrambi i casi sono naturalmente seguiti da alcune funzionalità o dell’attività di business, e non da una soluzione. Si potrebbe anche considerare di lasciare temporaneamente questa parte fuori della storia e concentrarsi sulla parte di valore. Il valore deve naturalmente essere valore reale, cioè un effettivo beneficio misurabile, anche perché la parte relativa al valore si collega e sostiene gli obiettivi del progetto. Quindi, la prossima volta che ci si trova a scrivere una storia rivolta agli utenti, è il caso di fare un passo indietro, per considerare la storia dal punto di vista del business. Scrivendo business story, si renderanno molto più soddisfatti gli eventuali utenti.