Articoli del meseArticoli del mese

Articoli del mese


Stampa articolo

Articolo del Mese - febbraio 2017

Anatomia di una storia - Quando la user story diventa poco utile

Suzanne Robertson by Suzanne Robertson

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.

Anatomia di una storia - Quando la user story diventa poco utile - Technology Transfer

Arrivano i microservice Quando sbarazzarsi dei monoliti. E quando no
Sander Hoogendoorn

I Big Data forniscono il contesto e la ricchezza predittiva attorno alle transazioni di business Avere dati coerenti e di qualità resta fondamentale per il processo decisionale
Barry Devlin

Cosa c’è dietro l’angolo? Cinque mosse per diventare un digital leader
Jeroen Derynck

Managing information technology Gestire l’IT come un business nel business
Mitchell Weisberg

Data integration self-service Miglioramento della produttività o caos totale?
Mike Ferguson

Project manager vecchi miti e nuove realtà
Aaron Shenhar

La catena alimentare dei requisiti
Suzanne Robertson

Come diventare un’azienda data-centric
Lindy Ryan

Enterprise analytical ecosystem - Come comprendere il comportamento online dei clienti e capitalizzare il valore dei dati nell’era Big Data
Mike Ferguson

Agilità? Basta Volere
Suzanne Robertson

Ma la vostra architettura è efficace?
Mike Rosen

Se il NoSQL diventa SQL
Rick van der Lans

La data quality e l’impatto sul business
Danette McGilvray

Business analysis e regole di business By Ronald G. Ross con Gladys S.W. Lam
Ronald Ross

Usare Scrum su larga scala: cosa cambia?
Craig Larman

Le architetture per ridurre il debito tecnico
Mike Rosen

Conversando con un marziano
Suzanne Robertson

Cosa c’è di nuovo nel project management?
Aaron Shenhar

Reinventare la Business Intelligence
Barry Devlin

Il nuovo volto della business intelligence
Shaku Atre

Alla ricerca del valore tra i pomodori nell'orto
John Favaro

I big data cambiano il mercato dei Database Server
Rick van der Lans

Un “superstorm” di informazioni
Barry Devlin

I dieci step per la qualità dei dati
Danette McGilvray

Perché è meglio evitare il private cloud?
Jason Bloomberg

Leonardo da Vinci aveva ragione!
Chris Date

Mobile user experience: Come adottare una strategia sostenibile
James Hobart

Cosa significa occuparsi di architettura?
Mike Rosen

Virtualizzazione dei dati e sistemi di Business Intelligence Agili
Rick van der Lans

Modelli e linguaggi naturali, quale il modo migliore per definire i requisiti?
James Robertson

Extreme Scoping: un approccio Agile all'Edw e alla BI
Larissa Moss

BI², la Business Intelligence al quadrato
Barry Devlin

I test di regressione in ambienti legacy
Randy Rice

Le conseguenze della consumerizzazione e del Cloud
Chris Potts

Come vanno gli affari? Chiedetelo al vostro cruscotto
Shaku Atre

Organizzare team di progetto efficienti in ambienti DW/BI
Larissa Moss

Big Data, come e perché
Colin White

Business Capabilities e l'allineamento del business all'IT
Mike Rosen

Il valore della tassonomia nella ricerca delle informazioni
Zach Wahl

BI, ma il Data Warehouse è ancora necessario?
Colin White

Reinventare la Business Intelligence
Barry Devlin

Il cruscotto delle prestazioni: il nuovo volto della Business Intelligence
Shaku Atre

Modelli e processi di User acceptance testing
Randy Rice

I limiti nel gestire l'IT come un Business
Chris Potts

Le componenti fondamentali del Cloud
George Reese

Metadati e DW 2.0
Derek Strauss

BI Open Source: basso costo e alto valore?
Jos van Dongen

Semplicità e requisiti
Suzanne Robertson

Business intelligence e analisi testuale
Bill Inmon

Extreme Scoping™: approcci agili al DW e alla BI
Larissa Moss

Dalla BI a un'architettura IT di livello Enterprise
Barry Devlin

Ambiente efficiente di ricerca di informazioni
James Hobart

Il Business deve trainare la Strategia IT
Chris Potts

Web database: la questione MapReduce (seconda parte)
Colin White

Web database: la questione MapReduce
Colin White

Misura delle prestazioni. I sette comandamenti
Harry Chapman

Le dieci cose che un architetto deve fare per creare valore
Mike Rosen

Sviluppare applicazioni a prova di sicurezza
Ken van Wyk

The ECM Landscape in 2008
Alan Pelz-Sharpe

Ma chi sono gli operatori dell’informazione?
Colin White

Qualità dell’informazione e trasformazione del management
Larry English

Classificazione sistematica delle informazioni
Zach Wahl

L’uso intensivo del Web nelle applicazioni di Bi
Colin White

Enterprise Search
Theresa Regli

La forza dell'astrazione
Steve Hoberman

La strada verso una BI pervasiva
Cindi Howson

Soa, una strategia di test
Randy Rice

Verso una BI più semplice e a minor costo
Colin White

I contenuti “Killer” del Web
Gerry McGovern

Sviluppo iterativo del software per i Dw
Larissa Moss

Qualità delle Informazioni e Datawarehousing
Larry English

Lo scenario Ecm 2008
Alan Pelz-Sharpe

La nascita del Web 3.0
John Kneiling

Documentazione: il dossier del crimine
Suzanne Robertson

L’impatto del Web 2.0 sui portali delle imprese
Colin White

Le tecniche vincenti di IT Management
Ken Rau

Web 2.0
Ed Yourdon

Web di successo se si conosce il cliente
Gerry McGovern

Un approccio alla BI incentrato sui processi
Colin White

Integrare Master Data Management e BI (Parte Seconda)
Mike Ferguson

Integrare Master Data Management e BI (Parte Prima)
Mike Ferguson

Il Project Manager è una Tata
Suzanne Robertson

Web di successo se si conosce il cliente
Gerry McGovern

L'informazione personalizzata
Colin White

La Tassonomia dell'Impresa
Zach Wahl

Managed Meta Data Environment (II parte)
David Marco

Managed Meta Data Environment
David Marco

Migliorare le applicazioni dell'impresa con Web 2.0
James Hobart

La Balanced Scorecard migliora la Performance dell'IT
Harry Chapman

La fusione dei processi dell'impresa grazie a Soa (II parte)
Max Dolgicer

La fusione dei processi dell'impresa grazie a SOA (I parte)
Max Dolgicer

Volere è Potere, in Ogni Senso
Suzanne Robertson

Dimostrate con i numeri il valore dei contenuti del web
Gerry McGovern

Il Back-end della pianificazione strategica dell'It
Ken Rau

L'audit delle prescrizioni di progetto (II parte)
Suzanne Robertson

L'audit delle prescrizioni di progetto (I parte)
Suzanne Robertson

Il Processo di gestione delle informazioni
Ted Lewis

I requisiti come strumento di gestione dei progetti
Suzanne Robertson

Il futuro è nel contenuto killer del web
Gerry McGovern

Alla ricerca del valore tra i pomodori nell'orto
John Favaro

Rilevare i costi sulla base delle attività
Ken Rau

Un percorso verso l'impresa intelligente (II parte)
Mike Ferguson

Un percorso verso l'impresa intelligente (I parte)
Mike Ferguson

Il Data Store Operativo: un lavoro di martello
Claudia Imhoff

Il data warehouse orientato all'impresa
Michael Schmitz

Dieci punti chiave per realizzare balanced scorecard di successo
Harry Chapman

Content management: i contenuti al primo posto
Gerry McGovern

Applicazioni Web ad alta disponibilità
John Kneiling

Il 2004, sarà l'anno in cui abbandoneremo html?
James Hobart

La tecnologia EII ripropone il data warehousing virtuale?
Colin White

Misurare per Gestire
Ken Rau

Volere è Potere, in Ogni Senso
Suzanne Robertson

Realizzare il CPM e l'integrazione della BI
Mike Ferguson

Tutti i punti della FPA
Koni Thompson

Requiem per il Portale?
Colin White

Business Intelligence: dalla teoria alla realtà (II parte)
Shaku Atre

Business Intelligence: dalla teoria alla realtà (I parte)
Shaku Atre

I portali Corporate e di E-business: la nuova generazione del posto di lavoro
Mike Ferguson

I 10 errori da evitare nella realizzazione di un Meta Data Repository (II Parte)
David Marco

I 10 errori da evitare nella realizzazione di un Meta Data Repository (I parte)
David Marco

Usare i modelli per acquisire l'esperienza di progettazione
James Hobart

Realizzare l'Impresa Intelligente
Colin White

.NET or J2EE - Choosing the Right Web Services Framework
John Kneiling

Progettare Applicazioni Mobili di Successo
James Hobart

La Sociologia del Progetto: Identificare e Coinvolgere tutti i Partecipanti
Suzanne Robertson

Integrare la Business Intelligence nell'Impresa (II parte)
Mike Ferguson

Integrare la Business Intelligence nell'Impresa (I parte)
Mike Ferguson

L'Evoluzione del Portale di e-Business (II parte)
Colin White

L'Evoluzione del Portale di e-Business (I parte)
Colin White

Il Consulente WebEAI: Servizi Web, XML e l'Impresa
John Kneiling

Data Mining: Come Gestire le Relazioni con i Clienti Secondo i Principi del CRM
Herbert Edelstein

Articoli del mese - Technology Transfer