salir de la zona de comfort

“Definition of Done” o definición de hecho o acabado


Antes de empezar a hacer seguimiento de proyectos, uno de los elementos básicos que se debe pactar con el equipo es lo que todo el mundo va a entender por hecho en un artefacto llamado “Definición de hecho”. En la mayoría de ocasiones, lo que entiende un desarrollador por hecho ni se aproxima a lo que el cliente espera como producto acabado, por lo que se debe fijar claramente cuando en el Sprint se va a considerar que una tarea o historia de usuario está terminada.
La metodología dice que una historia de usuario o tarea o está finalizada o no lo está, sin medias tintas. Pese a que estoy de acuerdo, muchas veces hay historias difíciles de partir en trozos pequeños y a la vez queremos reflejar en el seguimiento que se ha avanzado aunque no se haya completado ninguna nueva tarea (por exigencias de dirección por ejemplo), por lo que para mí es correcto informar de alguna manera que se ha avanzado un % de esta tarea.
Para unir las 2 necesidades en mi equipo hemos creado una definición de hecho que permite establecer una serie de avances parciales a cada tarea de forma que podemos hacer avances parciales sin dejar de tener claro todos cuando una tarea debe considerarse como finalizada. A continuación listo nuestra “Definition of Done”:

  • Testing Unitario/Integración completo y en verde – 50%
  • Código CheckedIn en el servidor
  • Actualizar CheckList y Test Cases para notificar a QA – 60%
  • Build ejecutada en el servidor de QA
  • OK de nuestro QA a la funcionalidad y sin incidencias – 75%
  • Revisión de código hecha – 80%
  • Documentación generada
  • Verificada demo para el Sprint Review – 85%
  • OK del Product Owner en el Sprint Review – 100%
  • Tarea resuelta en JIRA
  • OK de la funcionalidad en la UAT
  • Tarea cerrada en JIRA

Para nosotros cuando una historia está codificada está al 50%, y todavía le queda un largo camino por delante para completarse, pasando por la creación de los casos de test, obtener la validación de QA, revisar el código por un segundo ingeniero, generar la documentación necesaria y finalmente mostrar y obtener el OK en la demo funcional de final de Sprint. Lo consideramos terminado cuando el cliente lo ha visto y ha dado su OK, aunque dejamos claro que posteriormente quedan 3 pasos adicionales que no nos podemos saltar.
Esto nos ayuda a hablar todos de lo mismo y no llevarnos las sorpresas típicas de final de proyecto en las que no acaba nunca de terminar, el conocido como síndrome del 90%.

También te puede interesar...

Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Agile BCN Open Space primavera de 2017 (II) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...
Resumen Clean Code Este verano he releído uno de los libros de referencia de todo buen programador. Se trata de "Clean Code", de Robert C. Martin (o más conocido como Un...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

2 ideas sobre ““Definition of Done” o definición de hecho o acabado

  • WERS

    Su articulo es interesante, dada la experiencia descrita.
    Pregunto…
    Cuando mencionan “documentación generada”, podrían ayudarnos dándonos ideas de lo que documentan?
    Cuál se debe considerar documentacion ESENCIAL?
    Gracias de antemano.

    • Samuel Casanova

      Es una pregunta interesante y recurrente. En nuestro caso no hay una documentación que siempre hagamos, salvo un documento requerido para hacer las subidas a producción de lo que hacemos. Para nosotros, la documentación que generamos es siempre la mínima necesaria que nos aporte valor a nosotros como equipo o a la compañía.