Criterios de aceptación: Difference between revisions
No edit summary |
No edit summary |
||
| 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. | |||
==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=== | |||
==Véase también== | ==Véase también== | ||
Revision as of 11:29, 18 December 2023
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.