Criterios de aceptación: Difference between revisions
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Los '''criterios de aceptación''' definen qué requisitos mínimos debe cumplir una [[historia de usuario]] para determinar que ésta funciona adecuadamente. A diferencia de la [[definición de hecho]], los criterios de aceptación se centran en cada elemento de la [[pila del producto]] por separado. | Los '''criterios de aceptación''' definen qué requisitos mínimos debe cumplir una [[historia de usuario]] para determinar que ésta funciona adecuadamente. A diferencia de la [[definición de hecho]], los criterios de aceptación se centran en cada elemento de la [[pila del producto]] por separado. | ||
==Características== | ==Características== | ||
*Suelen presentarse en '''formato de lista o flujo'''. | *Suelen presentarse en '''formato de lista o flujo'''. | ||
| Line 8: | Line 8: | ||
==Elementos== | ==Elementos== | ||
[[File:CriteriosDeAceptacion.png|thumb|right]] | |||
*el '''número de escenario'''; | *el '''número de escenario'''; | ||
*el '''título''', donde se nombra el escenario que describe un comportamiento. Por ejemplo, “exploración de libros”; | *el '''título''', donde se nombra el escenario que describe un comportamiento. Por ejemplo, “exploración de libros”; | ||
| Line 13: | Line 14: | ||
*el '''evento''', es decir, la acción que el usuario ejecuta en el contexto definido para el escenario. Nos referimos a él usando «Cuando»; | *el '''evento''', es decir, la acción que el usuario ejecuta en el contexto definido para el escenario. Nos referimos a él usando «Cuando»; | ||
*y el '''resultado o comportamiento esperado''', que es el comportamiento del sistema en esa situación. Y que se expresa con «Entonces». | *y el '''resultado o comportamiento esperado''', que es el comportamiento del sistema en esa situación. Y que se expresa con «Entonces». | ||
==Cómo se redactan== | ==Cómo se redactan== | ||
Latest revision as of 14:59, 19 June 2024
Los criterios de aceptación definen qué requisitos mínimos debe cumplir una historia de usuario para determinar que ésta funciona adecuadamente. A diferencia de la definición de hecho, los criterios de aceptación se centran en cada elemento de la pila del producto por separado.
Características
- Suelen presentarse en formato de lista o flujo.
- Pueden escribirse en lenguaje natural, tal y como el product owner o el miembro del equipo que sugiera cada criterio se exprese. Lo importante es que ayuden a recordar de forma breve y clara la intención detrás de cada criterio.
- Aunque el product owner puede haber ido preparando estos criterios con antelación, se concretan en equipo durante la reunión de planificación del sprint. Ya que ayudan a entender lo que el cliente espera conseguir con ese incremento y con cada historia que forma parte de él.
- Es responsabilidad del propietario del producto asegurarse de que los criterios de aceptación cubren todos los aspectos necesarios para que el equipo estime y desarrolle las historias adecuadamente.
- Cuando llegue la revisión del sprint, el product owner comprobará si cada una de las historias de usuario se puede aceptar en función a los criterios que se definieron.
Elementos
- el número de escenario;
- el título, donde se nombra el escenario que describe un comportamiento. Por ejemplo, “exploración de libros”;
- el contexto, o sea las condiciones que desencadenan el escenario, y que se expresan con «Dado que»;
- el evento, es decir, la acción que el usuario ejecuta en el contexto definido para el escenario. Nos referimos a él usando «Cuando»;
- y el resultado o comportamiento esperado, que es el comportamiento del sistema en esa situación. Y que se expresa con «Entonces».
Cómo se redactan
Pueden escribirse tal como el propietario del producto se expresa, y pueden tener distintos formatos. El formato que empleemos dependerá de factores como las preferencias del equipo y el product owner.
Una manera popular de redactarlos es mediante BDD (Behavior Driven Development) y gherkin.
- BDD (Behavior Driven Development) es un enfoque de desarrollo de software que se centra en la comprensión de los comportamientos esperados de un sistema a través de la escritura de escenarios de usuario. Se basa en la colaboración entre desarrolladores, técnicos y stakeholders para definir claramente los requisitos y asegurarse de que el software cumpla con ellos.
- Gherkin es un lenguaje creado para las descripciones de comportamiento de software. Se utiliza en BDD para describir escenarios en un formato fácilmente legible y comprensible tanto para los desarrolladores como para los no técnicos.
Ejemplo
Historia de usuario: Como cliente, quiero tener la capacidad de realizar una búsqueda avanzada de productos en la tienda en línea para encontrar fácilmente lo que estoy buscando.
Escenario 1: Búsqueda por nombre de producto
Dado que un cliente ha accedido a la tienda en línea.
Cuando el cliente quiere buscar un producto por su nombre.
Entonces el cliente debería ver un campo de búsqueda en la página principal claramente visible.
Y el cliente debería poder ingresar el nombre del producto que busca en el campo de búsqueda.
Y al presionar "Buscar", el cliente debería ver una lista de productos que coincidan con el nombre proporcionado.
Y la lista de resultados debe mostrar al menos el título del producto, el precio y una imagen del producto.
Escenario 2: Búsqueda por categoría de producto
Dado que un cliente ha accedido a la tienda en línea.
Cuando el cliente quiere filtrar los productos por categoría.
Entonces el cliente debería poder seleccionar una categoría de una lista desplegable de categorías disponibles.
Y al seleccionar una categoría y hacer clic en "Buscar", el cliente debería ver una lista de productos que pertenecen a la categoría seleccionada.
Y la lista de resultados debe mostrar al menos el título del producto, el precio y una imagen del producto.