j.a.estevan

Sorry, this entry is only available in Español.

Sorry, this entry is only available in Español.

Sorry, this entry is only available in Español.

Sorry, this entry is only available in Español.

• 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} :
  

Obviamente esta situación es ficticia, 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 en a corto plazo.

Me gustaría analizar cómo se ha llegado aquí porque es algo que vemos todos los días cuando hablamos de software, que es a lo que vamos:

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 en concreto. 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 de ésta definicion va a ser la culpa del é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 la definicion de una tarea- esta perfectamente definida y quién lo solicita (consultor, analista, product owner, … quién sea) especifica detalladamente qué quiere, cuándo, dónde y cómo lo quiere. Pero nosotros no vivimos en un mundo ideal y 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 valido (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 los videos de las sesiones sobre Contratos Agiles (de Xavier Albaladejo) y a la keynote de Xavier Quesada, donde explicarán mejor qué yo por qué vale la pena reflexionar sobre este tema.

Sorry, this entry is only available in Español.

Sorry, this entry is only available in Español.

Voy a procurar no extenderme mucho para contar lo sucedido en estos dos días de conferencias que hemos podido disfrutar en la Universidad Jaime I de Castellón, empezando como no podía ser de otra manera felicitando la impecable organización por parte de los organizadores de Agile Spain. Un 10 para ellos y mi agradecimiento.

Después comentar que es mi primer evento “masivo” en la comunidad Agile Spain así que no tengo la oportunidad de hacer una valoración comparativa como otros compañeros están haciendo. Como es obvio, sólo voy a comentar las charlas a las que asistí. Ha quedado un poco largo, si te aburre puedes bajar directamente a las conclusiones

Leer el resto del artículo →

Sorry, this entry is only available in Español.

Sorry, this entry is only available in Español.