¿Cuál es la diferencia entre la definición de Done (DoD) y la definición de Ready (DoR) en los procesos ágiles?

Nunca se hace nada, solo está listo para el siguiente paso. En un proceso ágil, cada Definición de Listo (DoD) debe coincidir con una Definición de Listo (DoR) en algún lugar aguas abajo en el flujo de valor. La diferencia entre las dos definiciones es solo una cuestión de perspectiva.

Considera esto: estás en la oficina. Personas aleatorias se acercan a ti, y cada uno de ellos tira el trabajo a tu escritorio. Antes de que te des cuenta, tienes una acumulación de 3 pies de altura y en aumento.

¿Qué puedes hacer? Limite el trabajo entrante estableciendo una Definición de Listo: de ahora en adelante, aceptará solo artículos que cumplan con ciertos criterios, siendo el más obvio: “¿Está esto en la descripción de mi trabajo?” Sí, es cierto, su DoR lo hará consisten en criterios de aceptación .

¡Uf, eso está mejor! Ahora puedes hacer algo de trabajo. Pero, ¿cómo se determina cuándo está realmente “hecho”? Fácil, configura otro conjunto de criterios: una definición de hecho. Ahora está listo para abordar el trabajo un elemento a la vez. Entras rápidamente en la zona donde el trabajo fluye rápida y suavemente. ¿Y qué haces cuando terminas con un artículo? Tire del siguiente elemento de trabajo, ya que como lo expresa el Manifiesto “Culto de hecho”:

Lo importante no es terminar, sino hacer otras cosas.

Al final del día, has hecho un montón de trabajo y conduces a casa satisfecho.

Al día siguiente, sin embargo, se desata el infierno. Sus compañeros de trabajo, a quienes entregó sus resultados ayer, están indignados. “¡Tu concepto está incompleto!”, Se quejan. “¡Tu código tiene errores!”, Gritan. “¡Tu trabajo es inútil!” Es su veredicto final.

Como resultado, su Definición de Hecho chocó contra una pared. A nadie le importan tus criterios de aceptación. Para citar nuevamente el Manifiesto “Culto de hecho”:

Hecho es el motor de más.

Y más es lo que los destinatarios de su trabajo harán con él una vez que lo asuman para su posterior procesamiento. El concepto que hiciste será implementado. El código que escribiste será publicado. El trabajo que hiciste será utilizado por personas que solo se preocupan por sus criterios de aceptación, porque no les gusta hacer las cosas dos veces. Y ciertamente no están preparados para hacer tu trabajo. Entonces descubres que han establecido su propia Definición de Listo y rechazaron tu aporte. Todo su trabajo ahora está en tierra de nadie entre su DoD y su DoR.

Esto suena como un buen momento para conversar con ellos. ¿No tendría más sentido hacer coincidir su Definición de Listo con su Definición de Listo? De manera similar, en lugar de descartar cualquier trabajo que se presente simplemente porque no se ajusta a su Definición de Listo, podría intentar combinar su Definición de Listo con la Definición de Listo de las personas que vienen antes que usted, es decir, aguas arriba en el flujo de valor.

Conclusión: habla con tus vecinos. Es posible que descubra que no necesita una definición de Listo, solo una definición común de Listo. Porque …

Nunca se hace nada, solo está listo para el siguiente paso.

Definición de Listo (DoR)

DoR es un artefacto que crea el equipo que contiene el conjunto de condiciones mínimas que debe cumplir una historia de usuario antes de que el equipo de desarrollo lo considere “Listo para trabajar”. El criterio se establece para garantizar que el equipo de desarrollo no ponga en peligro el éxito de su sprint al comprometerse con una ‘trampa para osos’, es decir, requisitos ambiguos, criterios de aceptación no bien definidos, etc.

Elementos de ejemplo que pueden incluirse en el DoR:

• Historia de usuario definida
• Criterios de aceptación definidos para la historia del usuario
• La historia se acompaña de los modelos de requisitos necesarios (por ejemplo, diagramas UML, diagramas de casos de uso, diagramas de flujo de datos, etc., use lo que agregue valor al proyecto)
• El elemento de la cartera de pedidos ha sufrido un refinamiento de la cartera de pedidos al menos dos veces
• La historia ha sido dimensionada

Definición de Hecho (DoD)

La definición de hecho es un artefacto que el equipo obtiene que contiene las condiciones mínimas que debe cumplir una historia antes de que una pieza de trabajo (o historia de usuario) pueda declararse hecha.

Las actividades en este DoD pueden incluir ejemplos tales como:

• La historia del usuario está codificada y revisada por pares
• Las pruebas unitarias se escriben y pasan cuando se ejecutan
• Funcionalidad probada por un marco de automatización
• Probado por QA
• No hay errores graves / errores pendientes
• Suficientemente documentado para los flujos de valor aguas abajo

Aunque estos siempre tienen la intención de ser una guía, solo tenga cuidado de no crear un enfoque de puerta escalonada a lo que de otro modo debería ser un sistema de flujo.

Proyectos, software o de otro tipo sufren el problema común de la falta de comunicación. Mientras que el cliente espera algo más, el propietario del producto tiene una comprensión diferente. Luego están los desarrolladores que a veces tienen una comprensión diferente del trabajo a realizar. Con Agile, se abordan muchas de estas preocupaciones, gracias a las confrontaciones diarias y los objetivos claros establecidos antes de un sprint. Aún así, hay algunas áreas que generalmente se consideran durante el comienzo del proyecto y solo son relevantes cuando los sprints se acercan a su finalización. Una de ellas es la clara diferencia entre los criterios realizados y los criterios listos . En general, las personas usan estos términos indistintamente causando confusión evitable.

Debido a las dudas de algunos de los usuarios de nuestro software de gestión de proyectos, hace unos años publicamos una entrada en nuestro blog sobre -> Definición de Listo y Definición de Hecho: la diferencia.

Espero que nuestra experiencia te ayude.

La definición de hecho es un conjunto de reglas o criterios que el equipo adopta como una guía para cuando puedan afirmar legítimamente que una historia de usuario dada (o incluso una tarea) está “hecha” y lista para su revisión y aprobación por parte del propietario del producto. En el pasado, he visto los siguientes criterios comunes para “hecho”:

• Revisión de código completada por otro desarrollador;
• Pruebas unitarias automatizadas escritas y en ejecución;
• Pruebas de humo realizadas en entornos de desarrollo / etapas;
• QA cerrar sesión o sesión de programación emparejada;
• Cumple con los criterios de aceptación establecidos en la historia.

La Definición de Listo es un conjunto de reglas o criterios que el equipo adopta como guía para cuando una historia se puede mover legítimamente de la cartera de pedidos a un Sprint, ya sea durante la Planificación de Sprint o durante un Sprint donde todas las historias comprometidas se han completado. Sinceramente, rara vez he visto esto adoptado en la práctica, pero podría ver que se aplican los siguientes criterios:

• La historia ha sido revisada y estimada por el equipo;
• La historia está completa en formato: el usuario X necesita Y para poder Z;
• Los criterios de aceptación son claros y acordados;
• El propietario del producto ha aprobado la historia.

Ambos tienen el propósito de compensar el hecho de que la mayoría de las prácticas ágiles se ejecutan contra marcos sueltos que tienen pocas reglas, pero que los equipos generalmente pueden acordar un conjunto mínimo de requisitos para llamar a algo “hecho” o “listo”. La parte más importante aquí es que el equipo decide estas definiciones; no son algo forzado en el equipo por una fuerza externa.

Una ‘ definición de hecho ‘ es una lista de requisitos de calidad que un PBI debe cumplir antes de que un desarrollador pueda decir que el PBI está ‘hecho’ (completado)
por ejemplo, compilaciones de código, todas las pruebas de unidad pasan, código revisado por otro miembro del equipo, implementado continuamente en UAT
http://rules.ssw.com.au/Manageme …

Una ‘ Definición de Listo ‘ es una lista de requisitos que un PBI debe cumplir antes de poder agregarlo a un Sprint.
Por ejemplo, tiene criterios de aceptación, tiene suficientes detalles para que el equipo actúe, tiene valor comercial y esfuerzo asignado, está en el estado ‘Aprobado’
Esto generalmente lo hace el propietario del producto (con la ayuda del equipo de desarrollo) como parte del refinamiento de la cartera de pedidos antes de la reunión de planificación de sprint.
http://rules.ssw.com.au/Manageme …

Definición de Hecho : Criterios que debe cumplir una historia de usuario para que el desarrollo esté terminado y se pueda enviar. O incluso ya enviado.

Definición de Listo : Criterios de una historia de usuario que debe cumplirse para comenzar a desarrollar aka. llévelo al sprint en la reunión de Panning.

DoR: obligación contractual que debe cumplirse antes de comenzar un sprint.

DoD: obligación contractual que debe cumplirse al final del sprint.

DoD en una empresa de software:
http://leansourcing.it/dod-defin …