Criterios de aceptación: Difference between revisions
Jump to navigation
Jump to search
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== | ||