Raccolta dei requisiti in una metodologia agile

5

Nel grande libro User Stories Applicate l'autore ha specificato il seguente processo per i requisiti di pesca a strascico nella forma di utente storie:

Crea ruoli utente (persone) - > confronta gli obiettivi utente per ciascun ruolo - > Scrivi storie utente - >
stima tutte le storie utente - > prioritizza le storie - > seleziona alcune storie utente per la prima versione - >
scrivi i criteri di accettazione per ogni storia - > dividi ogni storia in attività - > attività di stima

Tuttavia, non capisco perché le storie di ALL dovrebbero essere stimate per prime e se devono essere valutate perché lasciare i criteri di accettazione fuori dalla storia fino al momento di lavorarci sopra?

La prossima cosa riguarda i criteri di accettazione stessa, nei criteri di accettazione del libro in cui semplici affermazioni come:

  • test con Master Card per il pagamento.
  • prova con Visa per il pagamento.

Il formato Given ... When ... Then ... non è migliore per la scrittura dei test di accettazione?

L'ultima cosa è rompere le user story alle attività, perché preoccuparsi di rivalutare le attività quando l'attività stessa è stata stimata nel punto della storia?

    
posta Songo 23.04.2013 - 18:22
fonte

3 risposte

1

Penso che il punto della stima iniziale sia di mettere tutti d'accordo (ad alto livello) sull'ordine di complessità implicato nell'implementazione della Storia. Questo dovrebbe aiutare con la prioritizzazione di Story.

Quando il nostro team ha fatto il passaggio ad Agile c'è stato un sacco di discussioni su come scrivere AC.

Ciò che alla fine abbiamo concluso è che entrambi i formati "test con Master Card for payment" e "Given ... When ... Then ..." avevano i loro meriti. Il primo è ovviamente più facile da scrivere perché è in un linguaggio naturale. Quest'ultimo è più preciso perché stabilisce in modo esplicito i prerequisiti, le azioni e le aspettative.

Abbiamo scoperto che, per motivi di velocità, i CA erano inizialmente scritti in un linguaggio naturale. Se dopo questo c'è ancora un elemento di ambiguità, vengono tradotti nel formato formale. Inoltre, se un AC è destinato a essere codificato come test automatico, dovrebbe essere nel formato formale.

Per quanto riguarda la suddivisione delle storie in attività: abbiamo seguito questo consiglio per un po ', ma abbiamo riscontrato che era inutile.

    
risposta data 23.04.2013 - 18:46
fonte
1

Stimare accuratamente una storia è un lavoro (non molto, ma aggiunge). Una stima accurata non ha valore diretto per il cliente. Quindi stimare solo quanto (e con la precisione) di cui hai bisogno per la pianificazione.

A lungo termine, puoi farla franca con "piccola / media / grande". Fai quello. Prendersi il tempo di passare attraverso criteri di accettazione, test, tasking o spike per una stima accurata è una perdita di tempo se non si lavorerà alla trama per due mesi - nel momento in cui si rivisita la possibilità che la storia sia quel contenuto, contesto o la conoscenza è cambiata.

In uno sprint / iterazione, hai bisogno di stime abbastanza accurate. Tasking e dettaglio AC (in qualunque formato la squadra apprezzi di più) vale lo sforzo aggiuntivo.

Penso che l'idea di stimare la storia (stima lorda) e quindi il compito separatamente (stima a grana fine) ti guidi attraverso il processo di raffinazione delle stime quando ne hai bisogno.

Inoltre, 'Given ... When ... Then' ha dei meriti, così come 'As foo, voglio ...' e 'basta farlo funzionare, sappiamo tutti di cosa stiamo parlando' . Per me, non esiste un formato, dipende dalla trama e dal contesto.

    
risposta data 23.04.2013 - 20:35
fonte
0

Sono d'accordo con te sulla stima. Nella mia azienda, abbiamo un processo di requisiti molto formalizzato (dettato dal nostro cliente) e vengono generate molte storie di utenti. Gli analisti aziendali come me stanno scrivendo queste storie e, in molti casi, non disponiamo delle conoscenze tecniche per valutarle realisticamente. Per noi, la fase di stima si verifica dopo che un team di mischia ha deciso di raccogliere una storia dal backlog. A quel punto, teniamo una rapida sessione di pianificazione / grooming in cui i nostri leader tecnologici e noi BAs possiamo parlare delle storie su cui lavoreremo, e gli sviluppatori useranno "pianificazione del poker" o qualunque metodo abbia senso per una determinata mischia squadra per dare una storia una stima delle dimensioni. Faccio un punto (come un BA) per NON votare nel poker di pianificazione anche se sono incorporato in una squadra di mischia.

Sono anche d'accordo che gli AC dovrebbero essere parte della storia prima è stimata. È completamente possibile per uno sviluppatore guardare solo la dichiarazione di valore e non vedere completamente tutte le necessità logiche che ne derivano immediatamente e stimare in modo impreciso una storia. Per me, una storia non è "fatta" a meno che non siano stati definiti i criteri di accettazione. Per ovvie ragioni, sono anche estremamente attento se dovrò mai toccare AC per una storia "in volo" (già accettata da una squadra), perché è come scherzare con i pali della porta durante una partita di calcio. Se mai dovessi cambiare un AC, è d'accordo con lo sviluppatore che possiede quella storia e dopo aver attentamente valutato se creare o meno una nuova storia nel backlog (idealmente, dovremmo sempre farlo, ma non lo facciamo t vivere in un mondo da manuale ideale-agile).

Per quanto riguarda il miglior formato di scrittura a scopo di test, puoi andare in entrambi i modi. Trovo che il classico "Come una X, ho bisogno di Y, così che io possa Z" funzioni meglio perché è immediatamente comprensibile a qualsiasi membro del team o stakeholder che lo incontra. Se lo scrivi correttamente , dovrebbe essere sempre abbastanza facile derivare i casi di test. Molto spesso, mentre sto scrivendo una user story, mi trovo a pensare "come potrei testarlo?". Trovo anche molto istruttivo come un ragazzo dei requisiti per andare a trovare i nostri tester e scegliere il loro cervello ogni volta che posso. Si scopre che spesso hanno una visione diversa della nostra applicazione rispetto a una BA e "pensare come un tester" ci aiuta a chiudere il circuito logico quando scriviamo una buona user story.

Abbiamo recensioni tra pari di storie di utenti tra i BAs sul mio progetto, che ritengo sia una buona pratica, e finiamo per avere un modo abbastanza classico e standardizzato di scriverle. Questa è una buona cosa per un progetto grande come il nostro perché il nostro cliente (o chiunque) può passare attraverso le storie degli utenti e non deve cimentarsi con più tipi di formati di storie di utenti.

Per quanto riguarda le attività, questa è davvero una domanda specifica per l'organizzazione. Per noi, le attività sono più utili quando più sviluppatori finiscono per lavorare su una singola storia utente. Le attività ci aiutano a tenere traccia di ciò che ogni dev sta facendo. Il nostro Scrum Master come gli sviluppatori per rompere storie in compiti perché dà loro una visione più granulare di ciò che sta accadendo e li aiuta a stimare la velocità. Nel nostro progetto, monitoriamo anche le attività per ora, ma storie per punto. Penso che non sia al 100% agile-scrum "kosher", ma aiuta il team di gestione del progetto. In realtà, ciò che fai o non fai con le attività dipende molto da cosa stai cercando di tenere traccia di, da come lo vuoi fare e da come sei organizzato.

    
risposta data 16.12.2016 - 20:49
fonte