Agile 201 — Storie utente

Le User Story sono un modo conveniente per suddividere il software in parti e descriverlo. Sono utili per l'assegnazione delle priorità e le conversazioni con le parti interessate. Il termine "caratteristica" è spesso usato come sinonimo di User Story, ma è importante capire che le User Story non sono requisiti software dettagliati. Le User Story fungono da indicatori o titoli delle funzionalità del software e sono sempre scritte nella lingua dell'azienda. Sono utilizzati per fare riferimento a una particolare caratteristica o funzionalità del sistema software.

Formati delle storie utente

Esistono vari formati per scrivere le storie degli utenti. Il più comune è il formato "Come [utente], voglio [azione], in modo che [beneficio]" :

"Chi? Che cosa? Perché?" è un altro modo conveniente per scrivere User Story:

Le User Story sono composte da tre parti: l' Utente , l' Azione e l' Obiettivo .

Criteri di accettazione

Specificare i criteri di accettazione è una parte importante della creazione delle User Story. I criteri di accettazione specificano le condizioni che devono essere soddisfatte affinché la User Story sia considerata completa e implementata con successo. I criteri di accettazione vengono utilizzati per garantire che il team di sviluppo e le parti interessate abbiano una comprensione condivisa di ciò che comporta la User Story e di ciò che deve essere fornito. Forniscono inoltre un modo per verificare che la User Story sia stata completata e che la funzionalità che descrive funzioni come previsto.

I criteri di accettazione dovrebbero essere verificabili tramite un "test binario", rispondendo "sì" o "no" a una domanda se un criterio di accettazione è soddisfatto.

I criteri di accettazione possono anche essere opportunamente specificati nel formato utilizzato nel Behavior-driven Design. Il Behavior-driven Design (BDD) è una metodologia di sviluppo software focalizzata sulla definizione e sul test del comportamento dei sistemi software utilizzando descrizioni in linguaggio semplice del comportamento del sistema. BDD si basa sui principi di Test-Driven Development (TDD) e Domain-Driven Design (DDD) e si basa sull'idea che i sistemi software dovrebbero essere progettati e testati in base al loro comportamento, piuttosto che ai loro dettagli di implementazione.

Dividere le User Story

Decidere lungo quali linee suddividere le User Story può essere piuttosto impegnativo. Tuttavia ci sono buone pratiche utili da seguire, ad esempio Venti modi per dividere le User Story . Qualunque sia l'approccio scelto, è importante assicurarsi che ogni User Story sia ancora in grado di fornire valore all'utente finale. Suddividendo le User Story in parti più piccole e più gestibili, i team di sviluppo possono assicurarsi di poter dare priorità al lavoro in modo più efficace, riducendo i rischi e le dipendenze.

I criteri INVEST sono un utile acronimo che definisce le caratteristiche di una buona user story:

• I sta per Indipendente, il che significa che ogni storia utente dovrebbe essere autonoma e in grado di essere elaborata e testata in modo indipendente:
• N sta per Negoziabile, il che significa che le storie degli utenti non dovrebbero essere eccessivamente prescrittive, lasciando spazio alla discussione e diversi modi di implementare la storia per fornire il valore previsto all'utente.
• V sta per Valuable, il che significa che ogni storia utente dovrebbe fornire valore all'utente finale o al cliente.
• E sta per Estimable, il che significa che ogni user story dovrebbe poter essere stimata in termini di livello di sforzo o complessità.
• S sta per Small, il che significa che le storie degli utenti dovrebbero essere suddivise in piccoli pezzi gestibili.
• T sta per Testable, il che significa che ogni user story dovrebbe poter essere testata per assicurarsi che sia stata implementata correttamente.

Scrivere buone storie utente

Esaminiamo alcuni driver e limiti per scrivere buone User Story. La creazione di User Story è uno sforzo collaborativo tra il Product Owner, le parti interessate e il team di sviluppo. Avere una buona comunicazione, buoni rapporti di lavoro e una composizione del team diversificata aiuta a creare storie utente migliori. La diversa composizione del team aiuta a scrivere storie utente migliori poiché i membri del team possono fornire varie prospettive aggiuntive sulla creazione di valore per gli utenti.

La mancanza di allineamento, l'incapacità di stabilire le priorità degli obiettivi di business e la mancanza di tempo per il perfezionamento sono alcuni dei fattori che ostacolano la creazione di buone User Story. Il Product Manager deve investire abbastanza tempo nel perfezionare le User Story e assicurarsi che le parti interessate comprendano i vantaggi e le priorità delle User Story.

È importante che il Product Manager ricordi che le User Story sono uno strumento di conversazione, quindi è importante che tutti i partecipanti siano allineati sul contenuto delle storie, il che richiede tempo per essere realizzato.

In conclusione, le User Story sono un aspetto essenziale della metodologia di sviluppo del software Agile. È fondamentale seguire i criteri di investimento e scegliere un modello di suddivisione adeguato. La creazione di User Story è uno sforzo collaborativo e avere una buona comunicazione e una composizione diversificata del team può aiutare a creare User Story migliori. È inoltre essenziale investire abbastanza tempo per perfezionare le User Story e garantire che le parti interessate comprendano i loro vantaggi e le priorità.

Teamleadsky ha riassunto questo discorso in parte con GPT-3, il modello di generazione del linguaggio su larga scala di OpenAI.

Trova altri discorsi, articoli e strumenti Agile su Teamleadsky .