Respuesta

El analista de negocios debe formalizar los criterios de aceptación (acceptance criteria) para cada requisito de manera que sean claros y unívocos para todos los actores del proyecto: el cliente, los desarrolladores y los testers. Para ello, se utilizan técnicas de especificación, como la formulación de criterios en notaciones Gherkin (Given-When-Then), listas de verificación y casos de uso (use cases). El analista documenta los criterios en los artefactos de requisitos y se asegura de que cada requisito tenga un conjunto de condiciones objetivas mediante las cuales se puede confirmar de manera inequívoca que la tarea se ha cumplido.

Características clave:

• Formulación clara y medible de los criterios utilizando términos comerciales y técnicos.
• Participación del cliente en la validación de los criterios antes del inicio del desarrollo.
• Inclusión de los criterios en las historias de usuario, especificaciones y casos de prueba.

Preguntas capciosas.

¿Se pueden usar solo historias de usuario para describir requisitos, sin criterios de aceptación adicionales?

No, las historias de usuario sin criterios de aceptación explícitos son demasiado abstractas y pueden ser interpretadas de diferentes maneras. Se necesitan criterios para entender que el requisito se ha implementado correctamente.

¿Es necesario incluir requisitos no funcionales (por ejemplo, rendimiento) en los criterios de aceptación?

Sí, los requisitos no funcionales también deben formalizarse en los criterios, de lo contrario, existe el riesgo de olvidarlos o implementarlos de manera incompleta.

¿Quién debe aprobar los criterios de aceptación: solo el analista de negocios?

No, siempre es necesario coordinar los criterios con el cliente y, si es posible, con el equipo de desarrollo para minimizar malentendidos.

Errores comunes y antipatrón

• Ignorar la coordinación de los criterios con el cliente.
• Dejar los criterios a criterio del equipo de desarrollo.
• Agregar criterios tarde después del inicio del trabajo.

Ejemplo de la vida real

Caso negativo: El analista de negocios no coordinó los criterios de aceptación con el cliente, y los desarrolladores entendieron los requisitos a su manera. Ventajas: Desarrollo rápido, ninguna llamada retardó el proceso. Desventajas: Después del lanzamiento, el 70% de la funcionalidad no cumplía con las expectativas reales, surgió un conflicto.

Caso positivo: El analista describió los criterios formales de aceptación, los coordinó con ambas partes y los adjuntó a las historias de usuario. Ventajas: Comprensión entre el cliente y el equipo, mínimo de errores después del lanzamiento. Desventajas: Al inicio se necesitó un poco más de tiempo para las coordinaciones.