Cosa c'è in una storia?

Questa è la traduzione italiana dell'articolo originale “WHAT’S IN A STORY?”, scritto e pubblicato da Dan North.

Contenuti

Lo "sviluppo guidato dal comportamento" (Behaviour-Driven Development - BDD) è una metodologia "fuori-dentro". Inizia dall'esterno identificando gli obiettivi aziendali, quindi approfondisce il set di funzionalità che raggiungeranno tali risultati. Ogni caratteristica viene catturata come una "storia", che definisce l'ambito della caratteristica stessa insieme ai suoi criteri di accettazione. Questo articolo introduce l'approccio BDD alla definizione e all'identificazione delle storie e ai loro criteri di accettazione.

Introduzione

Lo sviluppo software mira ad ottenere obiettivi aziendali. Sembrerebbe ovvio, ma spesso fattori politici o ambientali ci distraggono dal ricordarlo. A volte può sembrare che la consegna del software riguardi la produzione di rapporti ottimistici per mantenere felice il senior management, o semplicemente la creazione di "lavoro impegnativo" per mantenere le persone occupate, ma questo è un argomento per un altro articolo.

Di solito, gli obiettivi aziendali sono troppo ad alto livello per essere utilizzati allo scopo di scrivere direttamente software (da dove inizi a programmare quando il risultato è "risparmiare il 5% dei miei costi operativi"?), Quindi dobbiamo definire i requisiti a un livello intermedio per portare a termine il lavoro.

Lo sviluppo guidato dal comportamento (BDD) assume la posizione che puoi trasformare un'idea per un requisito in codice implementato, testato e pronto per la produzione in modo semplice ed efficace, purché il requisito sia sufficientemente specifico da consentire a tutti di sapere cosa sta succedendo. Per fare ciò, abbiamo bisogno di un modo per descrivere il requisito in modo tale che tutti - i manager, l'analista, lo sviluppatore e il tester - abbiano una comprensione comune dell'ambito del lavoro. Da questo punto di partenza possono raggiungere una definizione comune di "finito", e così noi possiamo sfuggire le trappole del "non è quello che ho chiesto" o "mi sono dimenticato di parlarti di quest'altra cosa".

Questo, quindi, è il ruolo di una Storia. Deve essere una descrizione di un requisito e del suo vantaggio aziendale, nonché una serie di criteri in base ai quali siamo tutti d'accordo sul significato di "finito" (definition of "done", in inglese). Questa è una definizione più rigorosa rispetto ad altre metodologie agili, dove è variamente descritta come una "promessa di una conversazione" o una "descrizione di una caratteristica". (Una storia BDD può descrivere altrettanto facilmente un requisito non funzionale, a condizione che il lavoro possa essere definito, stimato e concordato.)

La struttura di una storia

BDD fornisce una struttura per descrivere una storia. Questo non è obbligatorio - puoi usare un formato di storia diverso e continuare a fare BDD - ma lo presento qui perché è stato dimostrato che funziona su molti progetti di tutte le forme e dimensioni. Per lo meno, la tua storia dovrebbe contenere tutti gli elementi descritti nel modello.

Il modello della storia ha questo aspetto:

Titolo (una riga che descrive la storia)

Narrativa:
Come [ruolo]
Voglio [caratteristica]
In modo che [vantaggio]

Criteri di accettazione: (presentati come scenari)

Scenario 1: titolo
Dato [contesto]
  E [un po 'più di contesto] ...
Quando [evento]
Quindi [risultato]
  E [un altro risultato] ...

Scenario 2: ...

Raccontare la storia

Una storia dovrebbe essere il prodotto di una conversazione che coinvolge più persone. Un analista aziendale parla con uno stakeholder aziendale della caratteristica o del requisito e lo aiuta a inquadrarlo come una narrativa. Quindi un tester aiuta a definire l'ambito della storia - sotto forma di criteri di accettazione - determinando quali scenari sono importanti e quali sono meno utili. Un rappresentante tecnico fornirà una stima approssimativa della quantità di lavoro necessario a implementare la storia e proporrà approcci alternativi. Molte grandi idee legate ai sistemi provengono spesso sia dalle persone che li sviluppano, sia dalle persone che li hanno richiesti in primo luogo.

Questo sarà verosimilmente un processo iterativo. Lo stakeholder avrà un'idea di ciò che vuole, ma di solito non sa quanto lavoro sarà necessario o come verrà assegnato. Con l'aiuto degli esperti tecnici e dei tester, capiranno il rapporto costi / benefici di ogni scenario e potranno esprimere un giudizio sul fatto che lo vogliano implementato o meno. Ovviamente questo è anche pesato insieme gli altri requisiti: è meglio coprire più casi limite in questa storia o passare a un'altra storia?

A volte il team di sviluppo semplicemente non ne sa abbastanza per essere in grado di fare anche una stima approssimativa. In questo caso possono scegliere di svolgere un lavoro investigativo, noto come "spike", al fine di comprendere meglio il requisito. (Tratterò la pianificazione in modo più dettagliato in un prossimo articolo.)

Le caratteristiche di una buona storia

Utilizzando l'esempio dell'articolo Introducing BDD, diamo un'occhiata ai requisiti per prelevare contanti da un bancomat:

Storia: il titolare del conto ritira contanti

In qualità di titolare del conto
Voglio prelevare contanti da un bancomat
In modo da poter ottenere denaro quando la banca è chiusa

Scenario 1: l'account dispone di fondi sufficienti
Dato che il saldo del conto è \ € 100
 E la carta è valida
 E la macchina contiene abbastanza soldi
Quando il titolare del conto richiede \ € 20
Quindi il bancomat dovrebbe erogare \ € 20
 E il saldo del conto dovrebbe essere \ € 80
 E la carta dovrebbe essere restituita

Scenario 2: l'account non dispone di fondi sufficienti
Dato che il saldo del conto è \ € 10
 E la carta è valida
 E la macchina contiene abbastanza soldi
Quando il titolare del conto richiede \ € 20
Quindi il bancomat non dovrebbe erogare denaro
 E l'ATM dovrebbe dire che ci sono fondi insufficienti
 E il saldo del conto dovrebbe essere \ € 20
 E la carta dovrebbe essere restituita

Scenario 3: la carta è stata disabilitata
Dato che la carta è disabilitata
Quando il titolare del conto richiede \ € 20
Quindi il bancomat dovrebbe trattenere la carta
E il bancomat dovrebbe dire che la carta è stata trattenuta

Scenario 4: l'ATM non dispone di fondi sufficienti
...

Come è possibile vedere, ci sono una serie di scenari da considerare: alcuni relativi al saldo del conto, altri sulla carta e altri ancora sullo stesso bancomat. Analizziamo la storia per determinare se è utile.

Il titolo dovrebbe descrivere un'attività

Il titolo della storia, "Il titolare del conto ritira contanti", descrive un'attività che il titolare del conto desidera svolgere. Fino a quando non implementeremo questa funzione, il titolare del conto non sarà in grado di prelevare denaro dal bancomat. Una volta che avremo implementato e consegnato la storia, lo potrà fare. Questo ci fornisce un ovvio punto di partenza per determinare che aspetto abbia la definizione di "finito" in questo caso.

Se avessimo un titolo come "Gestione account" o "Comportamento bancomat", dovremmo cercare di capire meglio quando avremmo finito, e i bordi sarebbero molto più sfocati. Ad esempio, la "gestione dell'account" potrebbe includere la richiesta di un prestito e il "comportamento del bancomat" potrebbe comprendere la modifica del numero PIN sulla mia carta di credito.

Il titolo della storia dovrebbe sempre descrivere il comportamento effettivo di un utente del sistema.

La narrazione dovrebbe includere un "ruolo", una "caratteristica" e un "vantaggio"

Il modello Come [ruolo] voglio [caratteristica] in modo che [vantaggio] offre una serie di sbocchi positivi. Specificando il ruolo all'interno della narrazione, sai con chi parlare del film. Specificando il vantaggio, induci l'autore della storia a considerare il motivo per cui desidera una funzione.

Diventa particolarmente interessante se scopri che la funzione non offre effettivamente il vantaggio ad essa attribuito. Questo di solito significa che hai una storia mancante. C'è una storia con la funzionalità attuale, che offre un vantaggio diverso (ed è quindi ancora utile), ma c'è anche una storia nascosta in cui avrai bisogno di una caratteristica diversa per fornire il vantaggio descritto.

La storia di esempio ci dice che c'è un titolare dell'account che desidera la funzionalità che viene fornita, quindi sappiamo da dove iniziare a esplorare.

Il titolo dello scenario dovrebbe dire cosa c'è di diverso

Dovresti essere in grado di allineare gli scenari fianco a fianco e descrivere come differiscono usando solo il titolo. Nel nostro esempio, possiamo vedere che le descrizioni degli scenari dicono solo ciò che è diverso tra ogni scenario. Non è necessario dire "un titolare di un conto preleva denaro da un conto con fondi insufficienti e gli viene detto che non è in grado di completare la transazione". È ovvio dal titolo se questo è lo scenario che ti interessa, rispetto agli altri.

Lo scenario dovrebbe essere descritto in termini di "Assunzioni", "Eventi" e "Risultati"

Questo è il singolo cambiamento comportamentale più potente che ho visto nei team che adottano BDD. Semplicemente convincendo gli utenti aziendali, gli analisti, i tester e gli sviluppatori ad adottare questo vocabolario di "dato/quando/allora" (in inglese given / when / then), scoprono che un mondo di ambiguità svanisce.

Non tutti gli scenari sono così semplici. Alcuni sono rappresentati al meglio come una sequenza di eventi, descritti come: dato [un certo contesto] quando [faccio qualcosa] allora [questo accade] quando [faccio un'altra cosa] allora [succede questa nuova cosa] e così via. Un esempio è un sito Web in stile "procedura guidata", in cui si passa attraverso una sequenza di schermate per creare un modello di dati complesso. È perfettamente appropriato mescolare sequenze di eventi e risultati, purché si prenda l'abitudine di pensare in questi termini.

Un comportamento emergente interessante è che la qualità della conversazione cambia. Scoprirai rapidamente di aver perso un dato presunto ("beh, naturalmente il conto è scoperto"), o di aver dimenticato di verificare un risultato ("beh, naturalmente il titolare del conto recupera la sua carta"). L'ho osservato in un particolare progetto in cui lo sviluppatore principale mi ha detto che poteva percepire che analisti e sviluppatori stavano parlando incrociando i loro obiettivi, ma non riusciva a vedere un modo per dimostrarglielo. Entro pochi giorni dall'introduzione del vocabolario given / when / then, ha potuto vedere un notevole miglioramento nella qualità delle loro conversazioni.

I dati dovrebbero definire tutto e non più del contesto richiesto

Eventuali dati aggiuntivi sono fonte di distrazione, il che rende difficile per qualcuno che guarda la storia per la prima volta, sia dal punto di vista tecnico che da quello commerciale, capire ciò che deve sapere. Allo stesso modo, tutti i dati mancanti sono in realtà supposizioni. Se puoi ottenere un risultato diverso dai dati forniti, allora deve mancare qualcosa.

Nell'esempio, il primo scenario dice qualcosa sul saldo del conto, la carta e lo stesso bancomat. Tutti questi elementi sono necessari per definire completamente lo scenario. Nel terzo scenario non diciamo nulla sul saldo del conto o se il bancomat ha denaro. Ciò implica che la macchina tratterrà la carta qualunque sia il saldo del conto e qualunque sia lo stato del bancomat.

L'evento dovrebbe descrivere la funzionalità

L'evento stesso dovrebbe essere molto semplice, in genere solo una singola chiamata nel codice di produzione. Come discusso in precedenza, alcuni scenari sono più complicati, ma per lo più gli scenari di una storia ruotano attorno a un singolo evento. Differiranno solo nel contesto (i dati) e nei corrispondenti risultati attesi.

La storia dovrebbe essere abbastanza piccola da adattarsi a una singola iterazione

Non ci sono regole rigide e veloci su come eseguire questa operazione, a condizione che venga suddivisa in parti dimostrabili. In generale, se ci sono più di cinque o sei scenari, una storia può probabilmente essere scomposta raggruppando insieme scenari simili.

Non possiamo dire dall'esempio ATM quanti altri scenari ci siano per questa storia, ma sospetto che ce ne possano essere molti altri. Essenzialmente abbiamo tre "parti mobili" in questa storia, vale a dire il saldo del conto, lo stato della carta bancomat e lo stato del bancomat. Potremmo entrare più nel dettaglio con la carta bancomat: cosa succede se non è aggiornata, quindi non posso usarla per prelevare contanti ma il bancomat me la restituisce? Cosa succede se il bancomat si blocca durante la transazione? Cosa succede se il mio conto dispone di uno scoperto?

In questo caso potrebbe essere meglio suddividere la storia in diverse storie più piccole:

• Il titolare del conto ritira contanti (ipotesi: il bancomat funziona e la carta è valida)
• Il titolare del conto ritira contanti con carta non valida (ipotesi: il bancomat funziona)
• Il titolare del conto preleva contanti da un bancomat instabile (ipotesi: la carta è valida)

Sebbene possa sembrare artificiale, ti consente di dimostrare i progressi in termini di business e ti offre più punti dati con cui tracciare l'avanzamento. La cosa importante è sempre dividere la storia lungo le linee di business per scenari (e rendendo esplicite le ipotesi) piuttosto che lungo le linee tecniche (ad esempio, fare le cose del database in questa iterazione e le cose della GUI nella prossima iterazione). In questo modo l'azienda può osservare progressi dimostrabili secondo un linguaggio comprensibile piuttosto che limitarsi a crederci sulla parola.

In che modo questo è diverso dai "Casi d'Uso"?

Ci sono "casi d'uso" e ci sono "casi d'uso". Sono un grande fan del modo in cui Alistair Cockburn descrive i casi d'uso (al contrario delle versioni troppo ingegnerizzate che ho incontrato nei progetti RUP-as-waterfall). Dato che non ho molta esperienza su progetti basati sui casi d'uso, lascerò ad altri il compito di fare i confronti.

Certamente sono d'accordo con il suo suggerimento di partire con una precisione inferiore (di un risultato o di un obiettivo) e di lavorare verso precisioni più elevate, assumendo diverse opzioni alternative mentre si procede. In BDD, ciò significa iniziare con il risultato aziendale e lavorare attraverso aree funzionali di alto livello per approfondire storie specifiche tramite criteri di accettazione.

In realtà, non importa quale sia il tuo processo per identificare ed elaborare i requisiti. Va bene scrivere documenti sui requisiti se questo ti aiuta a organizzare i tuoi pensieri. Non va bene, tuttavia, passare quei documenti come se in realtà racchiudessero tutti i tuoi pensieri, perché non lo fanno. Invece, dovresti mettere da parte il documento dei requisiti, o la pila di casi d'uso, e ricominciare a definire le storie a partire dagli obiettivi aziendali, con la certezza che il tuo duro lavoro ha significato che hai tutte le risposte nella tua testa - o almeno una comprensione abbastanza buona per delineare il lavoro come lo vedi attualmente.

Sommario

Lo "sviluppo guidato dal comportamento" utilizza una storia come unità di base della funzionalità e quindi della consegna. I criteri di accettazione sono una parte intrinseca della storia - in effetti definiscono la portata del suo comportamento e ci danno una definizione condivisa di "finito". I criteri di accettazione sono anche usati come base per la stima quando dobbiamo fare la pianificazione.

Ancora più importante, le storie sono il risultato di conversazioni tra le parti interessate del progetto, gli analisti aziendali, i tester e gli sviluppatori. BDD si occupa tanto delle interazioni tra le varie persone del progetto quanto degli output del processo di sviluppo.