¿Como se define "Terminado"?, y ¿por que es importante para el proyecto?

Ahora que estoy dando de nuevo la clase de preparacitión para el examen de CAPM, me encuentro en la necesidad de explicar a mis alumnos lo crírico que es para el éxito de proyecto que nuestro equipo entienda claramente cuando estará terminado el proyecto y como "se ve" el producto final de nuestro esfuerzo.

Ademas, el tema permite dar seguimiento a lo expresado en el post anterior (PENDIENTE): Podemos expresar el avance de nuestro proyecto, ahora hay que saber cuando hemos terminado.

Traigo entonces un artículo publicado por Wayne Grant, en Projects at Work el pasado 23 de enero de 2014: ¿Como definir a nuestro equipo lo que significa "hecho" (o "terminado")?

Como dice Wayne, la adecuada definición de "Hecho" aporta transparencia a la forma en que un equipo trabajo, por lo que proone una lista de comprobación (o un taller) para ayudar a los equipos a acordar y publicar una definición de "Hecho".

Wayne dice que en su trabajo constantemente le sorprende que los equipos de trabajo no tengan una definición de "Hecho".

La idea surge de los métodos Agiles: la Definición de "Hecho" (Definition of Done - DoD) es una lista de verificación de actividades útiles que se llevan a cabo por el equipo de desarrollo de software cada vez que se implementa una historia de usuario. La DoD puede incluir, por ejemplo, código fuente, pruebas unitarias, pruebas de Integración, revisiones entre iguales (Peer Reviews), etc. La idea es que la culminación de todas estas actividades y su validación contra de un determinado conjunto de requisitos dará lugar a una pieza de software potencialmente liberable - es decir, software de calidad que cumpla con los requisitos. Una historia de usuario no puede ser considerada como terminada ('Hecha') hasta que todas estas actividades se han completado con éxito.

Es importante señalar que es casi seguro que la DoD contiene diferentes actividades para diferentes equipos (y proyectos) porque se desarrollan distintos tipos de trabajos y se tienen diferentes medios para garantizar la calidad. Por lo tanto, cada equipo tiene que pasar algún tiempo para dar con su DoD particular.

Y aquí es donde yo tomo la idea. Si bien Wayne recuerda que una DoD acordado y publicada es esencial para equipos ágiles, yo creo que puede ser útil para todo tipo de proyectos, ya que aporta transparencia a la forma en que el equipo de trabajo concibe el objetivo final del proyecto. Ayuda a asegurar que todos en el equipo tienen la misma idea sobre lo que significa "terminado" y el proceso que se deben seguir para alcanzarla. Además, como la DoD es desarrollado por todo el equipo del proyecto, puede ser discutida y posteriormente alterada cando el equipo acuerda hacer cambios a la forma de trabajo para mejorar la calidad y la eficiencia.

La mejor parte de la propuesta de Wayne es un taller para familiarizar al equipo de trabajo con el concepto de DoD.

El formato del taller.

El taller está diseñado para ejecutarse personalmente e idealmente todo el equipo debe estar presente. Cuando no todos los miembros del equipo pueden asistir y el equipo no es multi-funcional, todas las funciones deben estar representadas. No se requiere ninguna preparación específica por parte del equipo. Se debe programaren una hora para el taller y la se desarrolla en una habitación con un pizarrón blanco o un espacio similar de pared utilizable.

Se empieza por explicar el objetivo de la sesión, es decir, la creación de la DoD del equipo que posteriormente será publicada. Por supuesto, esto implica que se debe explicar lo que es la DoD y cómo puede ayudar al equipo. Normalmente, esto plantea algunas preguntas del equipo que se deben responder antes de pasar a la siguiente etapa del taller.

Luego se entregan notas adhesivas y plumones. Se solicita al equipo que piense en todas las actividades de alto nivel que normalmente dedican a conseguir terminar una historia. Se pide que escriban cada uno de estos elementos en las notas adhesivas con una actividad en cada nota. Hay que insistir en que cada uno escriba por lo menos un par de notas adhesivas y que sólo incluyan las actividades que realizan ahora, no las que suponen que pueden realizar.

Una vez que todos hayan terminado de escribir se pide al equipo que coloquen en el pizarrón todas sus notas, sin ningún orden concreto.

Enseguida se pide al equipo que colaborando entre ellos, agrupen ítems similares e idénticos. Los miembros del equipo pueden haber utilizado una terminología diferente para describir una actividad por lo demás idéntica pero al trabajar juntos pueden identificar qué notas adhesivas son en realidad la misma cosa.

Con los grupos completos, procede a revisar cada uno y validar que todos los elementos dentro de ellos se refieren realmente a la misma actividad. También se sugiere comprobar que el equipo realmente hace la actividad particular ahora, y que no se trata de una aspiración. Cualquier elemento aspiracional se elimina.

La siguiente tarea con el equipo es colocar cada grupo de actividad en una línea de tiempo. La colocación de las actividades refleja el orden en el que tiene lugar dentro de cada proceso de desarrollo.

Una vez establecida la línea de tiempo, se procede a crear de un título para cada actividad. Esto es necesario porque los miembros del equipo pueden hacer referencia a la misma actividad por un nombre diferente. Por ejemplo, "Aplicación", "Codificación" y "Desarrollo" son términos diferentes para las mismas tareas. Acordar un solo nombre para cada actividad presenta una terminología consistente que el equipo puede utilizar para mejorar su comunicación cuando habla de su DoD. Además, si hay dificultad en el equipo para crear un nombre para uno de sus grupos de actividad entonces se es posible que tenga que esta deba ser dividida en varias actividades más fáciles de nombrar.

Luego los nombres principales acordados son escritos cerca de cada actividad.

Con los titulares acordados se vuelve a revisar cada actividad de nuevo. Esta vez pidiendo al equipo definir aquello que está involucrado en la realización de cada uno de ellos, pensando en los entregables, los resultados y las condiciones que representan el éxito. Estas descripciones se escriben para cada actividad junto al título.

La combinación de las actividades ordenadas y las descripciones más detalladas integran la DoD del equipo.

Finalmente, esta DoD se documenta en algún medio que pueda ser consultado por el equipo.

La insistencia durante todo el proceso de incluir sólo aquellas cosas que el equipo hace ahora se debe a que el propósito principal de esta actividad es captar lo que el equipo hace ahora. Inmediatamente después de que la DoD está acordada y se ha publicado, el equipo es libre de negociar y hacer cambios positivos. Esto puede ocurrir incluso en una sección posterior del taller. La clave es que tener una DoD terminada que pueda servir como línea base, a partir de la que se puedan sugerir mejoras.

Cuándo ejecutar el Taller.

El taller se puede usar para ayudar a documentar la DoD para los equipos de proyectos que ya están ejecutándose. Sin embargo, los nuevos equipos no deben esperar hasta que estén a mitad de un proyecto antes de crear su DoD. Se sugiere poner por escrito esta DoD en el comienzo mismo del proyecto.

El autor sugiere que este formato de taller se podría utilizar en forma igualmente eficaz para crear la DoD inicial para un equipo recién formado.

Nota: Para conservar la idea general, las fotografías son del artículo original.