Qual è lo scopo della clausola 'so that' nella definizione della user story?


10

Una user story può essere definita in una frase come:

As a <type of user> I want <some goal> so that <some reason>

Solo Google per "formula storia utente" e i primi collegamenti propongono tutti questa formula.

La mia domanda è: qual è lo scopo di tale clausola? È lì per i manager? È possibile che i project manager e le parti interessate possano comprendere meglio la priorità dell'elemento? Perché è lì?

Nota: ho lavorato con la as a <type of user> I want <some goal>formula e funziona perfettamente. Non ho notato alcun problema nel mio lavoro implementando questo formato che è più breve.


6
Come utente SE, voglio un unicorno.
Piskvor lasciò l'edificio il

Risposte:


19

Lo scopo è quello di evitare il lavoro inutile costringendo l'utente / cliente a fornire un vantaggio commerciale solido e tangibile come motivo per l'esistenza di questa funzione.

Non è inaudito che le funzionalità vengano aggiunte solo perché qualcuno pensava che suonassero alla moda, o perché altri software ce l'hanno, quindi anche il nostro deve averlo. Più spesso, quelli sono almeno completamente inutili, se non addirittura attivamente dannosi.

Tuttavia, di solito è facile individuare tali funzionalità, poiché le persone che le propongono in genere avranno difficoltà a fornire loro una ragione commerciale convincente.

Esiste una tecnica chiamata Popping The Why Stack , in cui prendi la parte "so that" e chiedi "Why?", Quindi prendi quella risposta e chiedi "Why?" di nuovo, ricorsivamente. Se, dopo la (diciamo) 04:57 "Perché" s, non si è arrivati alle due "perché ci farà soldi" o "perché ci risparmia denaro" (preferibilmente con una descrizione precisa di esattamente come quella sta per succedere), quindi la funzionalità non vale la pena implementare.

Alcune persone credono che questo sia così importante da metterlo al primo posto nel modello della storia:

In modo da [...]

Come un [...]

Voglio [...]

C'è un grande esempio da un discorso di alcune persone di Thoughtworks: uno dei loro clienti voleva che i rapporti stampati fossero formattati in un modo molto particolare. Quando il consulente ha chiesto "Perché", hanno detto che in questo modo era più facile digitare nuovamente. Quindi, invece di implementare la funzionalità di formattazione dei rapporti, hanno appena trasferito i rapporti sulla rete. Senza la clausola "così", avrebbero comunque stampato i loro documenti in un dipartimento, spedendoli all'altro dipartimento e digitandoli di nuovo.


Quello che hai descritto si chiama Five Whys ( en.wikipedia.org/wiki/5_Whys ) ed è generalmente utile in campi di ingegneria (software), che vanno dall'ingegneria dei requisiti al controllo di qualità al miglioramento dei processi. È probabilmente una buona abilità da sviluppare.
Thomas Owens

Adoro la storia di ThoughtWorks. Ho scoperto che "So that" è molto utile nel fornire un contesto alla base della storia e nell'aiutare gli sviluppatori a fornire una soluzione migliore. Analisti / clienti spesso si restringono troppo velocemente su una soluzione; fornire agli sviluppatori il contesto consente loro di pensare e progettare una soluzione tecnica che gli analisti potrebbero non aver preso in considerazione o non ritenere possibile.
Mathias,

7

Il "così che" fornisce una ragione per l'obiettivo.

Ad esempio, l'obiettivo potrebbe essere quello di visualizzare i dati sulle vendite del mese scorso. Potresti lavorare con quello, ma uno dei motivi che devi sapere perché vuoi visualizzarli in modo da poter ottenere i requisiti più profondi. Cosa vogliono fare con i dati sulle vendite o le prospettive? Conoscere queste informazioni ti darà maggiori informazioni sull'applicazione e maggiori possibilità di progettare un'interfaccia utente che consenta al cliente di fare ciò che desidera.

Un altro uso del motivo è quello di dare priorità alle storie. Se hai due storie:

Voglio visualizzare i dati sulle vendite del mese scorso.
Voglio visualizzare un elenco di potenziali clienti.

ma hai solo le risorse per farlo - quale fai? Senza il motivo che avresti solo indovinato e potresti non consegnare quello giusto in tempo. Anche se questo è meno importante in quanto il cliente dovrebbe dirti quale fare prima, ma a volte non è così.


Non penso si tratti di dare priorità alle storie, ma piuttosto i requisiti più profondi. Le storie dovrebbero essere prioritarie dal cliente. Tuttavia, il "modo che" può essere utilizzato per ottenere requisiti aggiuntivi (attributi funzionali, non funzionali e di qualità) che aggiungeranno valore per l'utente. Il concetto di massimizzare il valore aggiunto è uno dei punti di forza di molti dei metodi agili, credo.
Thomas Owens

@Thomas - buon punto. Scambierò le ragioni - penso che la definizione delle priorità sia presente, ma non così importante.
ChrisF

1

Oltre a quanto detto, fornire un motivo per i requisiti consente di giudicare la validità del requisito. L'utente può desiderare cose per la ragione sbagliata. Avere il "così che" chiarisce il motivo consente quindi all'analista di confermare che la richiesta è soddisfatta al meglio in questo modo.

Esempio:

L'intelligenza artificiale desidera poter selezionare i dipendenti da un elenco di tutti i dipendenti dell'azienda

BI vuole essere in grado di selezionare dipendenti da un elenco di tutti i dipendenti dell'azienda in modo da poter eliminare quelli che hanno lasciato l'azienda 5 anni fa.

(B) non ha senso nemmeno in un'organizzazione di medie dimensioni, ma è possibile convalidare il requisito dell'utente e proporre un altro modo per soddisfare il requisito.


+1: aiuta ad arrivare alla radice del problema; altrimenti ti è stata appena data una potenziale soluzione.
JeffO,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.