No entiendo cual es la diferencia entre ambos. Parecen ser similares a mí. Por ejemplo, tengo esta típica historia de usuario de inicio de sesión/registro. ¿Puede proporcionar algunos ejemplos del Departamento de Defensa?
como usuario
Quiero registrarme e iniciar sesión
Para que pueda registrarme en la aplicación y comenzar a usar la memoria en la nube
Criterios de aceptación:
Debería poder acceder a la URL.
Debería poder ver y seleccionar el botón "Registrarse"
Debería ser redirigido al formulario "Registrarse"
Después de que el usuario envíe el formulario, se enviará un correo electrónico a su ID de correo electrónico registrado, este correo electrónico será la contraseña de la cuenta.
Esta contraseña se puede cambiar
Después de completar mi registro, podré seleccionar un paquete adecuado para mí.
También puedo registrarme a través de Facebook, Twitter, Google.
Los criterios de aceptación que ha enumerado son realmente una mezcla de historias y tareas.
Dada su historia de ejemplo:
Como usuario quiero registrarme e iniciar sesión para poder registrarme en la aplicación y comenzar a usar la memoria en la nube
Yo dividiría eso en:
Como usuario quiero registrarme para poder acceder y empezar a utilizar la memoria en la nube
y
Como usuario, quiero iniciar sesión para poder acceder de forma segura a mi cuenta de memoria en la nube
Varios de sus criterios de aceptación también son historias de usuarios. Por ejemplo:
Como usuario quiero poder cambiar mi contraseña para que mi cuenta sea más segura
y
Como usuario quiero poder registrarme a través de Facebook para poder registrarme de forma rápida y cómoda sin tener que volver a escribir todos mis datos
...etcétera.
Los criterios de aceptación son requisitos específicos de la historia que se deben cumplir para completar la historia. Son una técnica para agregar detalles funcionales a las historias de usuario. Los criterios de aceptación a menudo se agregan durante el refinamiento de la cartera de pedidos o durante la reunión de planificación del sprint.
Algunos ejemplos de criterios de aceptación:
No se debe permitir ninguna contraseña de más de 16 caracteres
El IVA debe incluirse en todas las cifras.
Estos criterios de aceptación agregan detalles a la historia del usuario y también brindan una guía conveniente para probar la integridad de la historia.
Como parte de una historia de usuario, puede definir algunas subtareas relacionadas con la implementación . Por ejemplo, como parte de la historia de usuario de registro, el equipo de desarrollo podría agregar una subtarea:
Agregue un botón "Registrarse" en el que los usuarios puedan hacer clic
y
Agregue una redirección HTTP para usuarios no registrados a la página de registro
Las tareas son utilizadas por el equipo técnico para ayudarlos a organizar el trabajo en la historia. Por lo general, las tareas no serían de interés para las personas no técnicas.
La definición de terminado es una lista de cosas que deben completarse para que cualquier historia se considere terminada.
La definición de hecho es acordada por el equipo antes de comenzar a trabajar. Cubre lo que el equipo siente que es necesario para considerar cualquier historia hecha.
Los ejemplos pueden ser:
Prueba de regresión completada
Documentación del usuario actualizada para reflejar la nueva historia
Visto y aprobado por el propietario del producto
Punto de referencia de prueba de rendimiento alcanzado
Arquitectura actualizada
Revisado por pares
Los criterios de aceptación consisten en verificar que la nueva característica funcione según lo esperado por las partes interesadas. Son mejor llamados Business Facing Tests .
Una prueba orientada al negocio es una prueba que está destinada a usarse como una ayuda para comunicarse con los miembros no programadores de un equipo de desarrollo, como clientes, usuarios, analistas comerciales y similares.
La definición de hecho es para ver si la función está lista para implementarse en producción y solo para los miembros del equipo de programación. La definición podría incluir que la función tiene pruebas, se actualiza la documentación, se escriben notas de lanzamiento, se limpia el control de versiones y cualquier cosa que su equipo necesite hacer para poder lanzar esta función. Algunos también lo llaman DoneDone como realmente hecho.
Ejemplo de definición de hecho de la terapia de choque de Scrum :
Mi definición inicial de "Terminado" es esta:
- Característica completa
- Código completo
- Sin defectos conocidos
- Aprobado por el propietario del producto
- Listo para producción
También eche un vistazo a la definición de ready , que se usa para verificar si las historias de usuario están listas para ser recogidas por el equipo de desarrollo. Debe incluir que los criterios de aceptación han sido escritos.
Esta es una excelente pregunta y es algo que he visto que es confuso para muchos equipos y propietarios de productos.
La forma más fácil de recordar la diferencia es simplemente hacerse esta pregunta:
¿Esta historia es específica o todas las historias deben hacer esto antes de que se consideren terminadas?
Si la respuesta es que es una historia específica, entonces es un criterio de aceptación para la historia.
Si la respuesta es que, en general, todas las historias deben hacer esto antes de que se consideren terminadas, entonces es un candidato perfecto para la Definición de Terminado, que debe llevar al equipo para su consideración.
La definición de Listo debe ser algo que cambie con el tiempo y le recomiendo que haga que su equipo lo revise cada 2 meses más o menos para asegurarse de que les esté sirviendo bien.
A veces, algo que alguna vez fue un criterio de aceptación se convierte en parte de su definición de hecho.
Tengo una respuesta basada en mi experiencia, pero después de googlear un poco, parece que la respuesta es la que funcione mejor para usted en su proceso. Como mencionó David Espina en su respuesta, pueden ser iguales o pueden ser diferentes.
En mi experiencia:
Acceptance Criteriason un conjunto de declaraciones, cada una con un claro resultado de aprobación/rechazo, que especifican requisitos funcionales (p. ej., funcionalidad comercial mínima). Estos requisitos representan “condiciones de satisfacción”. No hay aceptación parcial: o se cumple un criterio o no.
Definition of Donees un conjunto de sentencias que especifican requisitos no funcionales (p. ej., calidad mínima). Estos requisitos representan “condiciones de satisfacción”. No hay aceptación parcial: o se cumple un criterio o no.
La diferencia entre los dos es funcional vs no funcional. Las condiciones no funcionales generalmente consisten en cosas como revisiones de código y pruebas unitarias, entre otras cosas, que no brindan valor tradicional pero son medidas para garantizar un producto de alta calidad.
En mi opinión, no hay diferencia. La definición de hecho y los criterios de aceptación se utilizan indistintamente. No puede cumplir con la definición de hecho sin que se cumplan todos los criterios y no se puede no hacer si se han cumplido todos los criterios. Si te encuentras en el último, simplemente tienes dos conjuntos de criterios por alguna razón desconocida.
Una definición de hecho es algo a lo que todas sus historias deben adherirse.
Un criterio de aceptación es específico para la historia en la que trabajará.
Hay dos coches en una línea de producción.
La definición de hecho es que cada automóvil debe estar completamente construido, cumplir con sus especificaciones respectivas, estar listo para conducir y haber pasado todas las pruebas.
Los criterios de aceptación (especificaciones) para el primer automóvil (mini) incluyen fundas de poliéster para los asientos, tablero de instrumentos de plástico y ventanas manuales.
Los criterios de aceptación del segundo automóvil (Roller) incluyen barra, asientos de cuero, calentador de asientos, vidrios a prueba de balas, asiento eyectable y un acompañante encantador.
QED
La Definición de Listo es para el Incremento del producto, según la Guía Scrum. DoD no funciona para User Stories, pero Acceptance Criteria sí.
Por lo tanto, los Criterios de aceptación describen la funcionalidad que se requiere solo de la Historia de usuario o tarea específica.
El objetivo de la definición de hecho es construir un entendimiento común dentro del equipo con respecto a la calidad y la integridad de un producto construido y garantizar que cada incremento enviado sea de alta calidad. la lista puede incluir lo siguiente: - el código se implementa en el entorno de prueba - las pruebas unitarias se ejecutan y todo pasa - el código es revisado por pares - probado por el equipo de control de calidad (entorno) - los defectos se corrigen - Se cumplen los criterios de aceptación - La historia se demuestra a PO y se acepta - etc. Debemos cumplir con la definición de hecho para garantizar la calidad.
Los criterios de aceptación son en realidad una parte del Departamento de Defensa. El objetivo de los criterios de aceptación es aclarar lo que el equipo debe construir y garantizar que todos tengan un entendimiento común sobre la característica y el resultado.
Erudito