La Definition of Done es uno de esos artefactos que aparecen en Scrum pero que no pertenecen a los 11 elementos imprescindibles: roles, artefactos y eventos. Sin embargo, juega un papel fundamental en la propuesta de trabajo de Scrum, ya que está muy relacionado con la entrega. El hacer delivery es vital en un equipo Scrum y Agile; cuando hay entrega, somos capaces de recibir feedback del usuario para saber si vamos en la buena dirección. La Definition of Done también está relacionada con la calidad del equipo, lo que nos permite un ritmo sostenido a largo plazo de entrega de valor. Y también está muy relacionada con la comunicación del equipo, ya que permite un conocimiento compartido del estado de nuestro producto, vital para la gestión de expectativas. ¡Comenzamos!
¿Qué es la Definition of Done?
Una curiosidad de la Guía Scrum es que cada vez que habla de algo “terminado” lo hace entrecomillado. El motivo es que, según donde apliques Scrum, el concepto terminado es muy relativo.
La Definition of Done es un conjunto de reglas que determinan cuándo un elemento está terminado. Terminado significa listo para poner en producción a disposición del usuario. Eso sí, la decisión de “subir” la toma el Product Owner. Por tanto, se puede aplicar a nivel de item, de categoría, o release o de Sprint. En el método Kanban, es bastante habitual que el Definition of Done se aplique a nivel de columna o clase de servicio.
El decidir cuándo algo termina es especialmente relevante en diferentes puntos de Scrum:
- Lo que está terminado podemos medirlo (software terminado como principal medida de progreso)
- Podemos inspeccionar los items terminados y adaptarnos (tomar decisiones)
- Lo que está terminado podemos llevarlo a un usuario o al mercado para saber si funciona
- Cuando un item está terminado, eliminamos la incertidumbre asociada al trabajo oculto, no queda nada restante por hacer
- A la hora de planificar, el medir nuestra capacidad de terminar items nos ayuda a entender nuestra capacidad de entrega, además de ayudarnos a gestionar expectativas.
Por tanto, el disponer de una Definition of Done y ser disciplinados para cumplirla, es clave para un equipo de trabajo.
La Definition of Done y los valores de Scrum
La Definition of Done está muy relacionada con los valores que potencia Scrum. En primer lugar, nos permite poner foco en terminar cosas en vez de hacer muchas; más vale 10 items terminados que 30 en estado doing. También está relacionado con el compromiso, ya que buscamos hacer las cosas bien y la Definition of Done se centra en acabar el trabajo y garantizar un cierto grado de calidad en nuestro producto.
La apertura gana protagonismo ya que la Definition of Done nos facilita una conversación en torno a todo el trabajo que tenemos que realizar para finalizar un item. Si tenemos que debatir sobre el rendimiento de un miembro del equipo, la Definition of Done objetiviza la conversación, luego nos ayuda con el respeto dentro del equipo. Y por último, la Definiton of Done es tremendamente dura en muchos equipos, y por tanto, requiere de mucho coraje para que afrontemos un desarrollo software sano y de calidad.
La conclusión que sacamos es obvia, puede que la Definition of Done no sea un elemento obligatorio, pero desde luego parece lógico que lo usemos dado lo bien que se integra con las bases de Scrum.
Lo medio-terminado no se puede medir
La Definition of Done busca que terminemos las cosas. Que antes de arrancar nuevo trabajo, finalicemos el trabajo en curso. De esta manera, podemos medir la cantidad de trabajo terminado por unidad de tiempo (normalmente se mide por Sprint). Con el tiempo, esta métrica nos permite hacer predicciones sobre posibles fechas de release. Y todo esto es vital a la hora de que gestionemos las expectativas de nuestros interesados. Para un desarrollo empírico de producto, necesitamos acumular experiencia y lo que está terminado se puede medir para ganar aprendizaje.
Una métrica muy habitual en la gestión tradicional de proyectos es el porcentaje de avance. El porcentaje de avance se calcula de manera muy arbitraria. “Hemos firmado 10 meses y estamos por el mes 9, así que vamos por el 90%”. Cuándo termina el mes 10 y no hemos acabado el proyecto, entonces el avance pasa al 92 %, y después del 93, 94… ¡No tenemos verdadero control de cuándo acabaremos!
A esto lo hemos bautizado como “el síndrome del 90%”, que consiste en que, cuando creemos que una tarea está casi hecha, decimos que estamos al 90%. Sin embargo, el 10% restante a veces nos lleva más tiempo que el 90% anterior (la integración final suele ser problemática).
En Scrum, utilizamos la regla 0-100. Si algo no se ha terminado está al 0%, y si está terminado, entonces se ha alcanzado el 100%. Así, evitamos hacer estimaciones parciales que, casi siempre, son inventadas y nos engañan sobre el estado real de las tareas. Una fábrica no mide cuántos volantes pone o ruedas sino cuántos coches termina por unidad de tiempo, su capacidad de producción y, a su vez, de venta.
La calidad está en juego con el Definition of Done
La Definition of Done es el elemento que introduce Scrum para garantizar que nuestro producto tiene calidad. Cuidado, no es suficiente con que tengamos un listado de cosas a probar, debemos tener la disciplina de verificar su comprobación.
La calidad es un tema de actitud, la Definition of Done nos facilita una conversación dentro del Scrum Team para saber qué nivel de calidad buscamos y cómo garantizamos que lo obtendremos. Después, viendo los resultados de nuestro trabajo, podemos analizar si nuestra definición es correcta y si somos rigurosos cumpliéndola.
A medida que ganamos experiencia, solemos ampliar la Definition of Done y mejorarla para tener mayor calidad de producto. Una regla vital es que no debe reducirse durante el Sprint para “poder llegar”. Bajar la calidad para correr lo acabaremos pagando en términos de insatisfacción de cliente, retrabajo y desmotivación del equipo provocado por hacer “cutradas” para llegar.
Cuando definir tú Definition of Done
La Definition of Done se construye y se trabaja durante la Sprint Retrospective. Salvo en el primer Sprint que se trabajaremos en la Sprint Planning. En muchas empresas, existe una Definition of Done gobernada por la propia organización. Un equipo debe saber si existe y utilizarla. Un equipo siempre puede ser más duro en su Definition of Done, nunca puede ser menor a la establecida por la empresa.
Para crear nuestra propia Definition of Done, debe participar todo el Scrum Team. El Product Owner debe conocerlo, ya que todo aquello terminado podrá transmitirse a los stakeholders, y sabremos en todo momento el estado real de nuestro producto. El Scrum Master tiene que saber qué significa que un elemento está terminado, ya que es un acuerdo de equipo y su trabajo es corroborar que los acuerdos de equipo se llevan a cabo. Y por supuesto, el Development Team debe conocerlo, ya que son los que velan por su cumplimiento.
Un ejemplo práctico, cómo componer tu Definition of Done
Para poder definir nuestra Definition of Done, lo ideal es facilitar una sesión en la que nos sentemos y hagamos la pregunta clave: ¿qué significa en este equipo que algo está terminado? Se puede dar una primera definición de alto nivel y luego ir aterrizando por diferentes tipos de trabajo o por diferentes situaciones del contexto. Se puede incluso diversificar, de manera que, para unos clientes se siga una línea y para otros, otra.
Para realizar una, debemos seleccionar qué tipo de pruebas vamos a hacer: test unitarios, de integración de regresión, de seguridad… no es solo definir pruebas, también en qué medida y cantidad. ¿Qué cobertura de código aceptamos?
Además, hay que añadir reglas de equipo para revisar que cumplimos estas reglas. Por ejemplo, code-review donde revisemos el código de un compañero antes de dar por finalizado ¿Cuántos compañeros deben revisar un código? ¿Pruebas funcionales o también de revisión profunda de código? ¿Qué ocurre si detectamos algo mejorable? Todo esto es parte de nuestra Definition of Done.
A veces, la Definition of Done incluye a otras personas o equipos. En algunos clientes, hemos visto que necesitamos validación de un departamento concreto o del propio Product Owner. Tengamos en cuenta que todas estas validaciones retrasan la entrega de valor. Si debemos hacerlo, adelante, pero que comprendamos los perjuicios producidos.
También podemos crear reglas del estilo: está prohibido arrancar un trabajo nuevo mientras haya trabajo por revisar de un compañero. Así, evitamos que se acumule el trabajo en la parte de pruebas y que tengamos muchas cosas arrancadas sin finalizar.
Recordemos: sin entrega no hay Scrum
La diferencia entre un planteamiento Scrum y uno tradicional es la importancia de la entrega. Cuando hacemos release, todos los beneficios de Scrum salen a la luz. Sin entrega, el desarrollo no es incremental y, como mucho, es iterativo. Un desarrollo incremental nos permite saber si vamos en la buena dirección. Incluso, podemos cancelar el producto si vemos que la dirección no es correcta y que el mercado no quiere lo que estamos creando. Aquí está la gran ventaja del desarrollo ágil con respecto a los modelos tradicionales. No sé si llegaremos a una fecha concreta, pero sí sabemos que somos capaces de adaptarnos ante cualquier circunstancia. Y para ello, todo el trabajo debe estar terminado.
Y para tí, ¿cómo es tu Definition of Done?
Pues como todo, para gusto los colores. El problema del DoD es que es un criterio genérico de finalización y como tal se queda muy a alto nivel. Cuando tienes HUs de distinta naturaleza, con dependencias, integraciones etc… una opción es bajar el DoD a nivel de HU lo cual ayuda a entender y generar una conversación respecto a lo que se espera.