Levante la mano quienes hayan iniciado un proyecto utilizando algún marco de agilidad y definieron su Definición de Terminado (Definition of Done — DoD) durante la primera iteración. ¿Hola, hay alguien ahí?
Si no levantaste la mano, no te preocupes porque según un proverbio chino
“El mejor momento para plantar un árbol fue hace 20 años. El segundo mejor momento es ahora”.
Con lo cual, sea la iteración que sea en la que te encuentres con tu equipo este va a ser el mejor momento para ponerse en acción y “plantar su primer árbol” llamado Definición de Terminado (DoD).
¿Qué entendemos por DoD?
Si con tu equipo están trabajando con historias de usuario y ya completaron todas las tareas de una de ellas seguramente estén en condiciones de afirmar que esa historia está terminada.
Pero ¿todas las personas del equipo opinan lo mismo?
Puede ocurrir que para algunas personas a la historia le falte alcanzar cierto estándar de calidad, para otras el criterio de aceptación no se cumple en su totalidad, y otras opiniones más que pueden emerger de un equipo multidisciplinario en el que, generalmente, cada persona tiene su mirada puesta en una pequeña parte del todo.
Una DoD no es más ni menos que un checklist consensuado con los requisitos fundamentales que debe cumplir cada historia de usuario para ser considerada como terminada. Para eso, el equipo va a tener la responsabilidad de ir chequeando y tildando cada requisito de la lista, una vez que todas las tareas de una historia están terminadas. Cuando toda la lista DoD está tildada podemos decir que la historia está terminada.
¿Para qué definir una DoD?
Me gusta partir del principio ontológico que dice que “vivimos en mundos interpretativos”, o sea, que cada persona observa desde su propia perspectiva de acuerdo a su historia, creencias, hábitos, experiencias, etc. y por ende nuestras opiniones sobre el mismo hecho muchas veces difieren.
Consensuar una DoD en equipo permite acotar esa brecha interpretativa y facilita la fundamentación de lo que el equipo define como “terminado” con hechos observables e identificables por cualquier persona involucrada en el proyecto.
¿Cómo definir la primera DoD?
Existen muchas técnicas y dinámicas para definir en equipo la primera versión de DoD e incluso plantillas con las que se puede partir para no empezar de cero ni “reinventar la rueda”.
En mi búsqueda de material para facilitar la construcción de la DoD en un equipo me encontré con las DoD Kards diseñadas por Kleer que están inspiradas en un ejercicio diseñado por David A Koontz. Ambos materiales me gustaron mucho y me inspiraron a diseñar este template en Mural.
Básicamente, cuenta con un conjunto de tarjetas con especifícaciones base que potencialmente podrían ser parte de la DoD. Las tarjetas están categorizadas en Review, Quality, Environments, Communication y blank (para completar por el equipo) y pensadas principalmente para equipos de desarrollo de software aunque podrían aplicar a otras construcciones en equipo también adaptando la terminología.
¿Cómo facilitar la dinámica?
Por turnos, cada integrante del equipo agarra una tarjeta y lee en voz alta la especificación de la misma y según su criterio la ubica en alguna de las circunferencias de Now!, Next o Later, cada una tiene un sentido que paso a explicar:
- Now!: la persona considera que esa especificación debería ser parte de la DoD ahora mismo y empezar a ser chequeado para considerar que una historia de usuario está terminada.
- Next: para la persona esa especificación es importante pero requiere de algún tipo de discusión o información adicional que puede conversarse en una próxima reunión. Por ejemplo, dejarla para seguir conversándola en 2 semanas.
- Later: esa especificación no parece relevante en este momento y se puede dejar para más adelante. Por ejemplo, para volver a conversarla en 3 meses o más adelante.
Al ubicar la tarjeta, la persona da una breve fundamentación de por qué considera que debe ir en Now!, Next o Later y si las demás personas comparten la mirada continua la siguiente persona con otra tarjeta.
En caso de que existan diferencias de opiniones sobre la última tarjeta ubicada, quién facilite la dinámica se ocupará de que todas las voces sean escuchadas hasta que el equipo llegue a una resolución de si esa especificación debe o no formar parte de la DoD, o seguir la conversación a futuro.
Recordemos que el objetivo de esta actividad es acordar y consensuar una primera versión de DoD, la cual podrán seguir mejorando a medida que la pongan en práctica y hagan la experiencia.
También existen las tarjetas en blanco, las cuales sirven para que la persona en su turno elija escribir una especificación acorde al proyecto y que no sea parte de las tarjetas base.
En resumen
Me parece clave que los equipos generen acuerdos claros y dediquen tiempo para compartir sus puntos de vista en busca de generar consensos y mejorar sus prácticas.
En mi opinión, la mejor fórmula para los equipos es la que surge desde adentro, de la experiementación, del aprendizaje, del animarse a cometer errores, del abrir conversaciones efectivas y oportunas, del escucharse, del ocuparse de la calidad de relaciones que están generando juntxs.
La DoD es una buena práctica para comenzar a generar esos acuerdos y consensos en equipo para acotar las brechas interpretativas entre todas las personas involucradas en el proyecto.
En mi última experiencia, el equipo de 8 personas fue capaz de consesuar su primerva versión de DoD en 2 horas (2 sesiones de 1hr) utilizando el template de Mural.
¡Espero que esta actvidad colabore en tu equipo también!
Me va a encantar que me cuentes cómo les fue a uds.
