Criteri di accettazione del backlog del prodotto

Mi piace utilizzare i criteri di accettazione, ma come menzionato da un altro utente, le storie dovrebbero essere negoziabili. Vediamo un esempio di come possiamo modificarlo per adattarlo meglio ad un ambiente agile:

" Mentre l'utente fa clic sul pulsante home, il sistema mostrerà 3 opzioni. "

Questo è troppo specifico per una storia, per quanto mi riguarda.

Tu (sorta) hai due opzioni.

Passa a qualcosa di più simile a " L'utente deve essere in grado di selezionare tra queste opzioni quando stanno effettuando l'accesso ... ". In questo modo non stiamo dettando direttamente l'implementazione. A seconda del contesto, è possibile che in questo modo sia ancora troppo specifico.

E anche in questo caso, questa potrebbe essere una storia a parte, a seconda del contesto: " Come utente, devo essere in grado di selezionare tra queste opzioni, in modo che ... "

Alla fine, questo dipende dalla tua squadra e dal loro aspetto. Parla con loro. Riportalo nella retrospettiva.

"Come utente, voglio poter creare nuovi utenti e assegnare autorizzazioni"

Vedo almeno due storie diverse in questa affermazione:

1. Come utente, voglio essere in grado di creare nuovi utenti (e le autorizzazioni predefinite sono assegnate a questi utenti)

2. Un utente può assegnare autorizzazioni ad altri utenti.

Piccole storie che aggiungono valore al prodotto rendono più semplice la definizione della storia e uno sviluppo più prevedibile. Per i criteri di accettazione di una storia, personalmente utilizzo gli scenari nella tipica forma "data-allora-poi" - per esempio, uno scenario per la prima storia:

Dato un utente che ha effettuato l'accesso al sistema (puoi usare "personas" invece di "un utente"),

quando l'utente inserisce il nome e la password del nuovo utente,

e invia la richiesta per creare un nuovo utente,

quindi il nuovo utente viene creato,

e questo nuovo utente può accedere al sistema.

Puoi avere altri scenari - ad esempio, uno in più per gestire nomi duplicati, un altro per password deboli - probabilmente dovresti anche implementare qualche tipo di captcha o roba simile di rilevamento umano ...

Se mischi la creazione dell'utente con l'assegnazione dei permessi, probabilmente avrai una storia molto grande. IMHO la parte più difficile della scrittura di buone storie di utenti non sta scrivendo i criteri di accettazione più accurati, sta imparando a definire storie davvero piccole che aggiungono valore al prodotto. Con storie tutte piccole, è più semplice e facile - l'ho imparato nel modo più duro ...

È un modo possibile, ma a rigor di termini non c'è bisogno di criteri di accettazione in quanto una storia dovrebbe essere negoziabile.

In altre parole, ciò che costituisce una corretta implementazione di una storia dovrebbe essere deciso mentre è in fase di sviluppo e non prima.

Detto questo, potrebbero esserci alcuni criteri di base che potresti aspettarti di vedere in una storia corretta, tenendo presente che le storie riguardano "obiettivi" e non "specifiche".

"Un utente può creare un altro utente" è un buon candidato. "Un utente può impostare le autorizzazioni per un utente che ha creato" è un altro buono. "Quando l'utente fa clic sul pulsante home, il sistema mostrerà 3 opzioni" non è un buon esempio di test di accettazione. Prescrive in anticipo un'interazione.

sì, questo è un approccio corretto e puoi aggiungere ulteriori informazioni, ad es. come parametri di prestazione, usabilità ecc.

in pratica dovrebbe essere chiaro agli sviluppatori cosa userete per accettare il lavoro che stanno facendo. Se non sei uno sviluppatore o non conosci il co-debase, allora dovrebbe essere utile se puoi utilizzare alcuni dei tuoi sviluppatori per il tempo di preparazione del backlog per capire quali sono i principali presupposti che faranno quando selezioneranno il PBI nella successiva iterazione. e quindi fai in modo che quei presupposti siano parte dei criteri di accettazione, ad es. supporteremo solo lettere inglesi ecc.