In che modo le storie utente non possono contenere requisiti (se scritti su una carta) ed essere comunque implementabili

Mi è stato detto "Le storie degli utenti non sono requisiti, è solo un promemoria di ciò che il cliente desidera, non è possibile inserire i requisiti all'interno di una storia". Ma facciamo un esempio del fatto che un cliente desidera una diversa elaborazione per diverse carte di credito. Esistono requisiti rigorosi che devono essere implementati e conosciuti in modo che i casi di test possano essere scritti. Dove dovrebbero andare i requisiti se non nella user story?

Come possono svilupparsi gli sviluppatori da una storia se non ci sono requisiti inferiori? In che modo i tester possono scrivere casi di test (dettagliati) basati su una user story? Dove requisiti quali vincoli DB, validazione dei campi ecc. Vivono al di fuori della user story?

Questa risposta si concentrerà su come lavorare con User Story e requisiti di livello inferiore. Non parlerò delle virtù, o della loro mancanza, di Scrum o Agile. Non parlerò nemmeno dei guru.

Questa risposta presuppone che tu sia a bordo con Scrum ma non hai ancora trovato il modo di farlo funzionare per te.

Come altri hanno già detto, le User Story hanno lo scopo di coprire come gli utenti vorrebbero che il software fosse. Poiché agli Utenti non interessano elementi di implementazione di basso livello come tabelle di database, vincoli, schemi architettonici, ecc., Non troverai tali dettagli in una User Story.

Tuttavia, ciò non significa che questi dettagli non dovrebbero essere registrati da nessuna parte.

Quando gli sviluppatori implementano le storie degli utenti, devono essere consapevoli dei dettagli di livello inferiore che gli utenti non sanno. Queste informazioni possono provenire da PMI, BA, proprietario del prodotto, architetto o qualsiasi altro esperto o persona tecnicamente competente.

Questo significa che i dettagli di basso livello dovrebbero essere registrati nelle User Story? No (e sì).

A un certo punto tra il momento in cui la storia viene creata e realizzata, qualcuno dovrà capire come implementarla. Questo di solito assume la forma di conversazioni con le persone coinvolte nella storia (utente, architetto, sviluppatore, ecc.). Queste conversazioni dovrebbero comportare criteri di accettazione inequivocabili che delineano chiaramente la portata dell'implementazione della User Story. Questi dettagli dovranno essere registrati da qualche parte e dove questo dipende davvero da te. La chiave qui è che questi dettagli vengono richiesti dopo la creazione della User Story. Penso che questo sia ciò che il tuo guru sta cercando di enfatizzare.

Come sviluppatore è chiaro che avrai bisogno di un modo per associare requisiti più specifici alla tua User Story. Il modo in cui lo fai dipende interamente dalla tua squadra.

Se le persone del tuo team vogliono mantenere questi dettagli fuori dalle User Story, potrebbe essere necessario rispettarlo. Ci sono vantaggi nel mantenere le storie utente di alto livello libere dai dettagli di implementazione. Li mantiene snelli e il tuo backlog può essere letto come una cronologia di ciò che gli utenti e il proprietario del prodotto desideravano. Fai conoscere anche le tue esigenze come sviluppatore. Dovresti essere in grado di trovare un compromesso in cui il semplice collegamento alla User Story rende tutti felici.

Sì, è BS. E Scrum non è agile.

Odio la rigidità dei cosiddetti praticanti agili che ti teletrasportano che esiste un modo di fare agile e che devi seguire tutte le regole stabilite nelle sacre scritture di qualunque metodologia "agile" che usano. È tutto BS.

Agile significa essere agili.

Agile significa fare le cose con un minimo di spese generali. Questo non significa "nessuna documentazione" poiché di solito si finisce per documentare di più in un ruolo agile, si procede semplicemente con la documentazione senza dover pianificare un processo per fare la documentazione. Allo stesso modo con la codifica, i test e l'acquisizione dei requisiti. Le uniche cose che contano in un processo agile sono quelle che ti aiutano a svolgere il tuo lavoro, in modo rapido ed efficiente, senza alcun BS.

Quindi, in questo caso, se mettere i requisiti dell'utente nelle carte ti aiuta a scrivere, testare, documentare e dimostrare il codice necessario ... metti i requisiti sulla carta e comunica ai guru che il team ha sempre ragione.

Cosa pensa il resto del tuo team di sviluppo? In una vera metodologia agile, se tutti pensano che i requisiti debbano essere scritti in anticipo senza "conversazioni da parte degli utenti", allora dovrebbe essere quello, fai quello che il team pensa funziona meglio per loro di fare il loro lavoro. Se il team pensa che le conversazioni degli utenti siano una buona cosa, ascoltale e capisci perché lo pensano e portati nel loro modo di lavorare.

Basta non chiamarlo User Story e tutti saranno felici.

Penso che la risposta sia, puoi scriverlo dove vuoi.

In generale, implementazioni specifiche non sono incluse nella user story per alcuni motivi:

1. Sai cosa vuole il cliente, ma non sai come verrà implementato.
2. Il cliente è consapevole che sono coinvolti requisiti più specifici, ma in realtà non gli interessa e / o li capisce comunque.
3. Tutti pensano di essere pienamente consapevoli delle implementazioni specifiche in questo momento, ma nessuno vuole scriverle perché nella loro esperienza, tutto cambierà comunque e nessuno vorrà riscriverlo.

Non ci sono regole che omettono documenti aggiuntivi quando necessario. Forse il cliente ha bisogno di accedervi e forse no. Se speri di generare una sorta di contratto tra te e il cliente sull'implementazione specifica come se tu potessi seguirlo e quando non funziona incolpare il cliente per averlo accettato, ti sbagli. Se il cliente comprende i dettagli tecnici dell'elaborazione della carta di credito, è necessario condividere questi documenti con loro ed eventualmente renderli parte della conversazione.

Penso che se ciò che i tuoi consulenti Scrum ti stanno dicendo è che Scrum non richiede requisiti, allora hai dei consulenti molto poveri. Hanno anche torto a dirti che una user story non è in realtà un requisito, ma è solo un tipo di requisito.

Quali sono i diversi tipi di requisiti software?

Requisiti aziendali

Si tratta in genere di un'esigenza aziendale di alto livello, qualcosa che generalmente equivarrebbe a una sorta di dichiarazione di stile esecutivo su un sistema. È volutamente di alto livello e ampio e di per sé non può essere implementato senza molti più dettagli.

Requisiti dell'utente

Questi sono i requisiti di User Story che conosci. In genere possono adattarsi a una nota adesiva.

• Attore: in genere un utente o un stakeholder.
• Necessità: alcuni elementi o funzionalità generali richiesti dall'utente
• Motivo: la ragione o il contesto alla base dell'esistenza di questa esigenza
• Criteri di accettazione - Questo è il framework per i test di accettazione degli utenti e durante la demo di Sprint come il Product Owner sarà in grado di decidere se una user story è accettata o meno.

Requisiti funzionali o di sistema

Questo sembra essere il pezzo mancante nel tuo puzzle. Spinto dai requisiti a livello di utente, un requisito funzionale definisce gli attori a livello di sistema e le proprietà di un sistema, nonché i comportamenti e le funzioni di un sistema. Questo potrebbe anche essere fatto in un formato storia e incluso nel tuo backlog. Questi elementi dovrebbero essere autonomi e possono essere implementati indipendentemente da qualsiasi requisito dell'utente.

• Attore: un sistema o un componente di qualche tipo.
• Necessità: necessità o proprietà o dichiarazione di comportamento di un sistema che dovrebbe esistere.
• Motivo: un contesto dietro al perché questo è necessario nel sistema
• Criteri di accettazione: scenari, comportamenti, funzioni e flussi necessari per comunicare come eseguire i test di sistema e integrazione. Quando questi tipi di test vengono superati per il requisito, sappiamo che questo requisito funzionale è stato completato. Questi possono esistere nella documentazione esterna delle storie degli utenti, ma devono essere completati prima che tali storie vengano assegnate in uno sprint.

I requisiti funzionali definiscono la tua soluzione che suona come quella che stai descrivendo come il divario nel tuo processo.

Notevoli tipi di requisiti che devono essere menzionati ma che non hanno importanza per la tua domanda: Requisiti non funzionali, Requisiti tecnici, ecc ...

Una User Story è un tipo specifico di artefatto con l'obiettivo di descrivere l'interfaccia che l'utente si aspetta dal sistema ed è per questo che i dettagli di basso livello semplicemente non vi appartengono. Se li metti lì, stai cambiando l'intento del manufatto e non si adatta più alla definizione di un USA.

Utilizzare altre forme di specifica per acquisire requisiti di livello inferiore e decisioni di progettazione. Quello che dovrebbero essere esattamente questi altri moduli è qualcosa che deve essere risolto nella tua organizzazione e personalizzato per il tuo ambiente specifico.

La tua domanda sembra molto simile a qualcosa del genere

Ho questo CarFactory e ho bisogno che anche lui faccia biciclette, ma il nostro "Guru" OOD dice che non mi è permesso farlo. Cos'è questo BS!?!

Rispetta la separazione delle preoccupazioni e la coesione dei tuoi artefatti, sia quelli nel tuo codice che quelli nei tuoi processi.

Penso che lo scopo di questo approccio non sia quello di limitare le storie degli utenti, ma di prevenire cattivi requisiti.

Nella mia esperienza, gli utenti sono generalmente incapaci di scrivere requisiti. Gli sviluppatori sono generalmente incapaci di scrivere requisiti. Diamine, ammettiamolo subito: i requisiti sono difficili da scrivere!

Penso che sarebbe valido per un utente scrivere qualcosa nel gergo dei requisiti come parte di una storia d'uso. Tuttavia, farlo non dovrebbe automaticamente renderlo un requisito. Avere due storie d'uso contrastanti è un problema minore; avere due requisiti contrastanti è un grosso problema di rottura del contratto. Non ha senso promuoverlo l'uno con l'altro prima del tempo.

Penso che il punto di vista draconiano derivi da un riconoscimento della natura umana. Se le persone iniziano a pensare alle storie degli utenti come a un luogo in cui porre requisiti, inizieranno a farlo. Il vero vantaggio di usare storie rispetto ad altri mezzi per raccogliere requisiti come le informazioni è che sono scritte nelle parole e nella notazione naturali dell'utente. Ciò rende più probabile che gli sviluppatori pensino dal punto di vista del cliente. In un mondo perfetto, anche il gergo dei requisiti del freddo potrebbe andare lì. In realtà, queste parole tendono a far sì che gli sviluppatori si attacchino ai requisiti di facile comprensione e manchino le espressioni e le sfumature sottili che lo sviluppo agile vuole scoprire usando le storie d'uso.

Prendi le tue decisioni

La risposta a "Quindi, in che modo gli sviluppatori possono mai sviluppare una storia se non ci sono requisiti inferiori?" è molto semplice: i requisiti dettagliati che sono ortogonali alle esigenze dell'utente finale (ad es. vincoli DB, convalida dei campi, ecc.) non contano in realtà per l'utente. Se le esigenze dell'utente possono essere soddisfatte da validazioni di campi molto diversi, strutture DB molto diverse o forse addirittura nessun DB tradizionale, sarebbe controproducente che gli utenti inventassero tali informazioni con una particolare implementazione in mente, che potrebbe essere molto diverso da come il sistema è implementato alla fine.

Sei sviluppatori professionisti, quindi prendi decisioni professionali al meglio delle tue capacità sui dettagli di implementazione. Un utente che desidera un tavolo può dire a un falegname che tipo di legno vorrebbe, ma ci si aspetta che il falegname decida quanto devono essere spesse le gambe del tavolo per gestire carichi ragionevoli. Se mancano alcune informazioni per prendere una decisione significativa, è necessario discuterne con l'utente, ma circa il 90% dei contenuti per un documento con requisiti dettagliati in realtà non ha bisogno di informazioni a parte le vaghe storie degli utenti buon senso e le migliori pratiche del settore .

Tutti questi dettagli non sono arbitrari - ci sono scelte sbagliate e scelte migliori, e dovrebbero essere documentate poiché influenzano altre parti dell'implementazione, ma alla fine sono ancora dettagli di implementazione che possono e dovrebbero essere decisi dal team di implementazione secondo alle esigenze e alle migliori pratiche degli utenti.

Un'analogia di un'auto standard: se un cliente desidera che l'automobile sia dipinta di rosso, un chiarimento appropriato per la storia dell'utente sarebbe quello di chiedere quale tonalità di rosso sarebbe migliore, ma non la composizione chimica della vernice; tuttavia ci si aspetterebbe che non scegliessero di dipingere la macchina con acquerelli che si sarebbero lavati via sotto la pioggia, dato che è meglio non farlo.

TL; DR

Le storie degli utenti servono a documentare quale valore dovrebbe essere aggiunto al prodotto e perché. I dettagli dell'implementazione (ad es. Come il valore deve essere aggiunto, testato, misurato o validato) sono vincolati dalla trama, ma non sono contenuti al loro interno. Vengono deliberatamente lasciati come artefatti separati per mantenere flessibilità e agilità all'interno della struttura.

Le specifiche e i dettagli di implementazione sono spesso catturati in altri artefatti come gli script e gli scenari di accettazione-Test Driven Development (ATDD), Test-Driven Development (TDD) e Behavior-Driven Development (BDD). Questi particolari artefatti non sono obbligati dal framework Scrum, ma ti daranno sicuramente un buon punto di partenza se non hai già in atto altri controlli di processo efficaci.

Le storie degli utenti non sono specifiche

Il poster originale (OP) ha posto la seguente domanda :

[A] il cliente desidera un trattamento diverso per le diverse carte di credito, ci sono requisiti rigorosi che devono essere implementati e conosciuti in modo che i casi di test possano essere scritti ... DOVE DOVREI INSERIRLO SE NON NELLA STORIA?

Una user story è una funzionalità che offre valore , fornisce un contesto per guidare le conversazioni sull'implementazione e un punto di vista legato a un consumatore di valore che trarrà vantaggio dal valore fornito dalla funzionalità.

Il punto centrale di una user story è che i dettagli di implementazione non sono prescrittivi. Il team è libero di implementare la funzionalità in qualsiasi modo che offra il valore identificato al consumatore di valore nel contesto appropriato.

Un esempio lavorato

Una storia utente di esempio

Questo è più facile da spiegare se inizi con un insieme meno ambiguo di storie utente. Dato che l'OP non ha fornito una user story fruibile che segue il mnemonico INVEST , ne inventerò uno a titolo di esempio. Considera la seguente storia:

Come utente che preferisce pagare con la carta Discover,
vorrei avere la possibilità di effettuare i miei acquisti con la carta Discover in
modo da non essere limitato a Visa, Mastercard o American Express.

Ciò fornisce una funzionalità concreta, fornisce un contesto che può guidare le decisioni di implementazione che il team deve prendere e identifica il consumatore di valore come cliente proprietario di Discover-card. Non è un insieme di specifiche, ma è ciò di cui hai bisogno per avere le giuste conversazioni con il cliente e con il team su come implementare al meglio la storia durante un'iterazione di sviluppo.

Analisi e implementazione

L'implementazione effettiva dipende dal team. Il team dovrà fare alcune analisi per determinare:

• Il modo più semplice per implementare una nuova funzionalità.
• Quale delle varie opzioni di implementazione sarà più semplice da supportare in futuro, senza accumulare debiti tecnici.
• Come applicare i principi open-closed e YAGNI per garantire che la tua nuova funzionalità sia robusta senza essere troppo ingegnerizzata.

Uno dei principi fondamentali del Manifesto Agile è la collaborazione con i clienti. Un team interfunzionale e auto-organizzato dovrebbe essere in grado di collaborare con il cliente per elaborare i dettagli di implementazione all'interno delle linee guida fornite dalla user story.

Se le storie dei tuoi utenti non sono scritte bene, o se il team non ha le competenze o la maturità dei processi per fare le analisi appena sufficienti richieste dal loro agile framework, questo ovviamente sarà molto più difficile di quanto debba essere. Sono stati scritti interi libri sull'argomento di come creare buone storie utente al giusto livello di granularità; purtroppo non esiste un proiettile d'argento, ma è un'abilità apprendibile per i team agili.

Progettazione guidata dai test e basata sul comportamento

Il modo migliore per garantire che l'analisi sia valida e che l'implementazione sia sia sana che sostenibile è attraverso l'uso delle pratiche TDD e BDD. Ad esempio, vista la storia sopra, il team dovrebbe catturare l'implementazione pianificata attraverso artefatti come:

• Funzionalità del cetriolo con scenari verificabili.

  Questo è molto utile per guidare lo sviluppo di test di accettazione e per documentare le aspettative degli utenti sul comportamento dell'applicazione. Ad esempio, la user story dovrebbe avere una o più funzionalità di Cucumber correlate che descrivono come l'utente è in grado di effettuare il checkout con una scheda Discover e quale aspetto ha tale processo per l'utente.

• Test RSpec che convalidano il comportamento (non i dettagli di implementazione interna) delle nuove funzionalità del codice.

  Ciò è molto utile per documentare e convalidare il comportamento previsto della funzionalità all'interno dell'applicazione. Ad esempio, la user story guiderà la creazione di test unitari e di integrazione che assicurano che l'utilizzo di una carta Discover richiami qualsiasi comportamento specifico della carta richiesto dall'applicazione per autorizzare una vendita attraverso il gateway di pagamento.

Gli strumenti specifici non contano. Se non ti piace Cucumber o RSpec, usa gli strumenti o le metodologie che funzionano meglio per il tuo team. Tuttavia, il punto è che i dettagli di implementazione sono basati sulla user story , ma non sono prescritti da essa . Invece, l'implementazione (o le specifiche, se si preferisce) sono dettagli da elaborare durante lo sviluppo della funzionalità in modo collaborativo.

Molte buone risposte qui. Spero di poter aggiungere un valore con un altro ...

Penso che uno dei problemi che il tuo team potrebbe avere sia la migrazione da una metodologia non Agile.

Di solito si tratta di una metodologia a cascata e, in pratica, che di solito comporta il tentativo di documentare tutti i requisiti tecnici prima che venga scritta una riga di codice.

Ma non sempre funziona. Spesso non funziona. La ragione? Perché i requisiti raramente si allineano con la realtà. Le cose cambiano. Da qui il passaggio verso Agile.

Con Agile, la User Story è tutto ciò a cui l'utente tiene. Vogliono ottenere dal punto A al punto B. Come arrivare in termini di implementazione è nelle tue mani. Se stai aspettando che qualcuno ti dica i requisiti tecnici, non è davvero Agile. Se hai domande, chiedi. Se hai bisogno di documentazione, documento, ma non vuoi che il cliente prenda tutte queste decisioni per te. Possono avere opinioni, ma in un ambiente Agile tali opinioni dovrebbero essere (come suggerisce il tuo guru) in una conversazione.

Può sembrare che questo sia un peso per la tua squadra, ma consideralo un lusso. La tua squadra ora ha molto da dire nella soluzione, il che non era necessariamente il caso del modello a cascata.