 |
| DoR - Ready y DoD - Done |
- Que sea independiente y desarrollable en un solo sprint
- Que los criterios de aceptación que describen la nueva funcionalidad sean detallados
- Que se pueda testear
- Que no tenga dependencias externas
- Que esté estimada por el equipo
- Aprobada por arquitectura
- Aprobada por el usuario
DoD (Definición of Done) responde la pregunta ¿Qué tiene que cumplir una historia de usuario para que esté hecha?, se refiere a la calidad del software y es responsabilidad del equipo. Una definición de hecho crea un entendimiento común en todo el equipo/compañía de lo que significa hecho. Explicita los criterios para que toda historia de usuario sea considerada hecha, a diferencia de los criterios de aceptación que son específicos por historia. Ejemplos:
- La historia ha sido analizada y se ha hecho el diseño
- El código escrito
- El código documentado o comentado
- El código se ha integrado
- El código probado apropiadamente (pruebas unitarias, de integración, de regresión, etc.)
- La historia ha pasado las pruebas de forma manual o automática según los criterios de aceptación
- La documentación y otros requisitos que requiere el proyecto/producto están hechos
 |
| Las historias tienen que entrar "Ready" en el sprint y salir "Done" |
Buenas tardes.
ResponderEliminarDesde la publicación de este articulo, a la fecha.
Existen cambios significativos o la definición ha sido invariable ¿?
El definition of Ready o Definition of Done no han cambiado.
EliminarLa definición que genere cada equipo de estos términos y sus criterios dependen de cada uno de ellos, según las necesidades, naturaleza del proyecto, compañía, el equipo en sí.... :)
Hola YPlaza,
EliminarLa definición de hecho (DoD) sigue tal como se definió en origen en la Scrum Guide. Con los marcos de escalado se ha introducido definiciones de hecho a diferentes niveles, encontrarás información en el siguiente post: ¿Hay definiciones de hecho (DoD) a diferentes niveles?.
Respecto a la definición de listo (DoR) decrite que esta ya no está en la Scrum Guide porque Scrum.org no es partidaria de la misma. Encontrarás el porqué aqui: ¿Porqué la definición de listo (DoR) no es prescriptiva en Scrum?
Y si quieres promover una buena DoR puedes hacerlo incidiendo sobre la calidad de historias de usuario, tal como describo aqui: ¿Qué puede ayudar a evaluar la calidad de una historia de usuario con INVEST?
Espero haberte ayudado, gracias por preguntar, saludos,
Alex
Gracias María NV por contestar también :-D
EliminarHola, se que ha pasad un buen tiempo desde que se escribió este articulo, pero pregunto, espero me puedan guiar un poco, quien es el responsable de velar por un DoD, soy nuevo como Scrum master y me dicen que esta tarea es mi deber, pero otros me dicen que no. Gracias
ResponderEliminarHola Juan Carlos,
EliminarTu responsabilidad como Scrum Master es que exista un DoD y asegurarte que el equipo lo siga - básicamente no debes de permitir que se considere acabada una historia de usuario si no cumple con DoD.
Es responsabilidad del equipo y del Product Owner definir que significa "terminado" para ambos, y son ellos los responsables de idenficar los criterios del DoD y de mantenerlos a lo largo del tiempo (si DoD varia se suele hacer en la retrospectiva).
Si lo piensas es de sentido común, para ir a un ejemplo sencillo: solo el pintor (equipo) y el cliente (Product Owner) pueden decidir cuando cualquier pared (historia de usuario) esta pintada y acabada (por ejemplo grosor de pintura sobre la pared). El Scrum Master se asegura de que proceso a seguir se haga bien, que pintor y cliente verifiquen que la pared pintada esta acabada para ambos.
Espero haberte ayudado,
Alex