Sì, la storia utente dice cosa vuoi ottenere, i compiti dicono come si fa a farlo accadere.

In questo caso, per esempio. Le attività potrebbero essere "aggiungi elemento al carrello pulsante UI", "controlla i livelli di stock", "ottieni account utente", "aggiorna il carrello temporaneo", "aggiorna l'elenco degli ultimi acquisti dell'account utente" ecc.

È possibile che alcuni di questi siano parte di una diversa user story, ma non mi preoccuperei troppo di attraversare ogni t e puntare ogni piccolo io, la cosa importante su cui concentrarsi con agile è farlo, non funziona la burocrazia.

Quando parliamo di una porzione verticale di funzionalità, stiamo parlando della user story solo .

I compiti sono suddivisi in tutto ciò che il team di sviluppo ritiene appropriato, per completare la storia.

Penso che tu stia pensando troppo. Diciamo che vengo da te e dico "per favore fammi un carrello della spesa per un sito web". Che cosa hai intenzione di? Ignora tutta la teoria, le parole d'ordine e il dogma, cosa farai quando ti siedi su una tastiera?

Le attività sono solo una lista delle cose che devi fare.

1. Scrivi test
2. visualizza la grafica per il pulsante "aggiungi al carrello"
3. ...

Dipende:)

Non conosco il contesto di questa storia, ma sul valore nominale mi sembra che l'unico compito qui sia add-item-to-cart. In una tipica applicazione di navigazione / shopping, questo sarebbe un pulsante AddToCart, con la logica del clic del pulsante appropriata, in cui l'identità dell'utente / carrello esiste già.

Se l'identità dell'utente e un carrello non possono essere assunti, ti suggerisco di non suddividerli come compiti in questa storia, ma invece di separarli come nuove storie .

Se si rivela solo la presenza e il comportamento del carrello (e / o identità dell'utente, se necessario) tramite una ripartizione dell'attività, si avrà perso un'opportunità per conversazioni molto più istruttive e preziose con gli utenti (cosa fa il carrello sembra? dove dovrebbe apparire? puoi rimuovere oggetti dal carrello? ecc.).

Non tendo a pensare a compiti come "fette". Sono le cose che devi fare per implementare una determinata user story, quindi sono spesso cose come modificare uno schema, aggiungere una nuova classe, aggiungere un nuovo metodo, aggiungere una pagina, stile la pagina ecc. Non lo faresti in genere hanno un compito per implementare l'intera funzionalità. Se hai intenzione di pensarli come sezioni verticali o orizzontali attraverso una user story, sono decisamente più orizzontali.

L'uso di una porzione verticale di una User story viene in genere utilizzato per suddividere una storia utente di grandi dimensioni in diverse più piccole se la tua squadra ne conclude che è troppo grande, ad es. se ottiene una stima di un numero infinito di punti storia nella pianificazione del poker.

Se questo fosse il caso del tuo esempio di carrello della spesa, con un po 'di licenza artistica, potrei suddividerlo nelle seguenti storie utente:

• In qualità di acquirente desidero un pulsante aggiungi al carrello su ogni pagina del prodotto in modo che possa fare clic per aggiungere il prodotto al mio carrello una volta implementata la funzionalità.
• Come acquirente desidero inserire la quantità che desidero aggiungere al mio carrello in modo da poter aggiungere più quella predefinita.
• In qualità di acquirente desidero aggiungere una quantità di articoli al mio carrello quando faccio clic sul pulsante per poter acquistare in seguito gli articoli.
• In qualità di acquirente desidero una schermata di conferma per dirmi cosa ho appena aggiunto al mio carrello in modo da poter correggere eventuali errori che ho commesso.

Si tratta di sezioni verticali attraverso tutti i livelli del sistema, ciascuno dei quali implementa l'archiviazione dei dati, la logica aziendale, l'interfaccia utente e tutto il resto necessario per un sistema funzionante, anche se non completo,

Questa è tuttavia l'eccezione, da utilizzare solo per gestire storie utente di dimensioni spiacevoli. In genere, la trama di un utente sarà di dimensioni gestibili e può essere suddivisa in attività per descrivere i passaggi da seguire per implementarla.

Secondo me dipende dal peso della storia dell'utente. Se la storia dell'utente riguarda solo l'aggiunta dell'articolo al carrello, la prima attività dovrebbe essere la progettazione di questo approccio.

Dopodiché devi suddividere le attività in base al modello (scenario di accesso, se non connesso, così via).

Supponendo che tu sia un proprietario del prodotto o un analista aziendale, non farlo. Le attività generalmente non sono create da OP o BA perché si concentrano su dettagli tecnici, non su requisiti.

Se ti trovi in un ruolo di sviluppo o di controllo della qualità, considera le attività come strumenti per il team di sviluppo per comprendere i passaggi di lavoro necessari per completare la storia dell'utente. Il compito formale può essere un buon modo per far sì che i team di sviluppo inizino a lavorare su una storia e superino la stima del punto iniziale.

A seconda del team, le attività potrebbero essere inesistenti in modo estremamente dettagliato nello strumento di monitoraggio Agile. È il processo di pensiero che conta. Generalmente vedrai e penserai a diverse categorie di attività, a seconda di quanto è gradita la tua squadra.

Attività di ricerca Compiti di implementazione Attività di qualità del codice Test delle attività

Se il tuo compito non ti aiuta a soddisfare i criteri di accettazione o la definizione del team di fatto, considera se dovrebbe davvero essere parte della storia.