Definition of Done
Empieza a terminar tareas como toca
Terminar cosas es una de las tareas más difíciles que hay. Casi terminar lo que estás haciendo es sencillo, estás motivado por los resultados que promete. Pero, una vez obtenidos de manera completa o parcial, terminar y llegar hasta el final se siente como un obstáculo que te impide continuar con la siguiente tarea.
Como Tom Cargill de Bell Labs avanzó en los años 80:
El primer 90% del código representa el 90% del tiempo de desarrollo. El 10% restante del código supone el 90% restante del tiempo de desarrollo.
Y es que terminar tareas, sobre todo en software, no solo es lo más costoso, sino también, en muchos aspectos, lo más importante.
¿Qué es terminar tareas?
A parte de la poca motivación que tiene acabar tareas, muchas veces el problema también reside en que no está del todo claro qué significa acabar algo. O incluso puede que diferentes personas tengan concepciones muy diferentes de qué entienden por algo que está terminado.
¿Si ya está aportando el valor esperado, está terminado? ¿Si ya no lo vamos a tocar, está terminado?
El primer paso para saber si hemos terminado algo es saber qué consideramos como terminado. Este consenso sobre el estado de la tarea se suele llamar en inglés Definition of Done (en español es Definición de Hecho pero es que no me gusta nada 😅).
Definir un buen DoD es esencial para tener claridad sobre cuando hemos terminado una tarea y podemos pasar a la siguiente. Tener claro esto y que lo tenga claro todo el equipo (y negocio) es esencial para cumplir expectativas y reducir los posibles malentendidos que pueda haber.
Además, sirve como un seguro de calidad. Por ejemplo, definiendo las cosas que hemos de hacer antes de dejar un código productivo para la posteridad antes de continuar a la siguiente tarea hace que también nos centremos en la mantenibilidad a largo plazo de ese código y previene potenciales deudas técnicas y complejidad accidental.
Y sobre todo aporta transparencia sobre lo que estamos haciendo. Teniendo un DoD compartido tenemos absoluta claridad sobre cuando una tarea está terminada o que falta para que la consideremos como tal. Esto ayuda a que terceros o miembros de nuestro propio equipo gestionen de mejor forma las posibles expectativas que hay sobre esa parte del producto.
¿Cómo definir un buen DoD?
Definir Definitions of Done es una habilidad que se obtiene con el tiempo y con el trabajo continuo con nuestro equipo. Aquí te dejo algunos consejos para definir DoDs robustos que ayuden a gestionar nuestras tareas:
- Incluye a todo el equipo: esta es la más importante de todas, un DoD tiene que estar consensuado por todo el equipo para que las expectativas de todos estén bien gestionadas. Debemos considerar los criterios de completitud de las partes implicadas. Entre ellas están los requerimientos del producto, los criterios de calidad tanto de producto como técnicos, la documentación asociada (si hiciera falta), etc. Pero es importante que todos se vean representados es este DoD y sus necesidades se vean abordadas.
- Crystal Clear: sé explícito, claro y conciso. Ir al grano y hacer el DoD todo lo claro posible y fácil de entender evitará posibles malentendidos.
- Cubre todos los aspectos: no te fijes solo en los requerimientos de producto o los aspectos técnicos más claros. Haz el esfuerzo de pensar en la lista de cosas que tienen que estar hechas sí o sí para considerar la tarea como terminada. Ten en cuenta todos tus criterios de calidad y los valores de tu equipo para ello.
- Diferentes tareas requieren diferentes niveles de DoD: no hace falta ser súper detallado en todas las tareas, invierte más esfuerzos en cosas importantes y define DoDs más laxos para tareas rutinarias. Y recuerda que no hacen falta DoDs para todo, empieza a implementarlos allí dónde te sientas más cómodo.
- Asegúrate de que los criterios del DoD son medibles y verificables: si tienes dudas si una de las condiciones está cumplida o no es que no está bien definida desde un principio. No debería haber duda ni discusión.
- Alinea los DoDs a la realidad de tu equipo: DoDs demasiado exigentes pueden hacer que la entrega de tu equipo se vea afectada en el estado y contexto en el que se encuentra en ese momento. Ves poco a poco y adapta los niveles de exigencia para que garanticen la calidad sin comprometer la viabilidad. DoDs poco realistas y conseguibles pueden llevar a frustraciones y discusiones contraproducentes.
E Itera, como todo, nunca lo hacemos bien a la primera. Experimenta y prueba para encontrar la fórmula que mejor se adapte a tu equipo. Poco a poco iréis cogiendo práctica y mejorando.
Terminar cosas es algo que se nos hace difícil. Si al menos tenemos claro dónde está el horizonte al que queremos llegar se nos hará algo más fácil. ¡Prueba, itera y empieza a terminar tareas como es debido!
Ejemplo de DoD
Aquí os dejo un posible DoD para dejar más claros los puntos y enseñar cómo podría ser un ejemplo de una historia de usuario cualquiera. Nota: es solo un ejemplo y dependiendo de la épica, historia o tarea podría ser más o menos extenso.
- Producto:
- Cumple con los requisitos de aceptación de la nueva funcionalidad (estarían listados).
- Se ha hecho una demo suficiente con el resto del equipo sobre los nuevos cambios.
- Se ha hecho una prueba de validación con un grupo seleccionado de usuarios.
- Código:
- El código ha sido escrito siguiendo los estándares establecidos.
- Se ha hecho TDD para cubrir el código desarrollado.
- El código ha pasado por un refactor final que garantice su mantenibilidad futura.
- El código se ha hecho en pairing o ha sido revisado por al menos un compañero de equipo.
- El código tiene métricas asociadas para identificar posibles problemas de rendimiento.
TL;DR
Los Definition of Done (DoD) son un componente esencial para superar los desafíos asociados con la finalización de tareas, especialmente en el desarrollo de software. El DoD no solo marca el final de una tarea, sino que también actúa como un garante de calidad, facilita la transparencia y gestiona expectativas.
La clave para un DoD efectivo radica en el consenso integral del equipo, abarcando requisitos del producto, criterios de calidad técnica y de producto. La claridad, concisión y la medición verificable de los criterios son fundamentales para evitar malentendidos y garantizar un cumplimiento sin dudas.
Hemos de adaptar el nivel de detalle del DoD según la importancia de la tarea. La alineación con la realidad del equipo es crucial para evitar imposiciones excesivas o estándares poco realistas. La iteración continua es una práctica clave para perfeccionar el proceso de definición de DoDs con el tiempo.
En conclusión, el DoD proporciona una guía clara para superar la dificultad de finalizar tareas. Se insta a los equipos a experimentar, iterar y abordar la finalización de tareas de manera efectiva, utilizando el DoD como una herramienta esencial en su desarrollo.