Story

Le storie agiscono come un “linguaggio pidgin”, in cui entrambe le parti (utenti e sviluppatori) possono concordare abbastanza per lavorare insieme in modo efficace.

—Bill Wake, co-inventore di Extreme Programming

Le storie sono brevi descrizioni di un piccolo pezzo di funzionalità desiderata, scritto nella lingua dell’utente. I team agili implementano piccole sezioni verticali di funzionalità di sistema e sono dimensionate in modo che possano essere completate in un’unica iterazione.,

Le storie sono l’artefatto principale utilizzato per definire il comportamento del sistema in Agile. Sono brevi e semplici descrizioni di funzionalità solitamente raccontate dal punto di vista dell’utente e scritte nella loro lingua. Ognuno è destinato a consentire l’implementazione di una piccola fetta verticale del comportamento del sistema che supporta lo sviluppo incrementale.

Le storie forniscono informazioni sufficienti sia per le aziende che per i tecnici per comprendere l’intento. I dettagli vengono posticipati fino a quando la storia è pronta per essere implementata., Attraverso criteri di accettazione e test di accettazione, le storie diventano più specifiche, contribuendo a garantire la qualità del sistema.

Le storie degli utenti forniscono funzionalità direttamente all’utente finale. Le storie di Enabler offrono visibilità agli elementi di lavoro necessari per supportare l’esplorazione, l’architettura, l’infrastruttura e la conformità.

Il modello dei requisiti di SAFe descrive una gerarchia a quattro livelli di artefatti che delineano il comportamento del sistema funzionale: Epic, Capability, Feature e story. Collettivamente, descrivono tutto il lavoro per creare il comportamento previsto della soluzione., Ma il lavoro di implementazione dettagliato è descritto attraverso storie, che costituiscono il Backlog del team. La maggior parte delle storie emergono dalle funzionalità di business e enabler nel Backlog del programma, ma altre provengono dal contesto locale del team.

Ogni storia è un piccolo comportamento indipendente che può essere implementato in modo incrementale e fornisce un certo valore all’utente o alla Soluzione. È una sezione verticale di funzionalità per garantire che ogni iterazione offra nuovo valore. Le storie sono piccole e devono essere completate in una singola iterazione (vedere la sezione storie di divisione).,

Spesso, le storie vengono prima scritte su una scheda o una nota adesiva. La natura fisica della carta crea una relazione tangibile tra il team, la storia e l’utente: aiuta a coinvolgere l’intero team nella scrittura della storia. Le note adesive offrono anche altri vantaggi: aiutano a visualizzare il lavoro e possono essere facilmente posizionate su una parete o un tavolo, riorganizzate in sequenza e persino spente quando necessario., Storie di permettere una migliore comprensione della portata e del progresso:

• “Wow, guarda a tutte queste storie, siamo in procinto di firmare per” (ambito di applicazione)
• “Guarda tutte le storie che abbiamo compiuto in questa iterazione” (progresso)

Mentre chiunque può scrivere storie, di approvarli in squadra di portafoglio e di accettarli nella base di sistema sono a carico del Proprietario del Prodotto. Naturalmente, gli stickies non si adattano bene in tutta l’azienda, quindi le storie spesso si spostano rapidamente negli strumenti di gestione del ciclo di vita agile (ALM).,

Ci sono due tipi di storie in SAFe, storie utente e storie enabler, come descritto di seguito.

Fonti di storie

Le storie sono tipicamente guidate dalla suddivisione delle funzionalità di business e enabler, come illustrato nella Figura 1.

Storie utente

Le storie utente sono il mezzo principale per esprimere le funzionalità necessarie. Sostituiscono in gran parte le tradizionali specifiche dei requisiti., (In alcuni casi, tuttavia, servono a spiegare e sviluppare il comportamento del sistema che viene successivamente registrato per supportare la conformità, la tracciabilità o altre esigenze.)

Poiché si concentrano sull’utente come soggetto di interesse, e non sul sistema, le storie degli utenti sono incentrate sul valore. Per supportare questo, la forma di espressione consigliata è la forma user-voice, come segue:

Come (ruolo utente), voglio (attività), in modo che (valore aziendale)

Usando questo formato, i team sono guidati a capire chi sta usando il sistema, cosa stanno facendo con esso e perché lo stanno facendo., L’applicazione del formato “voce utente” tende abitualmente ad aumentare la competenza del dominio del team; arrivano a comprendere meglio le reali esigenze aziendali del loro utente. Figura 2 fornisce un esempio.

‘Personas’ descrivono caratteristiche specifiche degli utenti rappresentativi che aiutano i team a comprendere meglio il loro utente finale. Esempio personas per il pilota in Figura 2 potrebbe essere un brivido cercatore ‘Jane ‘e un pilota timido ‘Bob’., Le descrizioni delle storie fanno quindi riferimento a questi personaggi (Come Jane I want…).

Mentre la voce user story è il caso comune, non tutti i sistemi interagiscono con un utente finale. A volte l ‘”utente” è un dispositivo (ad esempio, stampante) o un sistema (ad esempio, transaction server). In questi casi, la storia può assumere la forma illustrata nella Figura 3.

Enabler Stories

I team potrebbero dover sviluppare l’architettura o l’infrastruttura per implementare alcune user story o supportare i componenti del sistema. In questo caso, la storia non può toccare direttamente qualsiasi utente finale. Queste sono storie abilitanti e supportano l’esplorazione, l’architettura o l’infrastruttura. Le storie di Enabler possono essere espresse in un linguaggio tecnico piuttosto che incentrato sull’utente, come illustrato nella Figura 4.

Ci sono molti altri tipi di Enabler storie, tra cui:

• Refactoring e Picchi (come tradizionalmente definito in XP)
• la Costruzione o il miglioramento di sviluppo di un’infrastruttura di distribuzione
• Esecuzione di lavori che richiedono l’interazione umana (ad esempio, l’indice di 1 milione di pagine web)
• Creazione del prodotto richiesto o configurazioni di componenti per scopi diversi
• Verifica del sistema di qualità (ad es.,, performance and vulnerability testing)

Le storie abilitanti sono dimostrate proprio come le storie degli utenti, in genere mostrando le conoscenze acquisite, gli artefatti prodotti o l’interfaccia utente, lo stub o il mock-up.

Scrivere buone storie

Le buone storie richiedono più prospettive. In agile, l’intero team – Product Owner, sviluppatori e tester – crea una comprensione condivisa di cosa costruire per ridurre le rielaborazioni e aumentare il throughput. I team collaborano utilizzando il Behavior-Driven Development (BDD) per definire test di accettazione dettagliati che descrivono in modo definitivo ogni storia., Buone storie richiedono più punti di vista:

• i Proprietari di Prodotti garantisce al cliente il pensiero per la vitalità e la desiderabilità
• agli Sviluppatori di fornire fattibilità tecnica
• Tester di fornire un ampio pensare che per le eccezioni, i casi limite, e altri modi inaspettati utenti possono interagire con il sistema

Collaborativo storia scritta assicura che tutte le prospettive sono affrontati e tutti sono d’accordo sulla storia del comportamento con i risultati rappresentati nella storia, descrizione, criteri di accettazione e prove di accettazione., I test di accettazione sono scritti utilizzando il linguaggio di dominio del sistema con Behavior-Driven Development (BDD). I test BDD vengono quindi automatizzati e eseguiti continuamente per mantenere la qualità integrata. I test BDD sono scritti in base ai requisiti di sistema (storie) e quindi possono essere utilizzati come dichiarazione definitiva per il comportamento del sistema, sostituendo le specifiche basate su documenti.,

Il 3Cs: Card, Conversation, Confirmation

Ron Jeffries, uno degli inventori di XP, è accreditato con la descrizione del 3CS di una storia:

• Card – Cattura la dichiarazione di intenti della storia utente utilizzando una scheda indice, una nota adesiva o uno strumento. Le schede indice forniscono una relazione fisica tra la squadra e la storia. La dimensione della carta limita fisicamente la lunghezza della storia e suggerimenti prematuri per la specificità del comportamento del sistema., Le carte aiutano anche la squadra a “sentire” la portata imminente, poiché c’è qualcosa di materialmente diverso nel tenere dieci carte in mano rispetto a guardare dieci linee su un foglio di calcolo.
• Conversazione-Rappresenta una “promessa per una conversazione” sulla storia tra il team, il cliente (o il proxy del cliente), il PO (che potrebbe rappresentare il cliente) e altre parti interessate. La discussione è necessaria per determinare il comportamento più dettagliato necessario per implementare l’intento., La conversazione può generare ulteriori specificità sotto forma di criteri di accettazione (la conferma di seguito) o allegati alla storia utente. La conversazione copre tutte le fasi del ciclo di vita della storia:
  • Perfezionamento del backlog
  • Pianificazione
  • Implementazione
  • Demo

Queste discussioni just-in-time creano una comprensione condivisa dell’ambito che la documentazione formale non può fornire. Le specifiche per esempio sostituiscono la documentazione dettagliata. Le conversazioni aiutano anche a scoprire le lacune in scenari utente e NFRS.,

• Conferma – I criteri di accettazione forniscono le informazioni necessarie per garantire che la storia sia implementata correttamente e copre le pertinenti funzioni e NFRS. Figura 5 fornisce un esempio. Alcune squadre usano spesso la sezione di conferma della scheda storia per scrivere ciò che dimostreranno.

I team agili automatizzano i test di accettazione laddove possibile, spesso in un linguaggio leggibile per le aziende e specifico del dominio., L’automazione crea una specifica eseguibile per convalidare e verificare la soluzione. L’automazione offre anche la possibilità di testare rapidamente il sistema, migliorando l’integrazione continua, il refactoring e la manutenzione.,>Investire in Buone Storie

INVESTIRE Il modello, sviluppato da Bill Wake , descrive le caratteristiche di un buon storie utente:

• I – Indipendente (tra le altre storie)
• N – Ccnl (flessibile dichiarazione di intenti, e non un contratto)
• V – Utili (fornendo un prezioso fetta verticale per il cliente)
• E – Stimabile (piccole e ccnl)
• S – Piccola (si inserisce all’interno di un’iterazione)
• T – Test (compreso abbastanza per sapere come eseguire il test)

la Stima Storie

Agile team utilizzano storia dei punti e ‘la stima del poker per il valore del loro lavoro ., Un punto storia è un numero singolare che rappresenta una combinazione di qualità:

• Volume-Quanto c’è?
• Complessità: quanto è difficile?
• Conoscenza-Cosa si sa?
• Incertezza-Cosa è sconosciuto?

I punti storia sono relativi, senza connessione con alcuna unità di misura specifica. La dimensione (sforzo) di ogni storia è stimata rispetto alla storia più piccola, a cui viene assegnata una dimensione di ‘uno.’Una sequenza di Fibonacci modificata(1, 2, 3, 5, 8, 13, 20, 40, 100) viene applicato che riflette l’incertezza intrinseca nella stima, soprattutto grandi numeri (e.,g., 20, 40, 100).

Stima del poker

I team agili usano spesso ‘stima del poker’, che combina opinione di esperti, analogia e disaggregazione per creare stime rapide ma affidabili. La disaggregazione si riferisce alla suddivisione di una storia o di caratteristiche in pezzi più piccoli e più facili da stimare.

(Si noti che ci sono anche un certo numero di altri metodi utilizzati.) Le regole di stima del poker sono:

• I partecipanti includono tutti i membri del team.
• Ogni stimatore riceve un mazzo di carte con 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, e,?
• Il PO partecipa ma non stima.,
• Lo Scrum Master partecipa ma non stima, a meno che non stia facendo un vero lavoro di sviluppo.
• Per ogni elemento backlog da stimare, il PO legge la descrizione della storia.
• Domande vengono poste e risposte.
• Ogni stimatore seleziona privatamente una carta di stima che rappresenta la sua stima.
• Tutte le carte vengono girate contemporaneamente per evitare pregiudizi e rendere visibili tutte le stime.
• Stimatori alti e bassi spiegano le loro stime.
• Dopo una discussione, ogni stimatore rivaluta selezionando una scheda.,
• Le stime probabilmente convergeranno. In caso contrario, il processo viene ripetuto.

Una certa quantità di discussione preliminare di progettazione è appropriata. Tuttavia, spendere troppo tempo nelle discussioni di progettazione è spesso uno sforzo sprecato. Il valore reale di stimare il poker è quello di raggiungere un accordo sulla portata di una storia. È anche divertente!

Velocity

La velocità del team per un’iterazione è uguale alla somma dei punti per tutte le storie completate che hanno soddisfatto la loro Definizione di DOD (Dod)., Man mano che il team lavora insieme nel tempo, la loro velocità media (punti storia completati per iterazione) diventa affidabile e prevedibile. La velocità prevedibile aiuta nella pianificazione e aiuta a limitare il Work in Process (WIP), poiché i team non affrontano più storie di quelle che la loro velocità storica consentirebbe. Questa misura viene anche utilizzata per stimare il tempo necessario per fornire epiche, funzionalità, funzionalità e abilitatori, che sono anche previsti utilizzando i punti storia.

Capacity

Capacity è la parte della velocità del team che è effettivamente disponibile per ogni data iterazione., Vacanze, formazione e altri eventi possono rendere i membri del team non disponibili a contribuire agli obiettivi di un’iterazione per una parte dell’iterazione. Ciò diminuisce la velocità potenziale massima per quella squadra per quell’iterazione. Ad esempio, un team con una media di 40 punti consegnati per iterazione regolerebbe la velocità massima fino a 36 se un membro del team è in vacanza per una settimana. Sapendo questo in anticipo, il team si impegna solo a un massimo di 36 punti storia durante la pianificazione iterazione., Ciò aiuta anche durante la pianificazione PI a prevedere la capacità effettiva disponibile per ogni iterazione nel PI in modo che il team non si impegni eccessivamente nella costruzione dei propri obiettivi PI.

Base di partenza per la stima

In Scrum standard, la stima del punto storia di ogni squadra—e la velocità risultante—è una preoccupazione locale e indipendente. In scala, diventa difficile prevedere la dimensione del punto della storia per epiche e funzionalità più grandi quando le velocità del team possono variare selvaggiamente., Per ovviare a ciò, i team sicuri calibrano inizialmente una linea di base del punto storia iniziale in cui un punto storia è definito più o meno lo stesso in tutti i team. Non è necessario ricalibrare la stima o la velocità del team. La calibrazione viene eseguita una volta quando si lanciano nuovi treni di rilascio Agili.

I punti storia normalizzati forniscono un metodo per arrivare a una base di partenza concordata per storie e velocità come segue:

• Dare a ogni sviluppatore-tester del team otto punti per un’iterazione di due settimane (un punto per ogni giornata lavorativa ideale, sottraendo 2 giorni per l’overhead generale).,
• Sottrarre un punto per ogni giorno di vacanza membro del team e vacanza.
• Trova una piccola storia che richiederebbe circa una mezza giornata per il codice e una mezza giornata per testare e convalidare. Chiamalo uno.’
• Stima ogni altra storia relativa a quella’.’

Esempio: Supponendo un team di sei persone composto da tre sviluppatori, due tester e un PO, senza vacanze o vacanze, quindi la velocità iniziale stimata = 5 × 8 punti = 40 punti / iterazione. (Nota: la regolazione un po ‘ più bassa può essere necessaria se uno degli sviluppatori e tester è anche lo Scrum Master.,)

In questo modo, i punti storia sono in qualche modo comparabili tra le squadre. La gestione può comprendere meglio il costo di un punto storia e determinare con maggiore precisione il costo di una caratteristica imminente o epica.

Mentre le squadre tenderanno ad aumentare la loro velocità nel tempo—e questa è una buona cosa— in realtà, il numero tende a rimanere stabile. La velocità di un team è molto più influenzata dal cambiamento delle dimensioni del team e del contesto tecnico che dalle variazioni di produttività.,

Dividere le storie

Le storie più piccole consentono un’implementazione più rapida e affidabile, poiché piccoli oggetti fluiscono attraverso qualsiasi sistema più velocemente, con minore variabilità e rischio ridotto. Pertanto, dividere le storie più grandi in quelle più piccole è un’abilità obbligatoria per ogni team Agile. È sia l’arte che la scienza dello sviluppo incrementale. Dieci modi per dividere le storie sono descritti in Requisiti software Agile di Leffingwell ., Un riassunto di queste tecniche segue:

• Fasi del flusso di lavoro
• Variazioni delle regole aziendali
• Sforzo maggiore
• Semplice/complesso
• Variazioni nei dati
• Metodi di immissione dei dati
• Qualità del sistema differite
• Operazioni (es., Create, Read, Update, Delete )
• Scenari di casi d’uso
• Break-out spike

La figura 6 illustra un esempio di suddivisione per scenari di casi d’uso.

Storie nel modello SAFe Requirements

Come descritto nell’articolo SAFe Requirements Model, il Framework applica un ampio set di artefatti e relazioni per gestire la definizione e il test di sistemi complessi in modo snello e agile. La figura 7 illustra il ruolo delle storie in questo quadro più ampio.

In scala, le storie sono spesso (ma non sempre) create da nuove funzionalità. E ogni storia ha test di accettazione e probabilmente test unitari. I test unitari servono principalmente a garantire che l’implementazione tecnica della storia sia corretta. Inoltre, questo è un punto di partenza fondamentale per l’automazione dei test, poiché i test unitari sono prontamente automatizzati, come descritto nell’articolo Test-Driven Development (TDD).

Per saperne di più

Leffingwell, Dean., Requisiti software agili: pratiche di requisiti snelli per team, programmi e aziende. Addison-Wesley, 2011. Cohn, Mike. Storie utente applicate: per lo sviluppo di software agile. Addison-Wesley, 2004.

Ultimo aggiornamento: 17 dicembre 2019