La Definición de Hecho es un acuerdo del equipo, y en muchas ocasiones de la organización, Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra “Hecha” para ser presentada al Product Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada y presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Terminado”.
Ya en la práctica, consiste en una especie de Checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros se puede ver también la columna “Done, Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Hecho o Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el Tester en el ambiente de pruebas, etc. Y más importante, cuando ha sido revisada y “firmada” por el Product Owner.
Varios practicantes de desarrollo ágil sugieren lo mínimo que debe contener la definición de Done, entre estas propuestas están las siguientes:
- Aprobación por el product owner
- Preparación review
- Notificar interesados
- Actualización del product backlog
- Actualizar los tableros (información crítica del proyecto)
- Pre-demostración con el equipo
- Pruebas código 100% completado
- Código cumple estándares de codificación
- Código almacenado en sistema control de versiones
- Diseños responsive
- Refactorización de código
- Revisión de código de compañeros
- Diseño de casos pruebas
- Completadas pruebas de integración
- Pruebas de performance
- Diseño técnico y/o manual técnico y/o configuración
- Validación implementación arquitectura
- Pruebas servidor de integración continua
- Carta de certificación
La Definición de “Listo” o Definition of Ready
Análoga a la Definición de “Hecho”, la definición de “Listo” es un acuerdo del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un Sprint. Básicamente, es un conjunto de condiciones y/o un Checklist también al cual se somete una historia para ser tomada en un Sprint Planning, a continuación un listado de ejemplificaciones para aquellas tareas claves para la Definición de “Listo”.
- Lista de dependencias identificadas
- Criterios de aceptación de las historias de usuario
- Máximo de criterios de aceptación por Historia de Usuario
- Valor de negocio identificados claramente
- Identificar requerimientos Frontend y Backend
- Tamaño máximo de Historias de Usuario
- Historia de Usuario estimada
- Prototipos aceptados
- Diagrama de Interacción
- Identificar Requerimientos no funcionales
- Configuración de ambiente de desarrollo y/o pruebas
- Pruebas de Usabilidad
- Insumo de interfaces
- Prototipos aprobados
- Escenarios de prueba
- El equipo sabe que van a demostrar y como Acuerdos de Interfaces
Diagrama de las definiciones.
¿Por qué es importante?
Desde la práctica, una historia de usuario no está lista a la primera. El Product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior, el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (Es de saber que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers y Product Managers priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su Backlog y otros Backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura, técnicos con el arquitecto o Líder Técnico, trabajando junto con el equipo en el grooming del Backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.
El Quién, Cuándo y Cómo de la definición de hecho
¿Quién?: La definición de hecho debe de construirse entre el equipo y el Product Owner. El Scrum Master tiene la labor de facilitar su generación, recopilar los acuerdos tomados y de ayudar a su puesta en práctica.
¿Cuándo?: Debe de realizarse al inicio del proyecto, antes de empezar el desarrollo. Evidentemente, por la propia evolución del proyecto podremos encontrarnos con la necesidad de realizar ajustes en la definición original, tanto para introducir como para eliminar puntos de control, pero siempre con el consenso de todas las partes.
¿Cómo?: Para poner en práctica la definición de hecho lo más sencillo y adecuado es interpretarla como un Checklist a utilizar por el equipo durante el desarrollo, pero sobretodo, antes de cerrar las historias. En caso de que el equipo delegue la operación de cierre de historia en el Product Owner o en el Scrum Master, éste podría hacer una revisión de cumplimiento de la Definición de Hecho.
