Nel corso dei precedenti articoli ci siamo soffermati a definire con precisione i requisiti software in generale e poi quelli funzionali ricapitolando sia la notazione dei casi d’uso che quella delle User Story. È giunto quindi il momento di concentrarsi sul nocciolo della questione: similitudini e differenze tra i due approcci, fonte di continui dibattiti. In questo articolo esaminiamo differenze e analogie tra le due notazioni, e nel prossimo articolo effettueremo un’analisi dei loro contesti di utilizzo.
Introduzione
Nel corso del primo articolo [1] abbiamo investigato il complesso modello dei requisiti software e abbiamo visto che i requisiti funzionali sono una componente, molto importante, del modello, in particolare rappresentano i servizi, i compiti e le funzioni che il sistema deve implementare: catturano il comportamento richiesto al sistema software. Nell’articolo di Giovanni Puliti [2] è stata presentata una panoramica delle storie utente, mentre nel precedente articolo di questa serie [3], abbiamo presentato rapidamente la notazione dei casi d’uso.
Use Case vs. User Story
User Story e Use Case sono molto probabilmente le principali notazioni utilizzate per l’analisi dei requisiti funzionali, tanto che succede che a volte esse siano confuse tra loro; in realtà, nel corso degli anni, queste due notazioni hanno assunto ambiti d’azione ben definiti: le storie utente sono uno strumento core per processi più agili, mentre i casi d’uso tendono a essere utilizzati in ambienti più strutturati.
C’è un aspetto da mettere opportunamente in luce: le User Story non si fondano su una notazione formale ben definita; non esiste un metamodello e tanto meno un insieme di regole formali. Molta dell’evoluzione di tale approccio è il risultato delle opinioni di un gruppo di persone annoverate tra gli “evangelizzatori” del movimento agile. Pertanto parte di questo articolo si basa sull’attuale visione di alcuni tra i principali pensatori delle User Story.
Una User Story somiglia a uno scenario di un caso d’uso… ma anche a una gazzella
All’avvio di un nuovo progetto, il team di sviluppo, in senso esteso, si interroga in genere sull’approccio da utilizzare per analizzare i requisiti del software. L’inevitabile passo successivo consiste nel rinvigorire il sempre vivo dibattito tra le due principali notazioni: casi d’uso o storie utente? All’inevitabile richiesta da parte di alcuni membri del team sul rapporto tra le due visioni, la prima risposta che viene data sono frasi del tipo:
- “le storie utente stanno ai casi d’uso come gli oggetti stanno alle classi”
- “una user story è come un caso particolare, uno scenario dei un caso d’uso”
- “una storia utente è una versione più informale, amichevole e concisa di un caso d’uso… e non vi sono i diagrammi”
Si tratta di definizioni che alcuni anni fa venivano ritenute assolutamente accurate da molti autori.
La storia comincia alla fine degli anni Novanta
Ma procediamo con ordine… Kent Beck ha coniato il termine User Story [4] ufficializzandolo nel 1999. Gli aspetti essenziali sancivano che una storia utente è una breve e semplice descrizione di una caratteristica dal punto di vista della persona che ne ha bisogno, di solito un utente o un cliente del sistema. L’essenza è l’utilizzo dell’approccio User-Centric (“incentrato sull’utente”) durante l’analisi dei requisiti, che consiste nel focalizzare l’attenzione sulla caratteristica che l’utente vuole ricevere, e non su ciò che l’utente vuole che il sistema faccia.
Fin da questa frase si percepiscono le prime similitudini e differenze tra i due approcci: anche per i casi d’uso è fondamentale la definizione di una funzione spostando l’attenzione sulla prospettiva del fruitore, dell’attore; tuttavia il focus in questo caso è descrivere il comportamento atteso dal sistema e pertanto si parla di Use Case Driven.
Storie utente come versione semplificata dei casi d’uso
Qualche anno più tardi, 2007, Alistair Cockburn, mostra una visione che tende ad enfatizzare le similitudini [5]: “Pensate a una storia utente come a un caso d’uso a soli 2 bit di precisione. Il bit di precisione 1 dichiara l’obiettivo del caso d’uso, il bit 2 aggiunge lo scenario principale. Il bit 3 aggiunge le condizioni di errore, il bit 4 definisce le azioni di errore. Il bit 5 aggiunge la descrizione dei dati dei dati in/out”.
Questa definizione va nella direzione delle storie utente come versioni semplificate dei casi d’uso: in effetti i due bit di precisione definiscono esclusivamente l’obiettivo e lo scenario principale, trascurando scenari alternativi e di errore, garanzie, trigger, etc.
Notazioni differenti
Qualche anno più tardi, lo stesso autore fornisce una definizione più restrittiva in cui si incomincia a differenziare le notazioni. Infatti, intorno al 2008, Alistair Cockburn scrive nel proprio blog [5] “Una User Story è il titolo di uno scenario, mentre uno Use Case è il contenuto di molti scenari”.
Sempre sullo stesso blog, Cokburn si corregge sostenendo che la precedente definizione non era corretta dal momento che le “User Story possono descrivere anche strutture dati e aggiornamenti della UI che ovviamente non sono parte dei casi d’uso”.
Dalle gazzelle… agli ascensori
A questo punto arriva il colpo di scena con la definizione che le storie utente stanno ai casi d’usocome una gazzella sta a un gazebo… Il tutto ovviamente corredato da corrispondente immagine; e quando gli fanno notare che gazebo e gazzella hanno le prime quattro lettere in comune, accetta la proposta di sostituire la gazzella con un elefante e il gazebo con un ascensore…
Eliminando gli aspetti folkloristici, vedremo come si è giunti a questa conclusione, dopo aver ricapitolato gli elementi base delle User Story.
Gli elementi fondamentali delle User Story
Di seguito, diamo un’occhiata a quelli che sono percepiti come gli elementi fondamentali che denotano una storia utente.
Dimensione
Le storie utente devono essere brevi. Una persona dovrebbe dedicare a una specifica storia utente non più di uno/due giorni.
Struttura
Le best practices applicate alle storie utente suggeriscono di ricorrere ad un “template” del tipo:
User Story (Card)
As
I want to
so that
Vale a dire che sto creando una storia utente quando, in qualità di utente, desidero fare qualche cosa di specifico in maniera tale da ottenere un determinato servizio, un valore, un riscontro etc.
User Centric
Le storie utente devono specificare le esigenze dell’utente, di cosa ha bisogno, e non il modo in cui ottenere tale risultato, o quale tecnologie utilizzare o il comportamento atteso del sistema.
Gergo
In virtù del punto precedente, consegue che le storie utente devono essere specificate in un gergo comprensibile all’utente e più in generale agli stakeholder. Quindi si tratta di un gergo di dominio.
Utilizzo
Le storie utente non sono il requisito finito o pesudo-finito pronto per l’implementazione. Tutt’altro: sono il punto di partenza per la specifica che dovrebbe avvenire durante il meeting giornaliero tra il team di sviluppo e il Product Owner. Chiaramente ci si riferisce allo Scrum Meeting.
Scope
Non tutti i requisiti, o più precisamente, non tutti gli entry presenti nel backlog del prodotto sono il risultato di storie utente. Ciò significa che non tutte le implementazioni eseguite dal team di sviluppo sono il diretto risultato di esplicite richieste dell’utente.
Affinità e divergenze
Anche in questi pochi elementi è possibile ravvisare punti di contatto e spazi di totale distanza tra le due notazioni… Si tratta proprio degli argomenti che approfondiremo nel corso del prossimo articolo, dedicato all’analisi delle due diverse notazioni all’interno del loro contesto tipico di utilizzo.
Il punto di fondamentale di differenza tra i due approcci risiede indubbiamente nel focus principale su cui si concentrano. Mentre i casi d’uso permettono di definire il comportamentorichiesto dal sistema, e quindi si prestano a essere usati sia dall’architetto per definire l’architettura e sia dagli sviluppatori per implementare il relativo servizio, componente, e così via, le storie utente si limitano a documentare brevemente una necessità utente. Tale bisogno, rigorosamente di tipo business, viene poi dettagliato durante le diverse cerimonie Scrum, anche grazie all’utilizzo di altri strumenti come il Product Backlog con le relative operazioni di raffinamento.
Detto ciò, non dovrebbe essere peccato mortale se una storia, durante un meeting Scrum, è oggetto di un processo di definizione completo e rigoroso che magari si basi sull’utilizzo proprio della notazione UML dei casi d’uso (con soli 2 bit di precisione: si intende!). Tuttavia, l’approccio “classico” prevede un utilizzo nella sua forma originale di card corredata da un accordo abbastanza informale sull’implementazione. In entrambi i casi è il team che stabilisce l’approccio più consono alla specifica storia, alla cultura del team, alla relativa dislocazione geografica, etc.
Feature
Molti processi di sviluppo del software prendono il via a partire da una lista di feature, oltre che da una serie di incontri di natura manageriale e/o commerciale. Si tratta delle caratteristiche che gli utenti vorrebbero che il sistema, nuovo o da modificare, implementasse.
La lista delle feature è tipicamente specificata attraverso un immancabile foglio elettronico e include tutte le possibili tipologie di requisito software: funzionale, non funzionale, dati, vincoli, e così via. Le varie feature sono corredate da poche informazioni: un codice univoco, un nome ed una breve descrizione, come mostrato nei seguenti esempi.
FEAT-010
“Load Instrument Data”
The system needs to load instrument data on a daily basis from Bloomberg and maintaining it internally
FEAT-020
“Instrument Data Format”
Data format must be compatible with the principle market data sources
FEAT-100
“Web GUI”
The system must include a Web GUI. This must offer a sophisticated and highly interactive user experience especially for the report analysis and data drill-down investigation
FEAT-200
“Reporting performance”
The generation of the standard calculation report must be executed in few minutes
Si tratta di descrizioni molti brevi, focalizzate sulle necessità dell’utente, che non dovrebbero includere soluzioni tecniche, a meno di particolari necessità come per esempio il riutilizzo di un particolare sistema, framework aziendale, e così via.
Passi successivi
Come al solito, la lista di partenza viene rivista e filtrata attraverso tutta una serie di iterazioni ove criteri di natura tecnico-economico hanno il sopravvento. Una volta finalizzata la lista, questa viene passata al team di sviluppo (in senso esteso) il quale, nel caso si utilizzino processi più strutturati, procede a organizzarla nei vari modelli standard dei requisiti, come descritto nel primo articolo [1]:
- requisiti funzionali sono assegnati al modello dei casi d’uso;
- requisiti non funzionali confluiscono nel corrispondente documento/foglio elettronico;
- requisiti relativi ai dati confluiscono nel modello a oggetti;
- requisiti relativi alle interfacce utenti vanno nel relativo modello;
- e così via…
Figura 1 – Iniziale razionalizzazione della feature list.
Requisiti funzionali e casi d’uso
Per quanto attiene ai requisiti funzionali modellati attraverso la notazione dei casi d’uso, avviene che tipicamente una medesima feature “funzionale” dia luogo a diversi casi d’uso, sebbene in casi meno frequenti sia anche vero che un medesimo caso d’uso partecipi alla realizzazione di diverse feature. Pertanto la relazione generale tra feature e casi d’uso è molti-a-molti (figura 2).
Figura 2 – Tipica relazione many-to-many tra feature funzionali e casi d’uso.
User Story come Feature
Da quanto esposto nei paragrafi precedenti, sia in termini di processo sia in termini di caratteristiche intrinseche, è immediato riscontrare importanti similitudini tra le User Story e le Feature.
Per quanto attiene alle caratteristiche intrinseche, si tratta di descrizioni concise, corredate da poche informazioni aggiuntive, che dovrebbero specificare le esigenze dell’utente, senza specificare soluzioni tecnologiche e tantomeno il comportamento del sistema.
Per quanto invece riguarda il processo di sviluppo, si tratta di iniziali necessità dell’utente, di versioni embrionali che poi vengono dettagliate o durante le cerimonie Scrum, come da specifiche dei processi agili, o da un team di Business Analyst, come avviene nei processi più formali.
Conclusioni
In questo articolo ci siamo occupati di chiarire il rapporto tra storie utenti e casi d’uso. Si tratta di un argomento che all’apparenza può sembrare scontato; ma, indagando a fondo, ci si rende conto che non è privo di confusione, spesso dovuta anche all’evoluzione del concetto delle User Story. All’inizio si trattava di una versione ridotta dei casi d’uso: Goal and Main Scenario. Citando Alistair Cockburn si trattava della versione a soli 2 bit di precisione. Con il passare del tempo il concetto si è voluto fino ad arrivare alla similitudine coniata dallo stesso Cockburn il quale, con sfoggio di fantasia, afferma che le storie utente stanno agli Use Case come una gazzella sta ad un gazebo…
Spostando l’analisi alla lista delle feature, tipicamente prodotta per dar vita a un progetto, è possibile notare importanti similitudini con le User Story, sia in termini di caratteristiche intrinseche sia di uso nel contesto di un processo. In particolare, si tratta di descrizioni concise, corredate da poche informazioni aggiuntive, che dovrebbero specificare le esigenze dell’utente, senza specificare soluzioni tecnologiche nè tantomeno il comportamento del sistema. Il loro utilizzo prevede la definizione dei dettagli nelle fasi successive del processo.
Dopo aver posizionato correttamente User Story e Use Case, nel corso del prossimo articolo, pur con tutti i limiti del caso, investigheremo i loro aspetti qualitativi.
Riferimenti
[1] Luca Vetti Tagliati, “Use Case vs. User Story – I parte: I requisiti funzionali”, MokaByte 192, febbraio 2014
https://www.mokabyte.it/cms/article.run?articleId=UOP-DOQ-ESE-SHH_7f000001_10364476_11630062
[2] Giovanni Puliti, “Guida galattica per scrummers – V parte: Le storie utente. Concetti fondamentali”, MokaByte 192, febbraio 2014
https://www.mokabyte.it/cms/article.run?articleId=LOS-RCD-DS5-T5D_7f000001_10364476_1d974629
[3] Luca Vetti Tagliati, “Use Case vs. User Story – II parte: I casi d’uso”, MokaByte 194, aprile 2014
https://www.mokabyte.it/cms/article.run?articleId=K4J-734-VOV-UNS_7f000001_10073811_543808d0
[4] Kent Beck, “Extreme Programming Explained: Embrace Change”, Addison-Wesley, 1999
[5] Alistair Cockburn, “The new user story is a real story”
[6] Alistair Cockburn, “A user story is the title of one scenario whereas a use case is the contents of multiple scenarios”