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/

HOWTO: Ejecutar tu propio código .NET en Dynamics AX 2009

Aunque esto es algo que tiende a desaparecer en el próximo Microsoft Dynamics AX 2012, de momento es una funcionalidad muy útil en la versión 2009, ya que es la única manera de solventar algunas limitaciones técnicas.

Me estoy refiriendo a la posibilidad de utilizar el .NET CLR Interop para ejecutar desde nuestro código X++ librerías desarrolladas en .NET (ya sea C# o VB.NET). Esta integración también tiene sus propias limitaciones pero amplía de manera notable las posibilidades de desarrollo en AX 2009.

Voy a hacer un ejemplo paso a paso, y el primer paso es crear la propia librería desde Visual Studio. En mi caso voy a utilizar (el ya súper antiguo) Visual Studio 2005 para crear un nuevo proyecto “Biblioteca de clases”:

Dynamics AX 2009 DLL Interop

El código va a ser muy sencillo para no complicar la prueba, simplemente devolverá el nombre del equipo donde se ejecuta el código (esto se puede utilizar para comprender la ejecución de código en el cliente (devolverá la máquina local) o en el servidor (devolverá el AOS):

Continue Reading…