Consejos Tecnológicos

¿Cuáles son los criterios de aceptación?Definiciones y mejores prácticas

Consideremos un escenario en el que su equipo de desarrollo está trabajando en un conjunto Historia del usuario Por un producto. Al final del sprint, el desarrollador puede haber marcado una historia como completa, ¡pero el propietario del producto no lo cree así! La historia se llevó al siguiente sprint para seguir trabajando y, como resultado, se redujo la velocidad del equipo. Si el desarrollador tiene una comprensión clara e inequívoca de las expectativas reales del propietario del producto, se puede evitar este malentendido.

Aquí es donde los criterios de aceptación juegan un papel importante.Aveces llamado Definición de finalización Para las historias de usuario, ayudan a enumerar los requisitos que deben cumplirse para marcar la tarea como completada en todos los aspectos.

¿Cuáles son los criterios de aceptación?

Los criterios de aceptación son requisitos predefinidos que deben cumplirse, teniendo en cuenta todos los escenarios posibles para considerar completar una historia de usuario.

En otras palabras, especifican las condiciones bajo las cuales se puede decir que la historia del usuario está «completada». Cuando se cumplen todos los criterios, el equipo puede dejar la tarea a un lado y pasar a la siguiente historia.

¿Por qué necesitamos criterios de aceptación para las historias de usuarios?

Como muestra nuestro ejemplo, tener un conjunto de criterios de aceptación expresados ​​correctamente eliminará todas las ambigüedades que rodean la funcionalidad que se está desarrollando. El desarrollador comprenderá las expectativas del cliente y sabrá cuál es la función esperada.

Los criterios de aceptación se utilizan para:

  • Expectativas de la dirección: la historia de aceptación define claramente los límites de la tarea. Generalmente, los criterios de aceptación son comprobables y los resultados de sí / no o aprobado / reprobado no causarán malentendidos.
  • Llegue a un consenso con los clientes: en algunos casos, los clientes pueden sentir que necesitan obtener más de esta función y la función no puede satisfacer completamente sus requisitos. Los criterios de aceptación bien documentados resolverán todas estas ambigüedades.
  • Explique la función de la prueba: Los criterios definidos ayudarán a verificar si el sistema cumple con las expectativas.
  • Trabajo de estimación: cuando el equipo conozca los límites de cada tarea, podrá realizar estimaciones precisas.
  • Alcance de la gestión: cuando las partes interesadas cambian los requisitos en medio de un proyecto, se produce un deslizamiento del alcance. Un entregable puede expandirse repentinamente a cinco y, a menos que el alcance se defina correctamente al principio, es probable que las historias de usuarios tengan un alcance gradual, lo que hará que el cronograma y el presupuesto caigan en caída libre.

Consejos para redactar criterios de aceptación utilizando ejemplos

Enlace de origen: productcoalition.com

La imagen de arriba no requiere explicación y muestra lo que sucede cuando los criterios de aceptación no están claramente definidos. Cada resultado tiene un árbol, una cuerda y un columpio; pero están lejos de los requerimientos del pobre cliente.

Entonces, ahora que comprende qué son los criterios de aceptación y por qué son importantes, aquí hay algunas de las mejores prácticas recomendadas para redactar buenos criterios de aceptación.

  1. Asegúrese de que cada registro de producto o historia de usuario tenga un conjunto único de criterios de aceptación.
  2. Deben ser simples, claros y fáciles de probar. Cada criterio debe responder «sí / no» o «pasa / no pasa».
  3. Asegúrese de que los criterios de aceptación estén definidos, Y congelar Antes de implementar historias de usuarios. ¡No se permiten ajustes!
  4. Concéntrese en el resultado final, no en el método.En otras palabras, piensa en qué En lugar de cómo.
  5. Cuando sea relevante, incluya todos los estándares no funcionales y aspectos funcionales para tener una comprensión clara y completa de lo que se necesita.
  6. Es mejor establecer un proceso para que los miembros del equipo escriban los criterios de aceptación y luego el propietario del producto lo firme. El PO mantiene la visión del producto para que pueda asegurarse de que se está logrando el objetivo general.

A continuación, se muestran algunos ejemplos de criterios de aceptación claros:

Esta es la historia del usuario:

  • Como capacitadora ágil, quiero imprimir un informe de evaluación para poder compartir con su empleador los detalles del desempeño del estudiante en el curso.

Los criterios de aceptación para esta historia pueden ser:

  • Muestra el puntaje de la evaluación de cada prueba completada por el estudiante.
  • Elija una puntuación que deba compartirse con el empleador.
  • Seleccione la opción para compartir el informe (otras opciones se pueden imprimir o guardar).
  • Elija con quién desea compartir el informe.
  • Si la respuesta es incorrecta, se muestra un mensaje de error.
  • Comparta documentos por correo electrónico.

Esta es otra historia de usuario:

Los criterios de aceptación para esta historia pueden ser:

  • Después de hacer clic en «Ver carrito de compras», el carrito de compras se abrirá en una nueva pestaña.
  • Se muestra el número de cada elemento y se puede cambiar.
  • Muestra el monto total de la factura.
  • Haga clic en la pestaña «Pagar», puede elegir el tiempo de entrega y la dirección.
  • Después de hacer clic en «Continuar pago», se mostrarán varias opciones de pago.
  • Elija entre varios métodos de pago.
  • Si es necesario, configure la opción seleccionada como la opción predeterminada.
  • Haga clic en «Realizar pedido y pagar», puede ingresar los detalles de su cuenta y luego ir al sitio web del banco para realizar el pago.

¿Quién es responsable de redactar los criterios de aceptación?

No se asigna ninguna responsabilidad por la preparación de los criterios de aceptación.Aunque generalmente es el propietario del producto o el gerente de producto el que define las funciones, casi cualquier miembro del equipo puede escribir los criterios de aceptación. Historia del usuarioEl autor debe asegurarse de que los criterios de aceptación estén escritos desde la perspectiva del usuario final, por lo tanto Dueño del producto (Quien es considerado la voz del cliente) suele emprender esta tarea.

Sin embargo, ahora es una práctica común establecerlo como una actividad compartida en la que todos (incluidos los desarrolladores, evaluadores y personal de control de calidad) participen; de modo que todo el equipo pueda tener una vista de 360 ​​grados de lo que traerá la función. Cuantos más roles se involucren en esta actividad, mejor, porque esto brinda más oportunidades para el trabajo en equipo y la discusión. Muchas personas pueden trabajar mejor y puede haber funciones, dependencias o escenarios que una persona pasa por alto, pero la otra puede reconocerlo, simplemente porque resuelve el problema desde una perspectiva diferente.

¿Cuándo se deben escribir los criterios de aceptación de la historia de usuario?

Los criterios de aceptación deben escribirse antes de que la historia del usuario pase de la lista de trabajos pendientes del producto a la lista de trabajos pendientes del sprint. Esto suele suceder durante la sesión de preparación del trabajo pendiente al final de cada sprint (o la primera vez, antes del inicio del primer sprint).

Es importante escribir y finalizar los estándares antes de que comience la implementación, de modo que cualquier desafío en el trabajo real no afecte la definición de la función de la tarea.

Además, esto es un poco complicado, asegúrese siempre de que los criterios de aceptación no se escriban prematuramente. Al igual que la naturaleza de los proyectos ágiles, las prioridades cambian constantemente a medida que cambian los requisitos y es posible que deban reescribirse.

¿Cómo debe formatear los criterios de aceptación para las historias de usuario?

Hay dos formatos de uso común para los criterios de aceptación:

  1. Dado / cuando / entonces

Para historias de usuarios que suelen seguir este formato:

Como (usuario esperado), quiero (acción esperada) para (objetivo / resultado de la acción).

…… Los criterios de aceptación son los siguientes:

Escena: (Explique la escena). Dado (cómo comenzaron las cosas), cuándo (acciones tomadas), luego (resultados de las acciones tomadas).

P.ej:

Historia del usuario: Como comprador en línea, quiero agregar un libro a mi carrito de compras para poder comprarlo.

Criterios de aceptación: Dado que tengo tres libros en mi lista de deseos, cuando hago clic en un libro, se agregará a mi carrito de compras.

  1. Lista de verificación de verificación

El equipo desarrolla una lista de verificación de verificación, define una lista de aprobación / falla o no declaración y marca la función como completa.

Independientemente del formato que elija, debe ser el formato que el equipo esté dispuesto a utilizar.

Agregar

La propia historia del usuario se puede explicar de cientos de formas diferentes.Solo cuando se definan los criterios de aceptación, los resultados esperados serán completamente claros, y el cliente y el desarrollador se mantendrán sincronizados en términos de funcionalidad. Historia del usuario Proporcionará.

Al establecer un proceso claro para definir los criterios de aceptación y garantizar que se tomen en serio, Equipo ágil Se puede garantizar que no haya ambigüedad, que todos estén en la misma página y que los clientes obtengan lo que piden.

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba