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 Agile Retrospectives de Esther Derby y Dia... El libro Agile Retrospectives de Esther Derby y Diana Larsen es un manual para Scrum Masters sobre cómo facilitar las retrospectivas en los equipos. ...
Razones para que empieces ya con las reuniones uno... Tu labor como Scrum Master o Team Coach es fundamentalmente introducir cambio a mejor en el equipo o equipos. Los equipos son en esencia las personas ...
Cómo preparar reuniones uno a uno En este artículo te comparto algunas buenas prácticas y también errores comunes al preparar reuniones uno a uno para que sean mucho más efectivas. El ...

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.