Como sugiere el título: por ejemplo, ¿la siguiente historia de usuario es demasiado genérica?
"A registered user wants to login in order to use the site's services"
¿O debería usar historias de usuario más detalladas, como las siguientes?
1. "User insert email and password in the textboxes and click the login button";
2. "Server receives login data and check if they contain errors";
3. "Server puts the new user in the database if the login data are correct";
4. "The logged user is brought to his profile page".
Parece que cuanto más específico es, más entendemos la parte de los códigos requeridos (1) "cuadros de texto", 1) "botón de inicio de sesión", 3) "base de datos", ...).
¿Cuál es el camino correcto entre estos dos?
Las historias de usuario deben tener suficiente información básica como quién (tipo de usuario) quiere qué funcionalidad y por qué se necesita la funcionalidad. Además, cuál es su criterio de éxito para la historia. Se deben evitar los detalles en la historia del usuario, ya que se discutirán como parte de la reunión de planificación del sprint. es muy difícil lograr el equilibrio correcto, pero un experto en scrum realmente puede facilitar la discusión productiva. Como regla general, debe ser lo suficientemente específico para que la historia tenga buenas posibilidades de completarse en un scrum.
Dicho esto, el ejemplo que está dando arriba parece tener algunas tareas definidas y decididas por los miembros del equipo. Las historias de usuario generalmente deben provenir de propietarios de productos (PO)
Me encanta el formato Gherkin . Los detalles que describa serían escenarios, se pueden capturar más detalles en los pasos del escenario.
Feature: Some terse yet descriptive text of what is desired
As a ....
In order ...
I want ...
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: A different situation
...
En la filosofía Agile, como en Thoughtbot, los pasos de funciones al estilo Gherkin se escribirían en un proceso par/extremo entre el desarrollador, el analista comercial y SQA/SDET. Este proceso ocurriría en sesiones de preparación, antes de cualquier scrum diario. Los scrums diarios podrían realinear la historia, si salieran a la luz cosas nuevas, pero nunca la escribirían por completo.
El título de la característica se vería como su ejemplo #1. El escenario se describiría en las líneas del ejemplo n.º 2. Aunque, conceptos como "base de datos" probablemente no estén presentes, ya que son demasiado específicos para la implementación de un archivo de características. Dichos detalles de implementación se mantendrían en definiciones de pasos.
"Un usuario no autenticado ingresa el correo electrónico y la contraseña en el formulario de inicio de sesión y hace clic en el botón de inicio de sesión";
"El servidor recibe datos de inicio de sesión y comprueba si contienen errores";(Quitaría esto, ya que es una prueba que debería ocurrir en otro lugar, probablemente en una prueba unitaria)"El servicio de autenticación devuelve un token de autenticación y el usuario ahora es un usuario autenticado";
"El usuario usuario autenticado es llevado a la página de perfil del usuario".
Todd A. Jacobs
Todd A. Jacobs