Cómo escribir criterios de aceptación: ejemplos y mejores prácticas

aquí en Mobindustry, operamos con un enfoque ágil. Eso significa que utilizamos componentes ágiles como historias de usuario y criterios de aceptación. Los equipos y organizaciones de alto rendimiento tienen estos componentes en sus productos atrasados, y saben cómo crearlos y usarlos de manera efectiva.

si su backlog de productos carece de historias de usuario y criterios de aceptación — o si no están claramente definidos, corre el riesgo de que sus expectativas no converjan con la realidad., Las historias de usuario y los criterios de aceptación son responsables de representar cómo el usuario final usará su aplicación y cómo su equipo de desarrollo debe ejecutar cada tarea de desarrollo. Cuando empezamos a trabajar en un nuevo producto, Nuestro equipo colabora con el cliente para definir historias de usuario.

Una historia de usuario es una descripción corta y simple de una característica de producto desde la perspectiva de una persona que quiere usar esa característica. Las historias de usuario se utilizan para definir el backlog de productos en un flujo de trabajo de desarrollo ágil.,

el backlog de productos es esencialmente una colección de historias de usuarios que informan la especificación funcional y el desarrollo de características para un producto o servicio en particular. Las historias de usuario constan de tres partes: una persona del usuario para el que se está escribiendo la historia, una descripción de la característica que el usuario requiere y una explicación de la necesidad que satisface la característica.

Aquí está cómo escribir una historia de usuario:

como (usuario) quiero una (característica) para que pueda (satisfacer una necesidad).

echemos un vistazo a cómo podría verse una historia de usuario., Tomaremos Airbnb como ejemplo. Imaginemos cómo una historia de usuario típica podría buscar un producto como Airbnb.

«como usuario, quiero buscar un destino para poder reservar alojamiento en una ciudad extranjera.»

definición de criterios de aceptación

Ahora, necesitamos asegurarnos de que las historias de usuario se completen correctamente y se ajusten a las demandas del cliente.

los criterios de aceptación son las condiciones que un producto de software debe satisfacer para ser aceptado por un usuario, cliente o, en el caso de la funcionalidad a nivel de sistema, el sistema consumidor.,

los criterios de aceptación son un conjunto de sentencias, cada una con un resultado de pase / error claro, que se pueden medir y especificar requisitos funcionales y no funcionales.

escribir los criterios de aceptación es importante no solo para establecer lo que el cliente espera del producto sino para el proceso de desarrollo. Naturalmente, diferentes personas ven el mismo problema desde diferentes ángulos. Los criterios de aceptación bien definidos proporcionan una visión uniforme de la funcionalidad que planea implementar.,

cualquier persona debe ser capaz de caminar hasta un tablero de Scrum, agarrar un elemento de backlog de Producto, leer los criterios de aceptación, y ver claramente todo lo que necesita ser completado para que ese elemento en particular se mueva a la columna hecho. Los criterios de aceptación le dicen lo que debe hacerse para que una parte en particular de un producto se termine.

¿por Qué necesitamos los criterios de aceptación?,

• definir límites. Los criterios de aceptación ayudan al equipo de desarrollo a definir los límites de una historia de usuario. Sirven como una forma de confirmación de que la aplicación está funcionando como se esperaba, lo que significa que la historia del usuario está completa.
• Llegar a un consenso. Los criterios de aceptación permiten que el equipo de desarrollo esté en la misma página que el cliente. Informan al equipo de desarrollo sobre exactamente qué condiciones deben cumplirse y aseguran que el cliente sepa qué esperar de la aplicación.
• optimización de las pruebas de aceptación., Los criterios de aceptación son la base de las pruebas de aceptación de historias de usuario. Cada criterio de aceptación debe ser probado de forma independiente y tener escenarios claros para el éxito o el fracaso.
• Planificación y estimación. Los criterios de aceptación le permiten distribuir historias de usuarios entre las tareas para que se evalúen y programen adecuadamente.
• Describiendo escenarios negativos. Los criterios de aceptación pueden requerir que el sistema identifique una contraseña débil e impida que un usuario continúe, por ejemplo., Introducir un formato de contraseña incorrecto es un ejemplo de un escenario negativo en el que un usuario introduce datos incorrectos o se comporta inesperadamente. Los criterios de aceptación identifican estos escenarios y explican cómo el sistema debe responder a ellos.

¿quién escribe los criterios de aceptación?,

escribir criterios de aceptación ayuda a establecer un entendimiento común entre el propietario del producto y el equipo de desarrollo con respecto a la solución del problema de un cliente o la creación de capacidades del producto. Dado que los criterios de aceptación se relacionan con el cliente y el equipo, deben ser escritos por el cliente o un miembro del equipo.

en Mobindustry, nuestros analistas de negocios escriben todos los criterios de aceptación para las historias de usuarios. Los analistas de negocios entienden las necesidades del cliente y lo que los desarrolladores necesitan saber para cumplir con los requisitos del proyecto.,

los criterios de aceptación se documentan y confirman antes del inicio del proyecto, ya que el equipo y el cliente deben acordar qué resultados cumplirán con los requisitos del cliente.

ejemplos de historias de usuario con criterios de aceptación

ahora que tiene una comprensión clara de lo que son las historias de usuario y los criterios de aceptación, echemos un vistazo a algunos ejemplos.,

ejemplo 1

historia de usuario: como usuario, quiero poder registrarme en el servicio para poder comenzar a comprar en línea.

criterios de aceptación:

• Los usuarios solo pueden enviar un formulario rellenando todos los campos obligatorios.
• El Correo electrónico que proporcione el Usuario no debe ser proporcionado por un servicio de correo electrónico gratuito.
• Las presentaciones de la misma IP solo se pueden hacer tres veces en un plazo de 30 minutos.
• Los usuarios reciben correos electrónicos de notificación después de registrarse correctamente.,

Ejemplo 2

historia de usuario: como usuario, puedo acceder a una notificación en mi dispositivo inmediatamente después de recibirla.

criterios de aceptación:

• deslizar / tocar una notificación lleva al usuario directamente al mensaje.
• La Vista muestra la conversación — si el nuevo mensaje era una respuesta, se muestra encima del original.
• El recuento de mensajes se actualiza.
• Un mensaje se marca como leído después de que se muestra.

7 consejos para escribir buenos criterios de aceptación

los criterios de aceptación no son fáciles de escribir., A pesar del formato simple, escribir el texto es un desafío. Aquí hay siete consejos para ayudarlo a evitar errores comunes al escribir los criterios de aceptación o para revisar los criterios escritos por un miembro de su equipo.

• Criterios de documento antes de que comience el proceso de desarrollo. De esta manera, es más probable que el equipo capte todas las necesidades del cliente por adelantado. Inicialmente, es suficiente establecer criterios para un pequeño número de historias de usuario para completar los retrasos de dos sprints. A continuación, los desarrolladores utilizan los criterios de aceptación documentados para planificar el proceso técnico.,
• No haga que los criterios de aceptación sean demasiado estrechos. Los criterios de aceptación que son demasiado específicos dejan a los desarrolladores poco espacio para maniobrar. Para evitar esto, recuerde que los criterios de aceptación deben ser una expresión de intención, no una decisión final. Además, es posible que los criterios de aceptación estrechos no tengan en cuenta todas las acciones del usuario.
• Mantenga sus criterios alcanzables. Los criterios de aceptación efectiva definen una cantidad mínima razonable de funcionalidad que puede proporcionar. Pero si sigues describiendo todos los pequeños detalles, existe el riesgo de que tu equipo se quede atascado en cientos de pequeñas tareas.,
• evite criterios de aceptación demasiado amplios. Los amplios criterios de aceptación hacen que una historia de usuario sea vaga. Los criterios de aceptación efectivos deben describir el alcance del trabajo para que los desarrolladores puedan planificar y estimar adecuadamente sus esfuerzos.
• Evite los detalles técnicos. Los criterios de aceptación deben estar escritos en un lenguaje sencillo. Es posible que sus partes interesadas y gerentes no tengan antecedentes técnicos, por lo que usar un lenguaje sencillo hará que los criterios sean comprensibles para todos.
• Llegar a un consenso., El mismo problema puede ser resuelto de diferentes maneras por los miembros del equipo y las partes interesadas dependiendo de sus puntos de vista. Asegúrese de comunicar sus criterios de aceptación a las partes interesadas y a los miembros del equipo y llegar a un acuerdo mutuo.
• Escribir criterios de aceptación comprobables. Esto dará a los probadores la oportunidad de garantizar que se cumplan todos los requisitos y permitirá a los desarrolladores saber si la historia del usuario está completa.,

Cómo escribir los criterios de aceptación

Aquí hay cinco reglas generales que le ayudarán a resolver problemas con la redacción de los criterios de aceptación. Estas reglas le permitirán ahorrar un tiempo valioso y establecer un entendimiento entre el propietario del producto y el equipo de desarrollo.

Regla # 1: Evite «no»

» no «significa» en ningún caso » y, por lo tanto, no será suficiente tiempo para verificar el cumplimiento de tal condición., Si reescribe el requisito sin usar «no», será más claro y, lo más importante, verificable.

ejemplo:

historia de usuario

no: como usuario, no quiero tener que introducir mi contraseña cada vez que acceda a mi cuenta.
hacer: como usuario, quiero que mi contraseña sea recordada y completada automáticamente para que pueda acceder a mi cuenta sin volver a ingresar mi contraseña.

los criterios de Aceptación

no: El sistema no debe fallar.
Do: el sistema debe tener una disponibilidad de no menos del 90%.,

Exception

puede usar » not » en los criterios de aceptación para introducir una objeción lógica, como «el formulario de inicio de sesión no debe ser rojo.»En la mayoría de los casos, esto se aplicará a los requisitos no funcionales. En este ejemplo, formulamos una restricción que se puede verificar fácilmente si el rango de tonos de rojo está claramente definido (por ejemplo, especificado en formato RGB).,

la Regla #2: Uso de la voz activa

la voz Activa es cuando el sujeto de una oración es el ejecutante de la acción. Si la entidad responsable de ejecutar la acción no está claramente indicada, no estará claro quién o qué debe realizar la acción, y será más difícil para Usted verificar si se cumple un requisito.,

ejemplo:

historia de usuario

no: como comprador en línea, Quiero que se apliquen filtros para que pueda encontrar lo que quiero.
Do: como usuario, quiero aplicar filtros de búsqueda para que pueda encontrar elementos.

criterios de aceptación

no: se debe confirmar la identidad del cliente. (No está claro quién o qué es responsable de confirmar la identidad del cliente.)
Do: El Accounting_System debe confirmar la Customer_Indentity. (Tenga en cuenta que las definiciones de los Términos «Accounting_System» y «Customer_Indentity» deben agregarse al glosario.,)

Regla # 3: Evite usar pronombres (especialmente los indefinidos)

Use sustantivos en lugar de pronombres cuando se refiera a elementos a los que se hace referencia en otros requisitos. Los pronombres deben evitarse porque pueden introducir ambigüedad.,

esto es especialmente importante cuando los criterios de aceptación se almacenan en Herramientas de gestión de requisitos (como Jira) como declaraciones separadas que no están necesariamente organizadas. Siempre use sustantivos en lugar de pronombres y evitará este problema.

ejemplo:

historia de usuario

no: como miembro del sitio, quiero compartir información sobre mí para que otros puedan verla.
Do: como miembro del sitio, quiero agregar una descripción de perfil para que otros puedan aprender sobre mí.

criterios de aceptación

no: el controlador debe enviar al conductor el itinerario del día., Debe entregarse al menos 8 horas antes del turno.
Do: El controlador debe enviar el Driver_Itinerary del día al conductor al menos 8 horas antes del Driver_Shift.

Regla #4: Evitar las conjunciones

las Conjunciones son palabras y frases tales como «y», «o», «pero», y «así como» que combinan las oraciones simples a los más complejos., Su uso en los requisitos suele ser una señal de que un requisito se puede dividir en varios requisitos separados.

ejemplo:

historia de usuario

no: como diseñador de interfaz de usuario, quiero crear y ver un problema para saber qué probar.
Do: como diseñador de UI, quiero crear un problema para saber qué probar. / Como diseñador de UI, quiero ver un problema para saber qué probar.

criterios de aceptación

no: el Usuario debe ser de confianza o no.
Do: El Security_System debe categorizar a cada usuario como de confianza o Not_Trusted.,

Exception

«And, «»or,» Y » not » se pueden usar para describir condiciones lógicas y agregar calificadores.

Regla # 5: Evite los absolutos inalcanzables

un absoluto (como la disponibilidad del 100%) es inalcanzable. Piense en cómo verificar el indicador: ¿será posible demostrar que el nivel de disponibilidad del sistema es exactamente del 100%?, E incluso si se pudiera crear un sistema de este tipo, ¿puede permitírselo?

evite las palabras «todo», «siempre» y «nunca», ya que verificar tales requisitos absolutos requerirá un número infinito de pruebas.

ejemplo:

historia de usuario

no: como viajero, quiero saber mi ubicación precisa actualizada en tiempo real para no perderme. («Tiempo Real» se puede interpretar de diferentes maneras. Por ejemplo, puede verse como un absoluto (la ausencia de cualquier retraso), que no se puede lograr y que no es verificable.,)
Do: como viajero, quiero saber mi ubicación precisa, actualizada cada segundo, para que no me pierda.

criterios de aceptación

no: el sistema debe tener 100% de disponibilidad. (100% es un absoluto que no se puede alcanzar y no se puede verificar.)
Do: el sistema debe tener una disponibilidad de al menos 98%.

resumen rápido de los criterios de aceptación

esperamos que este artículo haya arrojado luz sobre el mundo de los criterios de aceptación y las historias de usuarios., Estos son los puntos clave:

• Los criterios de aceptación son las condiciones que un producto de software debe satisfacer para ser aceptado por un usuario, cliente o, en el caso de la funcionalidad a nivel de sistema, el sistema consumidor.
• Los criterios de aceptación deben documentarse y completarse antes del inicio de un proyecto, ya que el equipo y el cliente deben acordar qué resultados cumplirán con los requisitos del cliente.
• recuerde que los criterios de aceptación deben ser una expresión de intención, no una decisión final.
• Los criterios de aceptación efectiva definen una cantidad mínima razonable de funcionalidad.,
• Los buenos criterios de aceptación deben describir el alcance del trabajo para que los desarrolladores puedan planificar y estimar adecuadamente sus esfuerzos.
• Los criterios de aceptación deben estar escritos en lenguaje sencillo.
• asegúrese de comunicar sus criterios de aceptación a las partes interesadas y los miembros del equipo y llegar a un acuerdo mutuo.
• Al escribir los criterios de aceptación, evite usar» no», conjunciones y absolutos inalcanzables. Formula oraciones usando la voz activa.,

si desea crear criterios de aceptación e historias de usuario para su aplicación móvil o si tiene alguna pregunta sobre este tema, póngase en contacto con Mobindustry para una consulta gratuita.