Le mie storie utente per principianti sono state composte correttamente?

I (come utente) sono sempre arrabbiati con le password - devono essere troppo lunghi, devono essere cambiati troppo spesso, devono essere troppo diversi (attraverso i sistemi), ecc. ecc. Quindi la mia user story vai come:

As a user, I want quick and hassle-free access to my system. 

Se hai utenti molto premurosi, preoccupati per la sicurezza e la tracciabilità, puoi aggiungere:

As a user, I want to be sure that nobody without permissions can fiddle with my data. 

Suppongo che sia il più lontano possibile dagli obiettivi degli utenti. Le password non supportano alcuna attività utente, supportano gli obiettivi di amministrazione del sistema e, pertanto, devono essere inserite solo nelle storie per il "proprietario del sistema", in cui sono già presenti.

Considera di non attenersi al modulo "I want" per questo tipo di requisiti, poiché, come vediamo dalle altre risposte, la differenza tra "ciò che l'utente vuole" e "ciò che il proprietario del sistema vuole come l'utente dovrebbe funzionare con il sistema "può essere una causa di equivoci. Le parti importanti di una user story sono le parti che descrivono "who", "when / where", "what" e "why", "I want" è solo un modello intercambiabile.

Ad esempio:

A user when starting to work with the system has to log in with her secure password, so that only she can access areas of the system she need to do her work.

Questa è formalmente una user story corretta, proprio come la tua. Se questa storia descrive correttamente le tue esigenze, o se si trova sul livello corretto di astrazione per il tuo caso, è una domanda diversa.

Ogni volta che leggo una User Story, la mia prima domanda è "Davvero?" Mi metto nei panni dell'Utente e chiedo "VOGLIO DAVVERO quella caratteristica". La sicurezza è una di quelle aree in cui le User Story sono spesso scritte dal punto di vista dell'utente di un sistema ma, come altri hanno sottolineato, non vogliono dover effettuare il login o creare password complesse. Vogliono solo arrivare alle loro cose e avere le loro cose protette.

Oltre a chiedere "Davvero?" domanda, guardo se la User Story richiede una soluzione particolare. La sicurezza è, ancora una volta, un grande esempio. La maggior parte delle User Story sembra insistere nel richiedere password. Ma perché? Mi piace scrivere User Story in modo tale da dare agli sviluppatori la possibilità di prendere in considerazione alternative. In questo modo, creiamo un ambiente che incoraggia l'innovazione. Una buona cosa.

Quindi, ecco cosa mi piacerebbe vedere:

Come nuovo membro Voglio creare un account rapidamente e facilmente In modo che io possa accedere ai vantaggi per i membri

o forse:

Come membro corrente Voglio che le mie informazioni personali siano mantenute private In modo che possa mantenere la mia privacy

Infine, se il modello "As a ... I want ... So ..." non ti sta aiutando, sentiti libero di usare qualcos'altro ma ti consiglierei di capire i motivi per cui (e "È troppo difficile" probabilmente non è la risposta migliore:)

Gli utenti non vogliono mai vogliono l'accesso limitato. Includerei la restrizione dell'accesso come proprietario del sistema (anche comunemente noto come "proprietario del prodotto"). A seconda della quantità di controllo dell'accesso richiesta, potresti anche voler specificare chi e cosa nelle singole storie, ad esempio:

As a system owner I want only managers to be able to create new employees. 

Evita di specificare soluzioni nelle tue storie come descrivere come sono definiti o recuperati i ruoli.

Non avrei storie che includano dettagli come i criteri di formato della password (convalida), questo dovrebbe essere un criterio di accettazione per una storia sulla registrazione di nuovi account.

I blocchi sembrano un buon candidato per una storia di proprietario del sistema.