Definición de «Hecho» – DoD

Siguiendo con nuestro gran tema de equipos AGILE y metodología SCRUM, hoy queremos profundizar un poco sobre el concepto de «definición de hecho» o en inglés «definition of done».

Es aquello que debe cumplirse para decir que una unidad de trabajo (historia de usuario) está hecha, completada, finalizada.

Una historia de usuario no puede ser considerada para aceptación a menos que cumpla con dicho criterio.

La definición de hecho es un acuerdo de equipo para asegurar la calidad del trabajo y la calidad de la dinámica de equipo a lo largo de un proyecto.

Una definición de hecho apropiada busca cumplir con las siguientes metas:

1. Estándares de Calidad para Diseño y Código.
2. Administración de Conocimiento.
3. Integración y Entrega Continua.

Cada historia de usuario deberá cumplir con los siguientes criterios:

1. Estrategia de versionamiento y ramificación de código. Corresponde al uso de un sistema de versionamiento de código y al uso de una estrategia de ramificación que incluya la creación de ramas funcionales a partir de una rama general de desarrollo, la actualización de las ramas funcionales con la ultima versión de la rama de desarrollo y la actualización del código de la rama de desarrollo desde las ramas funcionales luego de una revisión de código.
2. Pruebas unitarias. Trata del desarrollo de pruebas unitarias para el código que haya sido modificado o creado durante cada historia de usuario. Las pruebas unitarias deben incluir simulaciones (mocking) de las interfases externas y alcanzar al menos una cobertura de código del 70%.
3. Revisiones de código. Consiste en revisar el código creado y/o modificado durante una historia de usuario como mecanismo de aprendizaje para otros desarrolladores y como mecanismo de validación/mejora de la calidad del código.
4. Documentación aplicable. Corresponde a actualizar la documentación aplicable, incluyendo documentos de arquitectura/diseño, documento experto, documentos de instalación y, en el caso de SPIKES (historias de investigación) la documentación del resultado de las investigaciones. También es recomendado el uso de WIKI’s para dicha documentación.
5. Pruebas de aseguramiento de calidad. Se debe contar con un conjunto de pruebas para cada historia de usuario que validen el cumplimiento funcional del criterio de aceptación; y la ejecución satisfactoria de dichas pruebas.
6. Integración del código en los ambientes de Desarrollo y de Pruebas (QA) deseablemente de forma automatizada.
7. Pruebas de regresión e integración. Finalmente se debe contar con pruebas actualizadas de regresión e integración, deseablemente automatizadas, a fin de validar que los cambios en el código no hayan tenido efectos adversos indirectos sobre otras funcionalidades del sistema.

 

 4,530 total views,  1 views today