Una versión inicial de Definition of Done (Definición de Hecho / Terminado / Realizado)

La  Definition of Done -  DoD - (Definición de Hecho / Terminado / Realizado) es el estándar de calidad que debe cumplir el equipo Scrum, es aquello que les garantiza que han cumplido lo que se han comprometido y que el "Incremento"  de funcionalidad es realmente "potencialmente entregable"

La mejor definición de "done" la leí de Alan Cyment:

 "ALGO ESTA HECHO CUANDO NO TENGO QUE VOLVER A PREOCUPARME DE ELLO"

Si el equipo de desarrollo o alguien del equipo siente que no esta totalmente hecho y ejemplo:

• falta un despliegue
• falta una validación
• duda si se realizaron toda la documentación comprometida
• o le da "susto" salir a producción con el desarrollo realizado (el incremento de software) por que sabe que tiene unos "pendientes" o cree que le van a reventar en producción muchos bugs

entonces no esta realmente "Done"

La DoD debe estar publica y disponible para el equipo, debe ser un acuerdo entre todos:

• Product Owner
• Teaam Developer
• Scrum Master

Este acuerdo se realiza inicialmente en el sprint cero y se va revisando en cada sprint planning (como fruto de nuevas necesidades o resultado de las retrospectivas), Si hay cambios en la DoD,  es casi seguro que impliquen nuevas tareas en cada sprint.

Aunque el Team Developer (Equipo de Desarrollo) debe ser responsable de cumplir la DoD, el que debe velar por que se logre este compromiso es el Scrum Master.

A continuación les comparto una versión inicial que puede ser evolucionada, corregida, mejorada o aumentada por cada equipo Scrum:

DEFINICIÓN DE HECHO

• Cada historia de usuario/funcionalidad este codificada, compilada, desplegada por el servidor de integración continúa.
• Las historias de usuario/funcionalidades cumplan todos los criterios de aceptación acordados con calidad(QA), el Product Owner al inicio del sprint.
• Las historias de usuario/ funcionalidades construidas no afecten a las funcionalidades ya entregadas, por lo que las pruebas de regresión deben ser satisfactorias.
• Las funcionalidades/historias de usuario comprometidas funcionen en todos los ambientes comprometidos, ej:
• Laboratorio
• Pruebas
• Preproducción
• Las funcionalidades/historias de usuario cuentan con pruebas funcionales automatizadas y despues de correr estas el resultado es exitoso.
• No se tienen advertencias en Rojo en la verificación de código del servidor de integración continua (Sonar) - en caso que estemos trabajando con Jenkins y Sonar - .
• Las clases de negocio cuentan con pruebas unitarias que verifican su correcto funcionamiento.
• El Código desarrollado se comentado y estandarizado.
• Código en el repositorio de control de versiones.
• El porcentaje de cobertura de pruebas unitarias al código es >= a un XX%
• El porcentaje de cobertura de pruebas funcionales automatizadas a las funcionalidades/historias de usuario es >= a un XX%
• Se genere y/o actualice la documentación comprometida para el Sprint
• Documento de arquitectura
• Documento de diseño
• Manual de Usuario
• Plan de pruebas
• u otro documento del proceso de desarrollo que le agregue valor al proyecto o que contractualmente estemos comprometidos a entregar
• [nuevo] Se cumpla con los requisitos no funcionales, por ejemplo:
• Estándares gráficos
• Estándares de usabilidad y UX
• Navegadores y versión de los mismos sobre los que debe funcionar
• Servidores de base de datos y de aplicaciones sobre los que funcionará
• Tipo de servicios a emplear
• etc.