Criterios de aceptación: Difference between revisions

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.

Véase también

@@ 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==
+*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.
-Suelen presentarse en formato de lista o flujo, y 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.
+==Elementos==
+[[File:CriteriosDeAceptacion.png|thumb|right]]
+*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''.
+<blockquote><small>'''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.</small></blockquote>
+<blockquote><small>'''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.</small></blockquote>
 ==Véase también==
@@ Line 11: / Line 58: @@
 *[https://open.spotify.com/episode/0GjNQprSs7wbQ8s6G0lGXu?si=f6b4006adcd24e1f Scrum Manager Podcast | Episodio 6: Definition of Done].
 *[https://www.scrummanager.com/blog/2023/03/definition-of-done-o-definicion-de-hecho/ Scrum Manager Blog: Transcripción Scrum Manager Podcast | Episodio 6: Definition of Done].
+[[Category:Glosario de términos]]
+[[Category:Prácticas ágiles]]