Definición de ‘hecho’ (DoD, Definition of Done)

  • Necesito precio para unos accesorios de baño para mañana {contrato a precio fijo, alcance fijo, plazo fijo}
  • Sin problema, le cuestan 50€ cada uno {confirmación del contrato}
  • Perfecto, pero los quiero colocados en la pared {ampliación de alcance no prevista}
  • OK, se los doy colocados en la pared {aceptación ¿? de la ampliación}

Resultado:

Definition of Done - Fail

Obviamente, este diálogo es ficticio, pero el resultado es real. Esa “instalación” lleva así desde hace más de un mes en un baño público y nada indica que la situación vaya a mejorar a corto plazo. Alguien ha considerado que ese trabajo está “hecho“, aunque esa no es la impresión que uno percibe cuando necesitas secarte las manos.

Me gustaría analizar cómo se ha llegado hasta aquí porque es algo que vemos todos los días cuando hablamos de software, que es a lo que vamos en este blog al fin y al cabo:

Definition of Done (DoD)

El término Definition of Done está asociado normalmente a Scrum, pero no por eso tenemos que limitarlo a Scrum, ágile, o a ninguna metodología específicamente. Es un término que en cualquier caso se tiene que tener en cuenta y sobre el que vale la pena negociar en cada proyecto, ya que esta definicion va a tener un gran peso en el éxito o el fracaso de muchas entregas. Me da igual que sean entregables waterfall, sprints de scrum o como queramos llamarlo.

En un mundo ideal, un análisis -o cualquier definicion de una tarea- esta perfectamente definida y quién lo solicita (consultor, analista, product owner, … da igual) especifica detalladamente qué quiere, cuándo, dónde y cómo lo quiere. Pero nosotros no vivimos en un mundo ideal y en nuestor mundo eso rara vez ocurre. Uno o varios de esos interrogantes los vamos a tener que preguntar o suponer, y de nuestro acierto va a depender que el resultado sea el esperado o no.

Esta duda (este riesgo) se puede mitigar destallando, por ejemplo, pruebas de aceptación o similares donde se especifique un juego de pruebas que el producto tendrá que cumplir para que se de por válido (para que se considere “hecho“). Pero aun así hay detalles que no entrarán en las pruebas de aceptación. Por ejemplo, la integración con otros sitemas, la existencia de dependencias externas, hardware, etc. … siempre habrá dudas sobre cuándo podemos dar un trabajo por “hecho“.

Supongo que la comunidad ágil tendrá para discutir largo y tendido acerca de lo que debe ser DoD, lo que se debe detallar en una tarea o en la definición de un sprint. Pero visto desde un punto de vista mas general (o mas waterfall en particular), la definición exacta y pactada de qué requisitos concretos debe cumplir un desarrollo para validarse es algo a lo que se le da poca importancia en el mejor caso, o se ignora por completo en el resto, y que a mi entender es causa de muchos desacuerdos entre las partes y constantes peleas a la hora de finalizar las entregas.

Sobre este tema se habló en la pasada Conferencia Agile Spain y por eso os remito a la keynote de Xavier Quesada “El último momento responsable”:

Xavier Quesada CAS2011

También en la sesion sobre Contratos Agiles (de Xavier Albaladejo), aunque todavía no está disponible el vídeo. Esperemos que lo esté pronto, porque el explica mejor qué yo por qué vale la pena reflexionar sobre este tema.

El resto de videos y fotos están disponibles en: http://conferencia2011.agile-spain.org/sesiones/