¡Nuevo episodio de Scrum Manager Podcast! También disponible en Spotify e iVoox.
En el episodio de hoy hemos querido resolver algunas dudas sobre la Definition of Done (DoD) o definición de «hecho». En la parte práctica hablamos sobre:
- La diferencia entre los criterios de aceptación y la definición de «hecho».
- Si tiene más sentido incluir las pruebas con usuarios en la DoD o en los criterios de cada historia.
- Cómo elaborar la definición de «hecho» para un proyecto artístico o con un importante componente estético.
Recordad que las transcripciones de todos los episodios estarán disponibles en el blog, e iremos subiendo a ritmo de sprint: cada par de semanas. ¡No dudéis en sugerirnos temas sobre los que os gustaría profundizar en los comentarios!
Transcripción
¡Hola y bienvenidos! En el episodio de hoy hablaremos de la definición de «hecho» y resolvemos dudas frecuentes sobre ésta y los criterios de aceptación. ¡Comenzamos!
Definition of Done: qué es
Definition of Done (DoD), en español «definición de «hecho»», es la descripción de las condiciones que debe tener un incremento para considerarlo terminado. Es explícita y conocida por todo el equipo. Dependerá del ámbito del negocio, pero algunos de los aspectos más habituales que se incluyen son funcionalidad, calidad, pruebas, documentación y retroalimentación del cliente. Es decir:
- Todas las tareas o historias implementan la funcionalidad requerida de manera correcta.
- Todas se han implementado con alta calidad técnica, cumpliendo con los estándares necesarios.
- Todas se han probado y los errores encontrados se han resuelto.
- Todo ha quedado documentado adecuadamente para su fácil comprensión y mantenimiento.
- Y el cliente ha revisado y aprobado el incremento.
También es habitual, en empresas de informática, que la Definición de Hecho incluya criterios de seguridad, privacidad, y compatibilidad; es decir, que el código escrito se pueda integrar con el resto del sistema, que esté escrito de forma compatible. Es importante que el código cumpla con los estilos y directrices del proyecto.
Definition of Done: para qué sirve
La definición de «hecho» incluye criterios y acciones que agregan valor demostrable, y puede ir evolucionando conforme se aprende, para mejorar tanto los entregables como la forma de trabajar. Ayuda no sólo a mantener un nivel de calidad que beneficia al cliente y a los usuarios, sino también a controlar el avance del proyecto. Porque si los incrementos se van entregando sin una buena Definición de Hecho aparecen problemas.
«Hecho» debe significar que está listo para usarse: para integrarse en el producto o sistema. Eso no sólo requiere que el incremento funcione, sino que esté probado, que sea seguro, etcétera.
Sin una buena Definición de Hecho podemos producir una nube de trabajo no del todo terminado o en un estado incierto, que complica las planificaciones, y genera riesgos ocultos que pueden poner en compromiso la fecha de entrega y la calidad del producto.
Aunque en la teoría puede parecer un concepto fácil, en la práctica suscita dudas. A continuación vamos a ver algunas de ellas, como la diferencia con los llamados «criterios de aceptación», o dónde encajan los tests con usuarios.
¿Qué diferencia hay entre los criterios de aceptación y la Definición de Hecho?
El nivel de concreción es distinto. Los criterios de aceptación se centran en cada elemento del backlog por separado y la definición de «hecho» atañe a los incrementos, en general. De modo que es normal, por ejemplo, que la Definición de Hecho incluya un criterio como «que todas las historias de usuario cumplan con sus criterios de aceptación».
Quizá el enfoque más útil para entender la diferencia entre «definición» y «criterios» sea considerar de dónde viene cada uno:
Criterios de aceptación
Los criterios de aceptación están conectados a las historias de usuario, y son algo con lo que están familiarizados los product owners. En muchos tutoriales sobre historias de usuario se recomienda incluir criterios de aceptación en éstas. Y suelen expresarse en forma de lista, como un flujo o una serie de criterios. El propietario del producto los explica durante la reunión de planificación del sprint, y cubren lo que el cliente espera de la historia.
Por ejemplo, si programamos un carro de la compra para una tienda on-line: el cliente debe poder añadir productos al carro, el cliente debe poder modificar la cantidad de cada producto, debe poder eliminar productos, introducir códigos de descuento… Todo esto son criterios de aceptación. Son aspectos fundamentales sin los cuales esa historia no podrá darse por aprobada. Y hay que conocerlos para que el equipo pueda estimar y desarrollar la historia correctamente.
Definition of done
La Definición de Hecho, en cambio, está vinculada a los incrementos. El equipo sabe bien que, aunque ese carro de la compra funcione, aunque todas esas acciones sean posibles, el trabajo no acaba ahí. Una historia puede estar completada, pero eso no constituye un incremento. Por supuesto, las historias incluidas en el sprint deben ser funcionales, y lo que define si lo son o no son los criterios de aceptación. Pero eso no es suficiente para entregárselo al cliente. Siguiendo el mismo ejemplo: para completar el incremento habrá que comprobar que el carro funciona en diferentes navegadores, que el código es aceptable y está bien comentado o documentado, que el sistema de pago es seguro… Hay muchas otras tareas necesarias.
La Definición de Hecho se asegura de que los incrementos están «hechos» de verdad: para no pensar que ciertas cosas pueden «dejarse para luego» y acabar con una deuda técnica de la que nos arrepintamos. Un incremento «hecho» es una entrega que se puede dejar cerrada con tranquilidad.
Los criterios de aceptación en cambio se refieren a requisitos concretos del product backlog que el propietario del producto concreta para el equipo.
En cuanto al formato, no existe un modelo estándar para escribir ni los criterios de aceptación ni la Definición de Hecho. Pueden apuntarse utilizando lenguaje natural, tal y como el product owner o la persona del equipo se exprese, o acordar entre todos un formato cómodo y que sirva a las necesidades del equipo. Lo que sí es importante es hacer un esfuerzo por ser concisos y descriptivos al sintetizar lo que se ha acordado durante las conversaciones.
¿Dónde tiene más sentido incluir las pruebas con usuarios, en la definición de «hecho» o en la propia historia?
La respuesta es… sí. Tanto la definición de «hecho» como los criterios de una historia de usuario son buenos lugares para incluir las pruebas con usuarios.
Podemos decidir que éstas son un requisito para dar cualquier incremento como «hecho», o limitarnos a especificarlo en ciertas historias que lo requieran. En cualquiera de los dos casos, a nivel de criterios podremos describir siempre con mayor precisión qué esperamos de esas pruebas. Las opiniones y acciones de los usuarios permitirán confirmar si la funcionalidad implementada se corresponde con lo que esperábamos de la historia o no. Y ayudará a identificar problemas antes en el proceso de desarrollo.
Dónde incluyamos las pruebas de usuario va a depender de nuestro proyecto, de cómo queramos construirlo y de los medios de los que dispongamos. Por un lado, hacer pruebas con usuarios no requiere de mucho, y no es necesario hacerlas con un gran número de personas. Siempre son aconsejables. Pero al final queda al criterio del equipo y del cliente dónde incluirlas, y si hacerlas en todos los incrementos o sólo para ciertas historias.
Por último, vamos a hablar de las opiniones más subjetivas.
¿Qué definición de «hecho» podría tener sentido en un proyecto artístico, o en un proyecto donde tiene mucho peso lo estético?
La subjetividad puede ser un desafío. En cualquier proyecto contamos con ella, pero en el ámbito artístico o estético el reto es mayor. Entre otras cosas, porque puede ser difícil articular estos criterios en una definición de «hecho».
Como ya hemos dicho, esta definición no sólo se refiere a que el incremento funcione, sino que también atiende a la calidad y al cumplimiento de ciertos estándares necesarios para que el proyecto sea considerado exitoso.
A continuación vamos a ver unos pocos ejemplos de cómo podría ser la definición de «hecho» en un proyecto con un alto componente artístico:
- La persona o el equipo responsable de la obra la ha revisado hasta considerar que cumple con los objetivos estéticos y de calidad deseados.
- La dirección creativa o el equipo de dirección ha revisado y aprobado la obra como satisfactoria.
- La obra se ha exhibido en un lugar adecuado y se ha alcanzado el objetivo de difusión o la reacción deseados.
En cuanto a cuáles son esos «objetivos estéticos y de calidad deseados», éstos se irán perfilando cada vez más durante la colaboración, y se pueden concretar durante la planificación del sprint en los criterios de aceptación de cada historia. Puede que sea difícil definir con palabras lo que el cliente busca, pero siempre podemos buscar ejemplos, dibujar prototipos, esbozar… Y si estamos trabajando de forma ágil eso quiere decir que hay colaboración constante y directa con el cliente. Cuando el equipo tiene dudas, lo más productivo es preguntar directamente, y no asumir respuestas que pueden no ser ciertas.
Es normal que la reunión de planificación no dé tiempo suficiente para presentar al product owner un ejemplo del que podría ser el diseño, pero se puede trabajar al principio del sprint con bocetos y prototipos; lo que el equipo artístico considere que es el mínimo necesario para que el cliente o el product owner lo revise y apruebe si ésa es la dirección en la que quiere seguir, si se ha entendido lo que busca o no.
Esperamos que este episodio haya ayudado a entender mejor qué son la Definición de Hecho y los criterios de aceptación, y para qué sirven. Recordamos que la Definición de Hecho no es un acuerdo rígido, sino que se adapta y mejora durante el desarrollo, conforme se van completando iteraciones. Y que puede incluir criterios de todo tipo para garantizar que los incrementos aporten valor y sean de calidad: sobre la funcionalidad, pruebas con usuarios, criterios de calidad, seguridad, validación de elementos estéticos, documentación…
Si queréis saber más, en la transcripción del podcast de nuestro blog encontraréis información adicional y enlaces sobre la definición de «hecho» y los criterios de aceptación.
Volveremos con el próximo episodio en lo que se tarda en hacer un sprint: un par de semanas. Hasta entonces podéis encontrarnos en Twitter, LinkedIn, y en scrummanager.com.
¡Mucha suerte con vuestros proyectos y hasta la próxima!
Un comentario en “Qué es la Definition of Done o definición de «hecho»”