search
top

En un proyecto ágil, acordar una buena definición de lo que significa terminado (el done)

Por lo general, la gente que empieza a implantar agilidad, o los que lo han intentado pero no con mucho éxito, suelen tener en común el pasar por alto un grupo de aspectos que son de los más importantes: los que definen las relaciones y compromisos entre los diferentes roles que participan en el desarrollo software.

Todo el mundo es consciente y se preocupa por establecer iteraciones, Sprint, prototipos, historias de usuario, etc. Pero hay otros aspectos en un proyecto ágil igualmente importantes, como son los de compromiso, por ejemplo, que todo el mundo tenga claros los roles y responsabilidades de todo el mundo, que al comenzar un Sprint el product owner deje clara la visión y el objetivo, etc.

O, como es el caso que aquí aplica, que tanto equipo como product owner (te dejo el post del product owner) estén de acuerdo y definan qué significa que algo está terminado. Por dejarlo más claro, para los que usáis un tablero Scrum… qué significa que algo está en la columna “done” (terminado).

¿Qué significa que una historia está terminada? ¿Qué está implementada y probada? ¿Y hasta que grado se ha probado? ¿Y quien la ha probado? ¿Y significa que además debe estar desplegada? ¿O lista para pasar a producción? ¿O no es necesario?

Hay equipos que acuerdan una definición de qué es “terminado” para todas las historias de usuario, y hay casos en los que hay historias que requieren de un “terminado” específico para las mismas.

Lo de qué significa “done”, terminado, se obvia muchas veces y no es algo trivial. No aclarar este punto suele dar lugar a problemas.

Acordar una buena definición de lo que significa terminado (done)

Realmente, la definición del “done” es un acuerdo de calidad entre los desarrolladores y el product owner, y por ello… con los clientes. Algunos aspectos típicos a considerar al acordar el significado de “terminado” pueden ser:

– Los tipos de pruebas y el grado de prueba.

– Nivel de calidad del producto software (métricas, etc.)

– Nivel de documentación.

– Entorno específico en que concluye el trabajo: en prepro, testing, producción, etc.

 

2 Respuestas to “En un proyecto ágil, acordar una buena definición de lo que significa terminado (el done)”

  1. Hola Javier. En su día escribí un post similar, sin restringirlo a un proyecto ágil:
    http://calidadysoftware.blogspot.com/2011/11/cuando-se-puede-dar-por-terminado-un.html

    Coincido totalmente en que hay que aclarar por adelantado qué consideramos como “terminado”. El detalle básicamente es desarrollar lo que comentas: medidas sobre todo cuantitativas, que permitan demostrar que el producto se considera estable, y podemos “irnos a casa”, o bien pasar a realizar el mantenimiento como tal. Por desgracia, el tema es complejo y no puede basarse en 2 o 3 métricas. Más bien es definir patrones, y una vez se cumpla un número pactado de patrones de estabilidad…entonces se acabó. Algunas métricas que tú mismo comentas podrían ser:
    – Que esté desplegado en producción y haya pasado con éxito por los entornos anteriores que existan.
    – Que haya superado las pruebas pactadas en los distintos entornos.
    – Que los fallos detectados en producción en un tiempo pactado, evidencien que la solución es estable (vamos, que no hay cada vez más y más fallos). Aquí hay que considerar tipología de fallos, impacto, etc.

    Esto que suena tan formal, se puede alinear con desarrollos ágiles…no siempre es necesario calentarse la cabeza con complejos planes de pruebas, casos de pruebas, etc. Hay herramientas automáticas de pruebas unitarias, pruebas funcionales, calidad de código, que pueden ayudar.

    Como siempre, Javier, buen post. Un saludo

  2. José Magán dice:

    Hola Javier:
    Tengo una inquietud muy acentuada con el tema del “Proyecto ágil” y se refiere al alcance del proyecto, si bien es cierto que el product owner puede modificar el product backlog, es aquí en donde trataría de que el proyecto no se me escape de las manos, es decir ante un compromiso de entrega del prototipo operativo, esas modificaciones pueden hacer que ese compromiso no se cumpla.
    Gracias,
    JM.

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top