La definición de hecho (DoD) es una lista de requisitos que una historia de usuario debe cumplir para que el equipo la llame completa. Mientras que los criterios de aceptación de una historia de usuario consisten en un conjunto de escenarios de prueba que deben cumplirse para confirmar que el software funciona como se espera.
la diferencia entre estos dos es que el DoD es común para todas las historias de usuario, mientras que el criterio de aceptación es aplicable a la historia de usuario específica., Los criterios de aceptación de cada historia de usuario serán diferentes en función de los requisitos de esa historia de usuario.
En otras palabras, tanto el DoD como los criterios de aceptación deben cumplirse para completar la historia del Usuario. El incremento del producto no se considera completo, a menos que se realicen ambas listas., Por lo tanto, necesitamos definir dos aspectos de la definición de hecho (DOD) — criterios de finalización y criterios de aceptación:
La definición de hecho se estructura como una lista de elementos, cada uno utilizado para validar una historia o PBI, que existe para garantizar que el equipo de desarrollo esté de acuerdo sobre la calidad del trabajo que está tratando de producir., Sirve como una lista de verificación que se utiliza para verificar la integridad de cada artículo de Backlog de productos (también conocido como PBI) o historia de usuario. Los elementos en la definición de «hecho» están destinados a ser aplicables a todos los elementos en el Backlog del producto, no solo a una sola historia de usuario.,el término implica que el incremento del producto se puede enviar
los objetivos de definición de hecho
- construir un entendimiento común dentro del equipo sobre la calidad y la integridad
- Utilizar como una lista de verificación que las historias de usuario (o PBIS) se comprueban contra
- asegúrese de que el incremento enviado al final del Sprint tenga alta calidad y que la calidad sea bien entendida por todos los involucrados.,
por ejemplo, en la industria del software, los equipos pueden necesitar hacer algunas de las siguientes preguntas para llegar a su departamento de Defensa:
- ¿Código Revisado por pares?
- Código completado?
- Código revisado?
- Code check-in?
- pruebas unitarias pasadas?
- pruebas Funcionales pasado?
- pruebas de aceptación completadas?
- Propietario del Producto revisado y aceptado?,
criterios de aceptación
Las historias de usuario son uno de los principales artefactos de desarrollo para el desarrollo ágil, pero Scrum no requiere explícitamente que se utilicen historias de usuario o criterios de aceptación., Si un elemento de backlog de producto se considera demasiado grande para ser puesto en un sprint, normalmente se desglosará en Historia de usuario y posteriormente en un conjunto de tareas como se muestra en la figura:
Las historias de usuario encapsulan los criterios de aceptación, por lo que a menudo vemos la definición de hecho y los criterios de aceptación coexistiendo en nuestro proceso de desarrollo de Scrum. La historia del Usuario proporciona el contexto de la funcionalidad que el equipo debe ofrecer., Los criterios de aceptación dan orientación sobre los detalles de dicha funcionalidad y cómo el cliente Los aceptará. Los dos juntos proporcionan todo el entregable.
algunos de los criterios de aceptación se descubrirán en los eventos de refinamiento de Backlog en curso antes de que comience el Sprint, y otros se descubrirán justo después de la planificación del Sprint cuando se siente para tener una conversación sobre la historia del usuario en un equipo pequeño. Por lo tanto, los criterios de aceptación son atributos que son únicos para la historia del usuario o el elemento de Backlog del producto.,los criterios e son diferentes para cada PBI/historia
los objetivos de los criterios de aceptación
- aclarar lo que el equipo debe construir antes de comenzar a trabajar
- Tiene una comprensión común del problema
- ayudar a los miembros del equipo a saber cuándo se ha completado la historia
- ayudar a verificar la historia a través de pruebas automatizadas.,
ejemplo — criterios de aceptación
- Un usuario no puede enviar un formulario sin completar todos los campos obligatorios
- La Información del formulario se almacena en la base de datos de Registros
- El pago se puede hacer a través de tarjeta de crédito
- Se envía un correo electrónico de acuse de recibo al usuario después de enviar el formulario
ejemplo de Historia de usuario con criterios de aceptación
de una historia de usuario.,
