El DoD y las Pruebas de Aceptación

Como si fuese un programador de Mátrix, no dejaba de hacer Scroll en Jira leyendo en diagonal las centenares de palabras que había en el campo «descripción» de aquella, mal llamada, Historia de Usuario. De pronto, desde el fondo de la sala, una sombra fue creciendo sobre su espalda y, finalmente, de manera sigilosa, como si se aproxima el vampiro Nosferatu, una mano le tocó el hombro y dijo… «a esa historia le faltan los criterios de aceptación». Uf, llegó el listo.
¿Pero los Criterios de Aceptación o el DoD?

Criterios de Aceptación

Los Criterios de Aceptación, o Condiciones de Satisfacción, de una Historia de Usuario (o un item de manera general) normalmente refieren a escenarios de prueba para comprobar la Historia de Usuario una vez implementada. Hablan de su comportamiento esperado una vez implementada. De hecho, los Criterios de Aceptación complementan la información, funcional, de la Historia de Usuario.
A los Criterios de Aceptación hay quien los llama Pruebas de Aceptación, y muchas veces se utilizan como sinónimos, aunque, teorizando mucho hay quien te puede decir que no son lo mismo, pero en el día a día suelen ser sinónimos.
Los Criterios de Aceptación, o las Pruebas de Aceptación, por ejemplo, refieren más a escenarios de Test y, típicamente, los puedes ver escritos en Gherkin, bajo la llamada «especificación con ejemplos» (no me meto mucho en esto para no extender el post y porque hay varios post sobre ello, como entendiendo qué es BDD (Behavior-Driven Development) (I) o ¿ATDD? ¿BDD?… ¿Cómo? Aclarando el lío de siglas en Testing).
Si nos metemos en terminología, y para no enfadar a los académicos de la Real Academia del Agile, también hay quien diferencia a las pruebas de Aceptación de los Criterios de Aceptación llamando a los Criterios de Aceptación Definition of Done…

Definition of Done

Aunque suene raruno, la traducción de DoD sería algo así como Definición de Terminado. Y el DoD vendría a ser una lista de condiciones que debe cumplir una historia de usuario, una vez implementada, para que el equipo la considere terminada.
¿Qué suelen ser condiciones en un DoD? Pues cada uno debiera buscar las que mejor le vengan, pero aquí, si miro, por ejemplo, en estas Historias de Usuario que tengo delante veo cosas como, cobertura de pruebas unitarias, si a habido «pair review», umbrales de métricas (en este caso en Sonar), etc.

¿Diferencias entre el Definition of Done y los Criterios de Aceptación?

Dicho lo anterior, deberían estar claros, no obstante convendría resaltar que, típicamente, los criterios de aceptación son específicos para cada Historia de Usuario, mientras que el DoD puede ser común para varias Historias, ya que refiere al incremento, a cómo queda el producto una vez que esas Historias le son incorporadas. Aunque esto no es una regla inamovible, ya que depende del producto, o productos, con los que trabaje el equipo.
Por continuar con las aclaraciones, los antiguos del lugar pueden explicarte que el DoD vienen a ser los viejos, ojo, que suelto la palabra, Requisitos, ejem, no funcionales, mientras que los criterios de aceptación vienen a ser las pruebas funcionales de aceptación.
En cualquier caso, ambos, tanto el DoD como los criterios de aceptación deben estar listos para considerar que una Historia de Usuario está terminada.

Terminando, no te pierdas en terminología…

Tres términos relacionados, que hay quien usa como sinónimo: criterios de aceptación, pruebas de aceptación y Definition of Done.
Yo no me complico la vida, uso Pruebas de Aceptación (como escenarios funcionales idealmente en Gherkin) y DoD, como condiciones de carácter más técnico y no funcionales. Pero, eso si, es importante resaltar el uso de esas dos especificaciones, de manera separada, para dejar bien clara una Historia de Usuario y, ojo, haciéndolo con cuidado para no caer en Lado Oscuro y acabar escribiendo «sábanas» de texto que acompañan a una Historia de Usuario (interacción por encima de documentación).
… ya se fue Nosferatu.

5 comentarios en “El DoD y las Pruebas de Aceptación”

  1. Muchas veces nos pasa que DoD puede cambiar con el tiempo, por lo cual se debe actualizar, siempre que sea necesario y colabore con los objetivos del proyecto, obviamente, nunca en medio de un Sprint. Muchos aprovechan la ceremonia de retrospectiva para actualizarlo, siempre y cuando sea para mejorar el desarrollo del trabajo, inclusive, dandole una mejor «dinámica o ritmo» al equipo. El DoD debe colaborar en que el trabajo fluya, que no sean piedras para impedir desarrollar un trabajo con buena calidad.

  2. Marco Antonio Alducin Garcia

    Debo reconocer que el termino «DoD» no lo conocía, pero la verdad se me es tan complicado utilizarlo, ya que es mas viable utilizar «Criterios de Aceptación» ya que considero que es una manera mas fácil de identificarlo.

  3. Entiendo que como miembro del equipo no puedo dar por terminada una historia de usuario si no se cumplen los criterios de aceptación, pero para darla por terminada se tienen que cumplir otros condicionantes que están incluidos en el DoD

Deja un comentario

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

Share This
Ir arriba