jueves, 5 de marzo de 2015

¿Qué significan DoR y DoD?

DoR - Ready y DoD - Done
DoR (Defintion of Ready) responde a la pregunta ¿Qué tiene que estar listo antes de empezar a trabajar en una historia de usuario para que esta pueda entrar en un sprint? DoR se refiere a la calidad de los requisitos y es responsabilidad del Propietario del Producto. Explicita los criterios para toda historia de usuario susceptible de entrar en el próximo sprint, como por ejemplo:
  • 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
Mi consejo es no empezar nunca en falso, si una historia de usuario no está preparada o el Propietario del Producto tiene dudas o no ha sabido transmitirla al 100% al equipo, es mejor no incluirla en el siguiente sprint, trabajarla e incluirla más adelante.

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:
Las historias tienen que entrar "Ready" en el sprint y salir "Done"
DoD también puede incluir acuerdos para considerar el incremento como hecho. Por ejemplo si se dedica un sprint a una página de búsqueda y en el sprint no cabe la página con el resultado, se puede explicitar el acuerdo como mostrar un xml con el resultado en la revisión de sprint para poder validar la búsqueda.

6 comentarios:

  1. Buenas tardes.
    Desde la publicación de este articulo, a la fecha.
    Existen cambios significativos o la definición ha sido invariable ¿?

    ResponderEliminar
    Respuestas
    1. El definition of Ready o Definition of Done no han cambiado.
      La 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í.... :)

      Eliminar
    2. Hola YPlaza,

      La 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

      Eliminar
    3. Gracias María NV por contestar también :-D

      Eliminar
  2. Hola, 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

    ResponderEliminar
    Respuestas
    1. Hola Juan Carlos,

      Tu 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

      Eliminar