Completando tus tareas (parte 2)
No usarás el “ya está” en vano…

En la entrega anterior revisé lo que en mi experiencia son los elementos necesarios para decir que terminamos las actividades que corresponden al desarrollo de lo que teníamos que programar para la User Story o el Sprint. Ese es solo el 50% del trabajo, el otro 50% corresponde que nuestro desarrollo sea aceptado para ser liberado. En ese caso, primero revisemos ¿qué son los criterios de aceptación?
De forma sencilla los Criterios de Aceptación son los elementos que nos indican que nuestro desarrollo trabaja como se esperaba.
Para lograra estas expectativas el equipo de desarrollo en conjunto con el Product Owner realiza una lista de elementos que dará claridad a la calidad y aceptación a nuestra entrega.
De forma similar con las Historias de Usuario, los criterios de aceptación se escriben en oraciones claras y concisas sobre las condiciones que el producto debe satisfacer para ser aceptado por cualquier stakeholder. Por esa razón es que el Product Owner participa en la generación de estas definiciones.
Podemos decir que los criterios de aceptación son los decorados, pero también son las interacciones y validaciones de aquello que realizamos.
Para facilitar la generación de los criterios de aceptación podemos separar estos en tres tipos:
- Criterios Funcionales: Identifica tareas específicas del usuario y procesos de negocio así como validaciones. Esto puede ser: Las contraseñas deben tener al menos 16 caracteres que incluyan una letra mayúscula, un número y un carácter especial. El usuario debe ser capaz de ver los elementos a los que está permitido según su nivel de acceso. El usuario solo puede realizar las acciones que le permite sus atribuciones dentro del sistema.
- Criterios no funcionales: Estos están relacionados con el diseño y forma de los elementos, redacción, tipo de mensajes, etc. Ejemplos de estos son: Los colores y los botones corresponden al diseño de interacción de la aplicación. Los mensajes incluyen un tipo de iconografía que distingue su severidad. El sistema es accesible para personas con discapacidad
visual. La aplicación es responsiva entre diferentes plataformas o medios de presentación. - Criterios de rendimiento: Si el rendimiento o desempeño de es crítico en la aceptación de una Historia de Usuario, este debe ser incluido. Esto tiene que ver con el tiempo de respuesta al realizar las acciones de negocio.
- Criterios de interacción: Un problema muy común en los Criterios de Aceptación tiene que ver con las colisiones y afectaciones entre sistemas, esto se producen porque en el equipo de desarrollo muchas veces se enfoca en el Detalle de su sprint o del módulo actual y no en la perspectiva general del proyecto. Es importante identificar los impedimentos, obstáculos e interacciones de todo el proyecto para garantizar la calidad del producto que se generará. El diseño de la característica actual no debe afecta otros módulos o sistemas que ya funcionan, si lo hace, se evalúa si se excluye la característica o se amplia el backlog para solucionar este problema. Siempre.
Como podemos ver, los Criterios de Aceptación son todos aquellos elementos que de cierta forma garantizan la calidad de lo que programamos, y son parte de lo que se programa, si bien, son dos cosas distintas, son parte de un todo: nuestra entrega.
¿Cómo redactar criterios de aceptación?
Así como las historias de usuario están conformadas por una estructura, los criterios de aceptación tienen dos formas de enunciarse que hace a todos comprensible su definición.
Estructura de enunciados
Cuando <rol> <entrada> se realiza <proceso/flujo/subflujo> y da un <resultado>. En este esquema podríamos decir algo como lo siguientes:
Cuando el <Administrador> <presiona el botón de Nuevo empleado> se <muestra la ventana modal> para <registro de empleados>.
De esta forma entendemos que:
- Roles, son aquellos y usuarios actores del sistema
- Entradas, son los elementos de acción o de entrada, estos pueden ser: escribir valores, presionar botones, cargar archivos, etc
- Procesos, son los flujos/subflujos que se inician y las operaciones que se realizan, mostrar una ventana nueva, guardar un elemento, generar un archivo, etc.
- Resultado, es lo que esperamos que pase, es la conclusión de un proceso terminado o en proceso, una pantalla a mostrar, un archivo descargado, un registro guardado, es, el resultado. Los resultados deben ser expresados de forma clara y específica, lo menos ambigua posible pero sin llegar al detalle ínfimo
Estructura de procesos
Lista de pasos que llevan a que se tenga un resultado esperado, sirve de soporte a la historia de usuario y son más detallados.
- Como Administrador puedo crear Usuarios
- Puedo Crear los usuarios desde el botón “Nuevo usuario”
- Cuando presiono “Nuevo usuario” me aparece una pantalla con la información: nombre, email, telefono, cargo, estado de la cuenta, jefe inmediato, reporta a, etc.
- No puedo asignar un usuario “reportar a” un usuario inactivo
- No puedo asignar a un usuario “reportar a” sí mismo
- No puedo asignar un usuario “reportar a” usuarios ciclicos (Usuario 1 reporta a Usuario 2 que reporta a Usuario 1)
- El sistema manda un correo notificando al usuario cuando fue creado
En conclusión
Algo muy importante que debemos tener en cuenta: los Criterios de Aceptación, cambian de tarea a tarea, de historia de usuario a historia de usuario y de sprint a sprint. Por lo tanto, se debe validar siempre cuales criterios aplican y cuales no. Siempre valida con el Product Owner cuales serán los elementos de aceptación y así garantizarás la calidad de tu entrega.
Algo que en mi experiencia funciona mucho, es no esperar a que QA valide los criterios de aceptación, el costo en tiempo suele ser muy alto, cuando programamos, podemos ir haciendo tareas de validación por nuestra cuenta de cada criterio de aceptación además de cubrir los elementos de la DoD, y esto es coherente con una situación: cuando programamos probamos y vemos lo que programamos. También podemos pedir a miembros del equipo hacer un pre-QA. Esta práctica a mi me trajo ahorros en tiempo de hasta el 30% y salidas a producción en el primer intento del 80%.
No es fácil, es un cambio de cultura, en desarrollo todo urge, pero ahí radica saber hasta dónde comprometernos y negociar los criterios de aceptación para que lo que entreguemos sea lo que se espera y funcione como debería de funcionar. Eso aumentar nuestra calidad y nuestro valor como equipo de desarrollo.
Cubierta la Definición de Terminado y los Criterios de Aceptación, puedes decir con toda confianza que tu trabajo está completo, que: ya está.
