"¿Está hecha esta tarea?"
Para responder a esta pregunta aparentemente sencilla es necesario comprobar si un incremento de producto o elemento se ha completado o está en curso. Pero esto solo funciona si un equipo y sus partes interesadas lo definen explícitamente como "hecho".
En las metodologías de gestión ágil de proyectos como kanban o scrum, "hecho" hace referencia a una columna de un tablero visual con los elementos completados. Con una definición clara de "hecho", los equipos ágiles, incluidos los equipos de DevOps y scrum, pueden completar sus tareas de manera más eficaz.
En esta guía se explica el significado de la definición de "hecho" (DoD) en las metodologías ágiles y cómo crear una para que los proyectos sean más eficaces y valiosos.
Entender la definición de "hecho" en la metodología ágil
La definición de "hecho" es un conjunto de criterios que debe cumplir un incremento del producto para que el equipo lo considere completo y listo para los clientes. Los miembros del equipo tienen una idea común de cuándo un incremento del producto está listo para su publicación, incluso cuando el incremento es grande y se compone de muchos elementos. Al definir claramente lo que significa "hecho" en el proyecto, un equipo ágil puede centrarse en ofrecer valor en cada sprint y en reducir al mínimo el trabajo que hay que repetir.
Es importante tener en cuenta que la definición de "hecho" no la crea una sola persona, sino que la acuerda todo el equipo del proyecto, incluidos los desarrolladores, los evaluadores, los propietarios del producto y otras partes interesadas. Esto garantiza un proceso más fluido durante los sprints, ya que todo el mundo utiliza la misma definición y las listas de comprobación que pudiera haber para marcar los elementos como finalizados.
"Si tienes que hacer entregas a otros equipos, asegúrate de que cuando hayáis terminado, hayáis hecho todo lo necesario para garantizar que el otro equipo obtenga buenos resultados", indica Mark Cruth, orientador de trabajo de Atlassian. "Colabora con los demás equipos del flujo de valor para averiguar qué debes incluir en tu definición de 'finalizado' para ayudarles".
Ejemplos de definición de "hecho"
La definición de "hecho" de un proyecto varía según el tipo de proyecto y el equipo implicado. Los siguientes ejemplos de DoD ilustran cómo difieren estas definiciones entre los distintos tipos de proyectos:
En un proyecto de desarrollo de aplicaciones móviles, la definición de "hecho" puede incluir:
- Todas las imágenes están comprimidas.
Todo el código está minificado y comprimido con Gzip.
En un proyecto de desarrollo de software, estos podrían ser los criterios de la definición de "hecho":
- Todo el código se ha probado exhaustivamente mediante pruebas unitarias, de integración y de extremo a extremo.
El incremento del producto se ha implementado en un entorno de ensayo y el equipo lo ha probado.
Un proyecto genérico podría incluir lo siguiente en su definición de "hecho":
- Se han resuelto todos los errores.
Se ha redactado y editado toda la documentación de la publicación.
Definición de "hecho" y definición de "listo"
La definición de "hecho" (DoD) es un conjunto de criterios generales que determinan si el incremento de un producto se ha completado. Garantiza la calidad y la coherencia de las entregas. Los equipos suelen utilizar la DoD al final de un sprint para comprobar la calidad del incremento de un producto.
Por el contrario, la definición de "listo" (DoR) es un conjunto de criterios específicos y de bajo nivel que solo se aplican a los elementos del backlog del producto. La DoR define cuándo un elemento del backlog está listo para que un equipo trabaje en un próximo sprint. Los equipos usan la DoR durante el proceso de mejora del backlog al principio de un sprint.
¿Por qué es importante la definición de "hecho"?
Tener una DoD es fundamental para ofrecer un producto de calidad que los clientes deseen, ya que aclara cuándo un elemento se puede marcar como completo y está listo para incluirse en un incremento del producto. Una DoD bien diseñada ofrece las siguientes ventajas:
Aumenta la calidad: comprobar cada incremento del producto según los criterios de la definición de "hecho" garantiza que los equipos ágiles tengan en cuenta los objetivos de calidad durante el desarrollo del producto. Así, se asegura que se cumplan de forma constante los estándares de calidad exigidos para su publicación.
Minimiza el riesgo: seguir la definición de "hecho" minimiza el riesgo de trabajo repetido o los consiguientes retrasos que podría ocasionar, ya que el equipo sabe exactamente qué criterios debe seguir un elemento antes de marcarlo como finalizado. Esto garantiza la calidad en todas las etapas del proyecto.
Mejora la coordinación de los equipos: la definición de "hecho" es una idea común de lo que significa "hecho" en el contexto del proyecto. Así, los equipos pueden centrarse más fácilmente en las necesidades del cliente y ofrecer valor con cada sprint.
Mide el progreso: con una definición de "hecho" clara, los equipos pueden hacer un seguimiento del número de incrementos del producto que cumplen con los criterios de "hecho". Por ejemplo, las métricas de scrum pueden incluir la velocidad, que muestra cuántos incrementos del producto completados entrega una persona en un plazo determinado.
Pasos para crear una definición de "hecho"
Si bien los pasos exactos para elaborar una definición de "hecho" varían según el equipo y el proyecto, el proceso sigue un patrón similar. Estos son los pasos para crear una DoD:
1. Trabaja con el equipo adecuado
Es importante trabajar con los miembros adecuados del equipo a la hora de crear una DoD, ya que los criterios decididos definirán la idea que compartan todos los participantes. Esto significa incluir a todas las personas que deben opinar sobre cómo definir "hecho" para el proyecto: los propietarios del producto, el experto en scrum, los miembros del equipo de scrum, los evaluadores, los responsables de producto, los patrocinadores y otras partes interesadas relevantes.
Cada miembro del equipo aporta sus conocimientos en la materia al proyecto y puede evaluar qué criterios son más adecuados para su área de especialización. Si eliges a los miembros del equipo inadecuados u omites a miembros clave del equipo, es posible que los criterios de la DoD no sean tan exhaustivos y, por lo tanto, que el producto no cumpla con los estándares.
2. Establece los criterios
La tarea más importante a la hora de definir "hecho" es establecer los criterios que el equipo utilizará para el proyecto. Establecer los criterios de la DoD es crucial porque afectará a la calidad del trabajo realizado.
¿Cómo sabrán si un componente del proyecto está completo? ¿Qué condiciones indicarán que se ha realizado el incremento de este producto? Los criterios deben ser específicos, cuantificables, viables, relevantes y de duración determinada. Para elegir los criterios adecuados, el equipo debe hacerse dos preguntas principales:
- ¿Los criterios son lo bastante específicos? Evita la ambigüedad (Todo el código se ha probado); define específicamente (Todo el código se ha probado minuciosamente mediante pruebas unitarias, de integración y de extremo a extremo).
- ¿Los criterios se centran en el cliente? Un buen ejemplo de ello es "Se ha redactado y actualizado toda la documentación", lo que debería facilitar al usuario final la búsqueda de instrucciones sobre el uso del producto.
"Ten en cuenta que el hecho de que algo cumpla con los criterios de aceptación no quiere decir que se haya terminado", explica Cruth. "La definición de 'finalizado' es un conjunto de actividades que el equipo considera que hay que completar para dar por 'finalizada' la historia de usuario (lo que puede conllevar cumplir con criterios de aceptación), pero esto no quiere decir que esta se haya implementado correctamente".
3. Crea una lista de comprobación
Aunque los criterios de la definición de "hecho" pueden parecer más adecuados para equipos que trabajan en proyectos grandes, los equipos que trabajan en tareas, incidencias o errores más pequeños pueden aplicar los mismos conceptos para crear una lista de comprobación menos extensa. Una lista de comprobación para cada tarea o incidencia puede garantizar que el equipo realice un trabajo de calidad alta y constante.
4. Asigna criterios de aceptación a las historias de usuarios
Los criterios de aceptación (AC) se refieren a las condiciones que deben cumplir las historias de usuarios para que los clientes las acepten. Esto difiere de los criterios de la DoD en que se refieren a las funciones o historias de usuarios, y no a los incrementos del producto.
Pero al igual que la DoD, los criterios de aceptación también son un criterio acordado para determinar si una historia de usuario o una tarea individual están hechas. Por ejemplo, con la historia de usuario "Como usuario, quiero poder utilizar un campo de búsqueda para encontrar el producto que estoy buscando", los criterios de aceptación podrían ser:
- El campo de búsqueda está en la barra de navegación superior.
- La búsqueda comienza al pulsar el botón "Buscar".
El campo de búsqueda contiene un marcador de posición gris que dice "¿Qué estás buscando?".
5. Revisa y actualiza la DoD
La DoD no es un documento estático. Cada error que se encuentra durante un sprint es una incidencia de calidad que puede resultar de una definición poco clara de "hecho". Actualizar la DoD es fundamental para que el error no vuelva a producirse.
"La definición de 'finalizado' debe equivaler a un documento en constante desarrollo, lo que quiere decir que, a medida que se aprendan cosas nuevas sobre el trabajo, el equipo debe actualizarla", añade Cruth. "Plantéate la posibilidad de revisar esa definición de 'finalizado' cada trimestre para asegurarte de que incluya todos los elementos que consideres necesarios".
Revisa y actualiza la DoD durante las revisiones de los sprints para que siga siendo relevante para el proyecto. A medida que los proyectos evolucionan y los equipos aprenden más sobre los requisitos de los clientes, también puede ser necesario revisar la DoD para que sea viable. Asegúrate de que los miembros del equipo puedan sugerir cambios en la DoD durante las revisiones de los sprints o las reuniones de mejora del backlog.
Garantiza una definición de "hecho" bien definida con Jira
Con Jira los equipos de software pueden crear la definición de "hecho" más fácilmente. Crea campos personalizados o descarga una extensión para crear listas de comprobación para cada incidencia de Jira. Crea una definición de "hecho" diferente para cada tipo de trabajo personalizando los tipos de incidencias de Jira.
Millones de equipos ágiles de alto rendimiento confían en Jira para la gestión de programas y proyectos, desde la planificación de la metodología ágil hasta las reuniones rápidas de sprint y todo lo demás. Pruébalo gratis.
Definición de "hecho": preguntas frecuentes
¿Quién se encarga de crear la definición de "hecho"?
El equipo de desarrollo, dirigido por el experto en scrum, suele crear las DoD. Sin embargo, deberían pedir la opinión de los propietarios del producto, los evaluadores y otras partes interesadas.
¿Cuál es la diferencia entre la definición de "hecho" y los criterios de aceptación?
La DoD es un conjunto de criterios generales para determinar si el incremento de un producto se ha completado. Se aplica a todos los incrementos del producto y define la calidad general del producto.
Por el contrario, los criterios de aceptación son condiciones de bajo nivel que solo se aplican a historias de usuarios o funciones específicas. Los criterios de aceptación definen si una historia de usuario es aceptable para un cliente. Un ejemplo de DoD podría ser "Se ha redactado y actualizado toda la documentación". Un ejemplo de criterio de aceptación podría ser "Se puede acceder al enlace a la documentación del usuario desde el menú de navegación".
¿Cuáles son las prácticas recomendadas para crear una definición de "hecho"?
Define los criterios con tu equipo: definir la DoD debe ser una tarea conjunta en la que participe todo el equipo, incluidos los desarrolladores, los evaluadores, los propietarios del producto y las partes interesadas pertinentes. Al crear una DoD, habrá una idea común de lo que significa que un incremento del producto esté completo.
Dale visibilidad: la definición de "hecho" debería estar disponible y a la vista durante la planificación de sprints o cuando se vayan a hacer estimaciones de los elementos del backlog del producto. El equipo debería poder consultarla con regularidad. Imprímela y cuélgala en la pared, o inclúyela en una wiki o en el plan del proyecto.
Sé práctico y realista: la definición de "hecho" debería poder alcanzarse dentro del plazo y con los recursos disponibles. Y lo que es más importante: debe ser relevante para lo que los clientes necesitan de verdad.