A veces tengo la sensación que en los equipos se tiene el Definition of Done (en adelante: DoD) como mero trámite. Queda muy bonito entre nuestra documentación de equipo… pero en el día a día, parece que el equipo se olvida de que existe.
En estos últimos días le planteé a un equipo si realmente lo necesitaban. La respuesta fue que no, y yo estaba de acuerdo, aunque tuve que dejar claro el motivo, eso es lo más complicado.
Da igual en el método que trabajemos, cuando decimos que hemos terminado algo ¿qué queremos decir con eso?; ¿significa que está en producción? ¿significa que lo hemos dejado documentado? ¿significa que lo hemos probado?…
La teoría dice del DoD que «es el entendimiento compartido en el equipo, de lo que significa que un trabajo está terminado, de esta forma aseguramos transparencia«. Así que lo que hacemos en el equipo es intentar definir desde un inicio lo que sería nuestro DoD.
¿Qué interviene en un DoD?
Podría pasar que una parte del DoD viniera definida por la propia empresa o el departamento, por una forma unánime de trabajo.
Por ejemplo; el desarrollo que implica el ticket debe estar subido a producción.
Y por otra parte, las cosas que acuerde el propio equipo
Por ejemplo; haber documentado la solución técnica aplicada en nuestro lugar de documentación.
Mientras lo definimos, seguramente nos daremos cuenta de que quizá no todos los tipos de tarea puedan seguir los mismos criterios cuando éstos se establecen, o que incluso un mismo tipo de tarea pueda no cumplirlo en algún momento concreto.
Por ejemplo; imaginemos que una historia de usuario, por el motivo que sea, no requiera que se guarde documentación técnica, eso sería una excepción al último ejemplo.
Hay equipos con DoD muy fáciles (o ellos mismos lo hacen fácil :-)) y equipos en los que salen muchísimas casuísticas. En ambos casos recordemos que no es algo estático sino que es un artefacto que puede ir cambiando con el tiempo.
Cuando el DoD es fácil, corto o llevadero, no suele haber problemas, pero cuando no es así nos pueden pasar dos cosas:
- El equipo considera que es muy complicado tener el Definition of Done adecuadamente escrito, se hace una bola muy pesada y se olvida
- Un Definition of Done tan largo puede ser inviable tenerlo en cuenta cada vez que queramos finalizar una tarea.
En ambos casos el equipo dejará de usarlo. ¿Eso se debe hacer?
¿Es obligado usar el Definition of Done?
Cuando usamos algo es porque nos aporta un beneficio, de lo contrario, ese algo no evolucionará . Y ¿cuándo le vemos el beneficio a algo? cuando nos cubre una necesidad o mejora nuestro estatus. Y ¿cuándo cubrimos una necesidad o mejoramos nuestro estatus? Cuando algo no funciona del todo bien.
Ahí está la clave, pensemos si hay algo que no nos funciona bien. En relación al DoD podríamos encontrarnos con situaciones que claman a gritos tener uno, por ejemplo:
- Los dailies se alargan cada día porque no nos ponemos de acuerdo en si una tarea está terminada o no.
- Llegamos a la Review, y lo que unos pensaban que estaba terminado y listo para mostrar, resulta que no lo está, aún estando las tareas en la columna «Done» de nuestra pizarra.
- …
Si esto no sucede, y no tenemos definido un «Definition of Done», no hace falta definirlo a la fuerza. Lo que ocurre es que los miembros del equipo, pese a cuantas casuísticas pueda haber, seguramente lo tienen todos claro en mente, y a su manera se entienden. En ese caso no compliquemos las cosas; si no hay necesidad de resolver un problema, pongamos foco donde sí lo haya.
Gracias por tu aportación. Feliz semana.