Definición de hecho, Definition of Done o «DoD» en Elemento115

Os voy a contar cómo llegamos a nuestra propia «Definición de hecho», «Definition of Done» o «DoD» en Elemneto115.

En la última retrospectiva ágil que hicimos el pasado 30/08/2017, aprovechamos para tratar un tema que veníamos necesitando desde hacía tiempo.

Un acuerdo sobre qué características debe tener un trabajo que realicemos para considerarlo como «hecho».

Un trabajo está hecho cuando se termina. Parece obvio. Y también puede parecer sencillo pensar en qué debemos tener en cuenta para considerarlo como tal. El problema reside en que habitualmente, distintas personas, pueden opinar diferente sobre qué características tiene algo que está hecho.

Y la cosa se complica si esas personas cumplen diferentes cometidos y tienen distintas responsabilidades durante el transcurso del trabajo.

Y ahí reside la necesidad de llegar a un acuerdo, y a ser posible con apoyo visual permanente.

¿Por qué es importante la Definición de Hecho?

Contémoslo con comida, que siempre es más fácil de explicar y entender. 

Pongamos que tenemos dos restaurantes especializados en vender hamburguesas, uno es un restaurante de comida rápida y otro uno de comida gourmet orgánica.

Como véis, las dos definiciones de hecho, son bastante claras en ambos casos. Y completamente diferentes.

Por otro lado, en los restaurantes hay personas con distintas responsabilidades (clientes, dueñx de negocio, jefx de sala, cocinerx, camarerx, etc) y que pueden dar más prioridad a unas características de la «definición de hecho» sobre otras dependiendo de algunos factores típicos:

• Cantidad de trabajo acumulado.
• Fecha o tiempos de entrega.
• Experiencia de las personas en el proceso.
• Confianza con el cliente.
• Momento del día / nivel de cansancio.
• etc.

Si no hay acuerdo explícito sobre la definición de hecho, distintas personas en cada momentos se ajustarán a la definición de hecho según su opinión y necesidades.

Una última complicación.

Ahora imaginad que un cocinero y una camarera del restaurante de comida rápida, deciden cambiar de trabajo e irse al restaurante gourmet. Pensad en cada uno de ellos y en qué problemas encontrarían a la hora de cumplir con su trabajo si no hubiera una «definición de hecho» claramente acordada y visualizable por todos en cada momento.

El acuerdo sobre la definición de hecho debe estar claramente visible y ser fácil de consultar y en su caso renovar cuando sea necesario.

Por suerte (o por desgracia para algunos), en Elemento115 no vendemos hamburguesas, si no servicios. Y la «definición de hecho» no es algo tan obvio.

Cómo hemos llegado a un acuerdo sobre la Definición de Hecho

Como decía antes, en la retrospectiva, facilité la sesión de co-creación de la «Definición de hecho» o «Definición de acabado» o «DoD», por sus siglas en inglés «Definition of Done».

La sesión está basada en un juego de cartas: DoD Kards preparadas por Thomas Whallet y Camilo Velasquez en Kleer.

El objetivo, para quien conozca la dinámica, es alcanzar un acuerdo sobre qué características debe reunir una tarea para que consideremos el trabajo como hecho, conseguir una mejor entrega de valor paliando y evitando los clásicos malentendidos y la desalineación de expectativas que se generan en este ámbito.

Durante el juego, separamos en tres columnas las diferentes recomendaciones:

• La columna de «YA» para aquellas cosas que estamos haciendo ya.
• En la sección de «MÁS ADELANTE» para aquellas que de momento no contemplamos pero que añadiremos pronto.
• Por último, la del «NO» para aquellas que no aplican, en las que no llegamos a un acuerdo, o que no nos interesan en ningún caso.

Os dejo la foto donde reunimos todo, y os invito a que visitéis el post que hemos escrito desarrollando más ampliamente la explicación nuestra definición de hecho.

Cuál es la definición de hecho de Elemento115

Os dejo a continuación nuestra lista de características de la definición de hecho:

• Revisión:
  • No se incrementa la deuda técnica  (sin justificación)
  • El product owner ha visto funcionando en algún entorno la historia de usuario y la ha aceptado.
• Difusión:
  • Se notifica a las personas interesadas.
  • Se comunicó al resto del equipo la información relevante.
  • Se actualizan las entregas en Jira y los documentos de Confluence, que afectan a notificaciones slack y emails para hacer llegar las notificaciones a quien corresponda.
  • Se enseña a los usuarios involucrados el uso de las mejoras.
  • Se genera o actualiza la documentación relevante: manual del API, manual de usuario, control de versiones técnico y release notas de marketing .
  • Se justifica el desfase con respecto a la estimación tanta al alza como a la baja si canta a la vista (si, según el sentido común, el desfase es grande)
• Entornos:
  • El entorno de entrega está preparado para hacer las pruebas y comprobaciones necesarias.
  • El código generado es almacenado en Bitbucket.
  • Se ha desplegado sin errores en el entorno de entrega con las pruebas definidas pasadas.
• Calidad:
  • Se ejecutan las pruebas necesarias.
  • Se cumple con los estándares de código.

Una definición de hecho sujeta a revisión

Naturalmente nuestra definición de hecho no está escrita en piedra, y la revisaremos en unos meses, ya que hay cosas que hemos dejado para «después» o incluso acuerdos a los que hoy por hoy no hemos llegado.

Es junto con la definición de preparado para desarrollo (acuerdo pendiente en Elemento115) uno de los acuerdos más importantes a los que puede llegar un equipo.

Espero que os haya gustado el post y si tenéis cualquier duda o sugerencia, por favor, utilizad la sección de comentarios de más abajo.