En el panorama del desarrollo ágil, la claridad es la moneda del éxito. Cuando un equipo comienza a trabajar en una nueva funcionalidad, la base radica en la historia de usuario. Sin embargo, una historia de usuario es meramente un marcador de posición para una conversación. Para transformar esa conversación en un producto funcional, se requieren dos artefactos críticos: los criterios de aceptación y la definición de terminado. Estos conceptos actúan como límites que garantizan calidad, alineación y previsibilidad.
Muchos equipos tienen dificultades para distinguir entre estos dos conceptos. A veces se tratan como si fueran lo mismo, lo que genera confusión durante las pruebas o la implementación. En otras ocasiones, se ignoran por completo, lo que provoca un crecimiento del alcance o que funcionalidades incompletas lleguen a producción. Esta guía explora la mecánica, el propósito y la implementación de los criterios de aceptación y la definición de terminado para ayudar a su equipo a entregar valor de forma consistente.
¿Qué es una historia de usuario? 📝
Antes de analizar los componentes de una historia, es esencial recordar qué es realmente una historia de usuario. En los marcos ágiles, una historia de usuario es una descripción breve y sencilla de una funcionalidad contada desde la perspectiva de la persona que desea la nueva capacidad. Suele seguir el formato:
- Como un [tipo de usuario],
- Quiero [algún objetivo],
- Para que [algún beneficio].
Este formato se centra en elvalorproporcionado al usuario, en lugar de la implementación técnica. Sin embargo, este formato por sí solo no es suficiente para guiar el desarrollo. No especifica los límites del trabajo ni los estándares necesarios para su finalización. Es aquí donde entran en juego los criterios de aceptación y la definición de terminado.
Criterios de aceptación (CA): Las condiciones para la finalización ✅
Los criterios de aceptación son un conjunto de condiciones que una historia de usuario debe cumplir para considerarse completa desde la perspectiva del propietario del producto. Definen los límites de la historia y proporcionan una comprensión clara de cómo debe ser el producto final.
El propósito de los criterios de aceptación
Los criterios de aceptación cumplen múltiples funciones dentro del ciclo de vida del desarrollo:
- Aclaración: Eliminan la ambigüedad. Si un desarrollador pregunta: «¿El botón debe volverse verde o azul al pasar el cursor?», los criterios de aceptación deben responder esta pregunta.
- Pruebas: Actúan como casos de prueba. Los ingenieros de calidad usan estas condiciones para validar la funcionalidad.
- Acuerdo: Garantizan que el propietario del producto y el equipo de desarrollo estén de acuerdo sobre lo que constituye «terminado» para esta historia específica.
Características de buenos criterios de aceptación
Los criterios de aceptación efectivos son específicos, medibles y no ambiguos. Evite términos vagos como «amigable para el usuario» o «rápido» sin definir métricas. En su lugar, especifique comportamientos exactos.
- Atómicos: Cada criterio debe abordar un único requisito.
- Verificables: Debe ser posible verificar el criterio con un resultado de aprobado o rechazado.
- Independiente:Los criterios no deben depender de historias externas para ser validados.
- Relevante:Enfóquese en el valor para el usuario, no en la estructura interna del código.
Ejemplos de Criterios de Aceptación
Considere una historia sobre la adición de una función de «¿Olvidó su contraseña?». Así es como podría verse el AC:
- Dado que el usuario está en la página de inicio de sesión,
Cuando hacen clic en el enlace «¿Olvidó su contraseña?»,
Entonces son redirigidos a la página de recuperación de contraseña. - Dado que el usuario ingresa un correo electrónico válido,
Cuando envían el formulario,
Entonces se muestra un mensaje de confirmación. - Dado que el usuario ingresa un correo electrónico inválido,
Cuando envían el formulario,
Entonces se muestra un mensaje de error que indica que el formato del correo electrónico es incorrecto.
Estos ejemplos siguen la estructura Dado/Cuando/Entoncesestructura (a menudo asociada con la sintaxis de Gherkin), que promueve la claridad y se alinea con los marcos de pruebas automatizadas.
Definición de Hecho (DoD): La Puerta de Calidad 🚧
Mientras que los Criterios de Aceptación son específicos para una sola Historia de Usuario, la Definición de Hecho es una norma global aplicada atodaslas tareas dentro de un sprint o lanzamiento. Representa la lista de verificación de requisitos que deben cumplirse para que cualquier incremento de trabajo se considere potencialmente entregable.
El propósito de la Definición de Hecho
La DoD actúa como una puerta de calidad. Asegura que la deuda técnica no se acumule y que el producto permanezca en un estado entregable en todo momento. Si una historia cumple sus Criterios de Aceptación pero no cumple la Definición de Hecho, no puede marcarse como completa.
Los elementos comunes encontrados en una Definición de Hecho incluyen:
- Revisión de código:Todo el código debe ser revisado por al menos un compañero.
- Pruebas unitarias:Las pruebas automatizadas deben pasar con cobertura del 100% para la nueva lógica.
- Documentación:La documentación de la API o las guías de usuario se actualizan.
- Rendimiento:La característica cumple con los requisitos mínimos de tiempo de carga.
- Accesibilidad:La característica cumple con las directrices WCAG.
- Seguridad:No se introducen vulnerabilidades conocidas.
¿Por qué importa el CDT?
Sin una Definición de Terminado, los equipos a menudo caen en la trampa de ‘técnicamente terminado pero no realmente listo’. Una característica podría funcionar según lo previsto según los Criterios de Aceptación, pero podría haber dañado otra parte del sistema, carecer de documentación adecuada o introducir riesgos de seguridad. El CDT evita esto al imponer una base mínima de calidad en todo el backlog.
Criterios de Aceptación frente a Definición de Terminado: Las principales diferencias 🆚
A menudo surge confusión porque ambos conceptos tratan sobre la ‘completitud’. Sin embargo, su alcance y propiedad difieren significativamente. Comprender esta diferencia evita desalineaciones entre desarrolladores, testers y propietarios de producto.
| Característica | Criterios de Aceptación | Definición de Terminado |
|---|---|---|
| Alcance | Específico para una única historia de usuario | Global para todo el equipo o proyecto |
| Propiedad | Propietario del producto y equipo de desarrollo | Equipo de desarrollo completo |
| Flexibilidad | Cambios por historia según los requisitos | Estable, aunque puede actualizarse con el tiempo |
| Propósito | Define los requisitos funcionales | Define estándares de calidad y no funcionales |
| Verificación | Pruebas funcionales frente a las necesidades del usuario | Verificación técnica y de procesos |
Piensa en los Criterios de Aceptación como el destino de un viaje específico, mientras que la Definición de Terminado es la lista de verificación de seguridad requerida para cada vehículo en la carretera.
Cómo escribir criterios de aceptación efectivos 📝
Escribir los criterios de aceptación es un esfuerzo colaborativo. No debe hacerse de forma aislada por el propietario del producto. La mejor práctica implica el concepto de los “Tres Amigos”, donde el Propietario del Producto, un Desarrollador y un Prueba colaboran desde temprano en el proceso de refinamiento.
Paso 1: Identificar el objetivo del usuario
Comience reformulando la propuesta de valor. ¿Qué problema está resolviendo el usuario? Esto garantiza que los criterios se centren en la experiencia del usuario en lugar de en detalles técnicos.
Paso 2: Definir escenarios positivos y negativos
No escribas solo el camino feliz. Considera lo que sucede cuando las cosas salen mal.
- Camino feliz: El usuario realiza la acción exactamente como se espera.
- Casos límite: ¿Qué sucede con caracteres especiales, datos faltantes o conexiones lentas?
- Camino negativo: ¿Cómo maneja el sistema las entradas inválidas de forma adecuada?
Paso 3: Usar un lenguaje claro
Evite el jergón siempre que sea posible. Si se necesitan términos técnicos, asegúrese de definirlos. Use el voz activa. Por ejemplo, “El sistema debe validar…” es menos claro que “El usuario recibe un mensaje de error…”.
Paso 4: Priorizar
Si una historia es grande, divídala. Los criterios de aceptación deben ser alcanzables dentro del sprint. Si los criterios implican trabajo que no puede completarse en el sprint, la historia debe dividirse.
Cómo establecer una definición de terminado robusta 🛠️
La definición de terminado no es un documento estático. Evoluciona a medida que el equipo madura y cambia la tecnología. Debe ser visible para todos, a menudo mostrada en una pizarra física o digital.
Paso 1: Consultar al equipo
La DoD es propiedad del equipo que realiza el trabajo. Los desarrolladores, probadores y diseñadores deben contribuir a la lista. Si un desarrollador añade un requisito, es más probable que lo cumpla.
Paso 2: Categorizar los requisitos
Agrupe los elementos de la DoD en categorías lógicas para hacer la lista de verificación manejable.
- Calidad del código: El linting se completó, sin advertencias, revisión entre pares finalizada.
- Pruebas: Pruebas unitarias escritas, pruebas de integración aprobadas, pruebas manuales verificadas.
- Despliegue: Desplegado en staging, pruebas de humo aprobadas.
- Documentación: El archivo Readme actualizado, la documentación de la API sincronizada.
Paso 3: Conviértelo en una parada definitiva
Si una historia no cumple con el CDE, no puede cerrarse. Esto requiere disciplina. Es tentador decir: «Arreglaremos la documentación después», pero eso genera deuda técnica. La historia permanece en «En progreso» hasta que se cumpla el CDE.
Paso 4: Revisar y perfeccionar
Durante las retrospectivas, pregunta al equipo: «¿El CDE detectó algún problema?» o «¿Hay un requisito que constantemente estamos omitiendo?» Actualiza el CDE según estas observaciones.
Errores comunes que debes evitar ⚠️
Incluso los equipos experimentados tropiezan al implementar estas prácticas. Ser consciente de los errores comunes puede ahorrar tiempo y frustración significativos.
1. Criterios de aceptación ambiguos
Escribir criterios como «El sistema debe ser seguro» es inútil. No es comprobable. En su lugar, especifica: «El sistema debe requerir autenticación multifactor para las cuentas de administrador».
2. El CDE como una tarea mecánica
Si el equipo marca la casilla del CDE sin realizar realmente el trabajo (por ejemplo, saltándose la revisión de código), el CDE pierde su sentido. El CDE debe respetarse, no solo leerse.
3. Sobrecargar el CDE
Un CDE con 50 elementos se vuelve abrumador. Enfócate en las barreras esenciales de calidad. Si un requisito rara vez se viola, podría ser una guía en lugar de un elemento obligatorio del CDE.
4. Ignorar los requisitos no funcionales
Los equipos a menudo se enfocan mucho en los AC (funcionales) y ignoran el CDE (no funcionales). El rendimiento, la seguridad y la accesibilidad forman parte del CDE, no de los AC. Ignorarlos lleva a características que funcionan pero son lentas o inseguras.
5. Crear el CDE sin el compromiso del equipo
Si el Propietario del Producto establece el CDE sin la participación de los desarrolladores, el equipo podría resistirse. El CDE debe ser un acuerdo compartido.
Integración en el flujo de trabajo 🔄
Los criterios de aceptación y el definir el final deben integrarse en cada etapa del ciclo de vida del desarrollo, no solo al final.
Fase de refinamiento
Durante el refinamiento del backlog, el Propietario del Producto redacta los criterios de aceptación. El equipo los revisa para asegurarse de que sean comprobables y factibles. Las preguntas se hacen y responden aquí, no durante la iteración.
Planificación de la iteración
Al comprometerse con historias, el equipo verifica que los criterios de aceptación sean claros. Si no lo son, la historia no está lista para la iteración.
Fase de desarrollo
Los desarrolladores escriben código para cumplir con los AC. Al mismo tiempo, aseguran cumplir con el CDE (por ejemplo, escribir pruebas, solicitar revisiones).
Fase de pruebas
Los ingenieros de QA verifican los AC frente al producto construido. También verifican el CDE (por ejemplo, revisar informes de cobertura de código, escaneos de accesibilidad).
Revisión y cierre
Antes de que una historia se mueva a «Hecho», el equipo confirma que se cumplen tanto los AC como el CDE. Si no es así, vuelve a la cola.
Medir el éxito 📊
¿Cómo sabes si tus criterios de aceptación y tu definición de final están funcionando? Monitorea métricas con el tiempo.
- Tasa de defectos:¿Están disminuyendo los errores encontrados en producción? Una definición de terminado sólida debería detectar problemas antes del lanzamiento.
- Tasa de rechazo:¿Las historias están siendo rechazadas con frecuencia por el Propietario del Producto? Esto indica una definición deficiente de los criterios de aceptación.
- Estabilidad de la velocidad:¿Permanece la velocidad del equipo consistente? Si las historias son devueltas con frecuencia por faltar elementos de la definición de terminado, la velocidad fluctuará.
- Frecuencia de despliegue:¿Permite una definición de terminado clara despliegues más fluidos y frecuentes?
Preguntas frecuentes ❓
Aquí tienes preguntas comunes que los equipos hacen al implementar estas normas.
P: ¿Pueden cambiar los criterios de aceptación durante una iteración?
R: Idealmente, no. Si los criterios de aceptación cambian significativamente, podría indicar que la historia no fue bien comprendida durante la refinación. Las aclaraciones menores son aceptables, pero los cambios importantes de alcance deberían resultar en una nueva historia o en un ajuste al alcance de la iteración.
P: ¿Necesita cada historia una definición de terminado única?
R: No. La definición de terminado es global. Sin embargo, algunas historias técnicas específicas podrían tener requisitos adicionales añadidos a la lista de verificación para ese elemento específico, pero la definición base de terminado se aplica a todas.
P: ¿Qué pasa si el equipo no está de acuerdo con la definición de terminado?
R: Facilite una discusión. El objetivo es alcanzar un consenso. Si un desarrollador insiste en un requisito con el que el probador no está de acuerdo, discuta el riesgo. Si el riesgo es bajo, descártelo. Si es alto, manténgalo.
P: ¿Qué nivel de detalle deben tener los criterios de aceptación?
R: Lo suficientemente detallado como para ser verificable. Si un ingeniero de calidad puede escribir un caso de prueba directamente a partir de los criterios de aceptación, es suficientemente detallado. Si necesitan hacer preguntas, necesita más detalle.
P: ¿Puede la prueba automatizada reemplazar a la prueba manual en la definición de terminado?
R: Depende. Para lógica crítica, sí. Para la experiencia del usuario o elementos visuales, aún podría requerirse validación manual. La definición de terminado debe reflejar la mejor práctica para la garantía de calidad.
Reflexiones finales sobre calidad y alineación 🌟
Implementar los criterios de aceptación y la definición de terminado no se trata de burocracia; se trata de respeto. Es respeto hacia el usuario que espera una funcionalidad operativa, respeto hacia el desarrollador que desea requisitos claros, y respeto hacia el propietario del producto que necesita confianza en la entrega.
Cuando estos dos conceptos se utilizan correctamente, crean un lenguaje compartido para el equipo. Reducen la necesidad de reuniones constantes de aclaración. Evitan la acumulación de deuda técnica. Y lo más importante, aseguran que cada historia completada aporte valor real al producto.
Empiece pequeño. Defina una definición de terminado básica. Escriba criterios de aceptación claros para su próxima historia. Revíselos en su próxima retrospectiva. Con el tiempo, estas prácticas se volverán naturales, integradas en la cultura de su equipo. El resultado es un flujo constante de software de alta calidad que satisface las necesidades de las personas que lo usan.