La importancia de tener una buena definición del DOR

4
(2)

“Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo.”

Andrew Carnegie

En los proyectos tradicionales es común que se utilice una robusta documentación para transmitir las necesidades del negocio al equipo de desarrollo causando que se pase de mano en mano generando que se distorsione en el camino los objetivos iniciales.

En los proyectos ágiles cambiamos la forma de transmitir las necesidades debido a que nos enfocamos en cambiar alguna documentación por conversaciones y traducir esas conversaciones en tarjetas.

Algunas veces las Historias de Usuario no contienen toda la información necesarios para el desarrollo de un producto en una organización. Es ahí donde juega un papel importante las definiciones antes de iniciar (DOR y DOD), que son checklist que deben contener los item del producto para que tanto negocio y equipo tengan un entendimiento mutuo de lo que se va a desarrollar y como se va a verificar.

Definition of Ready (Definición de Preparado)

El DOR es una lista de elementos que debe contener cada ítem del Product Backlog para que el equipo pueda comprometerse a desarrollar en el Sprint. La definición del DOR es tan importante como la definición del DOD.

Esta lista de elemento sale de un acuerdo entre el equipo de desarrollo y el Product Ownerdonde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint.

¿Por qué es importante el DOR?

Por varias razones…

Desde la práctica, una historia de usuario no está lista a la primera, necesita un tiempo de reflexión para ser completada. 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 (pienso 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, etc., 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 o técnicos con el arquitecto o Líder Técnico si hubiese y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.

Es importante determinar cuáles son las cuestiones que deben estar resueltas antes de comenzar una historia o pieza de trabajo, para evitar todos los bloqueos posibles.

 

Habrá posibles bloqueos que no puedan planearse, como puede ser una caída en el entorno de desarrollo (asumiendo que hablamos del mundo IT). Sin embargo, hay otros muchos que pueden evitarse.

Para detectar estas cuestiones, generalmente, es suficiente con realizar las siguientes preguntas a cada miembro del equipo:

¿Tienes toda la información necesaria para completar la historia sin lugar a dudas?

¿Has dado toda la información necesaria al resto del equipo para completar la historia sin lugar a dudas?

Esas son las preguntas que yo haría a la hora de saber si una HU está lista o no.

023_DOR
DOR

¿De qué dependerá la respuesta a estas preguntas?

El enfoque de la respuesta dependerá del rol.

Desde el punto de vista del Product Owner:

  • Necesita documentar la prioridad de la historia en base a sus objetivos.
  • Necesita que todas sus peticiones estén recogidas en la historia para asegurarse obtener un incremento del producto a su gusto.
  • Necesita que todas sus peticiones estén inventariadas, para que el día de la entrega pueda exigir ver dichos cambios.
  • Necesita identificar si una historia tiene alguna dependencia con cualquier otra historia anterior o alguna historia de menos prioridad en el backlog.
  • Necesita tener una confirmación de que la historia es viable desde un punto de vista técnico.

Desde el punto de vista de desarrollo:

  • Necesita que los requerimientos de su futuro desarrollo estén claros desde un punto de vista funcional
  • Necesita que los requerimientos de su futuro desarrollo estén claros desde un punto de vista de diseño (asumiendo que el desarrollo tenga parte gráfica/UI)
  • Necesita tener una confirmación de que la historia es viable desde un punto de vista técnico.
  • Necesita que los requerimientos de su futuro desarrollo estén claros desde un punto de vista técnico. Esta parte tendrá un enfoque un poco distinto dependiendo de varias cosas:
    • Tipo de desarrollo: front/back/middleware/cambios arquitecturales
    • Experiencia o madurez técnica del desarrollador: dependiendo de los conocimientos del desarrollador sobre el la tecnología o sobre el proyecto, el nivel de detalle técnico que necesite recoger la historia será mayor o menor.

Desde el punto de vista de QA:

  • Necesita que los ACs (criterios de aceptación) o casos de prueba estén claros desde un punto de vista funcional.
  • Necesita que los ACs (criterios de aceptación) o casos de prueba estén claros desde el punto de vista del diseño (si aplica).
  • Necesita tener los usuarios necesarios para realizar las pruebas.

Desde el punto de vista del Scrum Master:

  • Necesita confirmación de que todos los integrantes del equipo saben qué tienen que hacer para completar la historia con éxito.
  • Necesita asegurarse de que todos los requerimientos estén plasmados de manera transparente.
  • Necesita recordar la importancia de cumplir el DOR.

Desde el punto de vista de UX:en algunos equipos, el diseñador y el UX forman parte del equipo, en estos casos, las necesidades del equipo de desarrollo y de QA en lo relativo al diseño pueden variar.

Se pueden par dos tipos de comportamientos:

  • El diseñador y el UX funcionan al mismo ritmo y en el mismo sprint que el equipo de desarrollo: se añadirán sus tareas como subtareas de la historia. El riesgo será que cualquier trabajo de Front se verá bloqueado hasta que el diseño se complete.
  • El diseñador y el UX funcionan con 1 o 2 sprints de adelanto: se crearán tareas independientes para ellos, de tal manera que los diseños siempre estén listos en el momento de empezar el desarrollo. Esta solución suele ser la más adoptada, ya que en muchas empresas

En ambos casos, necesitarán que los requerimientos funcionales estén claros para poder completar el trabajo de ese sprint. El DOR deberá recoger este aspecto.

Terminando…

No tenemos que olvidar que el DOR evolucionará con el tiempo, a medida que se vayan detectando gaps con la experiencia a lo largo de los Sprints. Estas mejoras quedarán patentes en las retrospectivas y se refrescará la definición del DOR en las mismas. ​

Yo, no hace mucho, he tenido una experiencia muy bonita y buena haciendo este trabajo, y os puedo decir que aporta gran valor a todas las partes.

¡Feliz miércoles!

¿Cómo de útil ha sido esta publicación?

¡Haz clic en una estrella para calificarla!

Puntuación media 4 / 5. Recuento de votos: 2

No hay votos hasta ahora! Sé el primero en calificar esta publicación.

Cómo encontraste de útil esta publicación...

¡Sígueme en las redes sociales!

¡Lamento que esta publicación no te haya sido útil!

¡Permíteme mejorar esta publicación!

¿Cuéntame cómo puedo mejorar esta publicación?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.