La definición de hecho en 5 preguntas

Uno de los pilares sobre los que se sustenta SCRUM es la Transparencia y una de las recomendaciones principales para alcanzar esta Transparencia es asegurarse que cuando decimos que una funcionalidad o tarea ha sido terminada, todos los involucrados (Scrum Master, Product Owner, equipo e interesados) esperan y entienden lo mismo.

El Porqué de la definición de hecho

Veamos un ejemplo extraído de http://mathieuhetu.com/:

Evidentemente este ejemplo es un caso extremo, todo equipo o desarrollador suficientemente profesional se asegura de que todo compile y funcione antes de decir que ha terminado su trabajo ... bueno, lo que está claro es que si al cliente le dices que has terminado, seguro que interpreta que todo compila y funciona (ironic mode off).

Sin embargo existen otras cuestiones que no están tan claras y que deberían de ponerse en común. El objetivo de la definición de hecho es identificar todas las acciones que hay que realizar (además de la propia codificación) para poder dar por finalizado un trabajo.

Fuente: Magenic: The Definition of "Done" in Agile Project Methodology

El Quién, Cuándo y Cómo de la definición de hecho

• Quién: la definición de hecho debe de construirse entre el equipo y el Product Owner. El Scrum Master tiene la labor de facilitar su generación, recopilar los acuerdos tomados y de ayudar a su puesta en práctica.
• Cuándo: debe de realizarse al inicio del proyecto, antes de empezar el desarrollo. Evidentemente, por la propia evolución del proyecto podremos encontrarnos con la necesidad de realizar ajustes en la definición original, tanto para introducir como para eliminar puntos de control, pero siempre con el consenso de todas las partes.
• Cómo: para poner en práctica la definición de hecho lo más sencillo y adecuado es interpretarla como un checklist a utilizar por el equipo durante el desarrollo, pero sobretodo, antes de cerrar las historias. En caso de que el equipo delegue la operación de cierre de historia en el Product Owner o en el Scrum Master, éste podría hacer una revisión de cumplimiento de la definición de hecho.
  
  
  
  Fuente: Cinderella Scrum Master: Definition of Done: A checklist, not a process
  
  

El Qué de la definición de hecho

Los puntos de la definición de hecho pueden variar por muchos aspectos: cultura o procedimentación de la empresa desarrolladora, imposición del cliente, imposiciones del propio proyecto, etc. Por este motivo, establecer una definición de hecho única y adaptable a todas las circunstancias no es razonable.

Algunos de los aspectos que se pueden incluir son los siguientes:

• Gestión del versionado del código: lo habitual y recomendable es que, una vez terminado el desarrollo de una funcionalidad, el código generado se encuentre correctamente almacenado en un repositorio de código. Lo que puede variar de unos proyectos a otros es el cómo: ¿se crea un "tag"?, ¿se toma nota en un soporte externo del número de revisión?, ¿se hace un export del código a otro soporte?, etc.
• Pruebas: se supone que el código generado deberá estar probado, pero la definición de hecho puede dejar claro las pruebas que se esperan de este código: ¿se requieren pruebas unitarias y con qué nivel de cobertura?, ¿se documentan y ejecutan pruebas de validación de la funcionalidad y quien realiza dichas pruebas?, ¿se hacen pruebas de regresión para cada historia cerrada o solo se hacen una vez al final del Sprint?, etc.
• Control de calidad/seguridad: según el proyecto, cliente o compañía pueden venirnos impuestas ciertas pautas de seguridad y/o calidad que se deben cumplir. Estas deberán ser conocidas por todos los participantes del proyecto desde el inicio del mismo, pero especialmente por el equipo. Tanto si estas comprobaciones de hacen de forma automática (haciendo uso de herramientas SW como Sonarqube o HP Frotify, por ejemplo) o de forma manual por parte de algún equipo de control de calidad o seguridad, es necesario establecer inicialmente cuales son los niveles esperados para que el equipo pueda trabajar en consecuencia.
• Documentación: desde el inicio del proyecto debe de establecerse cuál es la documentación a generar junto con el desarrollo. Esta puede surgir como requisito del cliente o como una necesidad interna de la propia empresa de desarrollo. En este aspecto es importante destacar que la definición de hecho se refiere a las acciones a realizar para terminar una historia, por lo que requisito de documentación que se incluya deberá ser razonable y abordable historia por historia. Por ejemplo, un buen requisito es que se mantenga actualizado el plan de pruebas con cada historia, pero otras documentos, como el manual de usuario, puede que no sean necesarios en cada cierre de historia.
• Promoción de entornos o distribución del ejecutable: en la teoría de SCRUM se indica que al final de cada Sprint deberíamos tener un producto operativo (con funcionalidad limitada, pero "utilizable") por lo que es necesario establecer tanto los entornos objetivo (si corresponde) como a quién se deberá distribuir dicho producto. En la definición de hecho se debe indicar como actuaremos en este sentido para cada cierre de historia ¿es necesario promocionar de entorno o distribuir un ejecutable cada vez que cerremos una historia? ¿lo hacemos solo para algunas historias concretas o lo hacemos una única vez al final de Sprint?
• Notificaciones u otras acciones de difusión: se basa en establecer a quién hay que avisar cada vez que cerremos una historia: al Product Owner, a un conjunto concreto de interesados, a un equipo de pruebas o de auditoría, etc.
• Etc.

Resumen

La definición de hecho es una herramienta orientada a que todos los involucrados en el proyecto tengan un punto de vista común con respecto al trabajo realizado. Al equipo le sirve para saber si están cumplen con las perspectivas del Product Owner y a éste le sirve para ser consciente de lo que debe esperar por parte del equipo.