Conocido en nuestro sector como Changelog, este registro de cambios trata de recopilar toda la información sobre los cambios o actualizaciones realizadas en un proyecto o aplicación. Generalmente en este registro se suelen reflejar corrección de errores (bugs), modificaciones y nuevas características entre otras muchas cosas.
Ventajas del Changelog
Aunque sea un tipo de documentación que es necesario ir actualizando, y que requiere algo más de tiempo, es de lo más útil. Entre sus ventajas, por ejemplo, este registro puede ayudar con la resolución de problemas. Si un momento determinado, apareciera un error, se puede consultar cuáles han sido los cambios que se realizaron en esa fecha y revisarlos de manera concreta y rápida, en lugar de hacer una revisión general de todo el proyecto.
Por otra parte, podemos usar este registro para compartirlo con el cliente o usuarios, en un ejercicio de transparencia y por tanto fomentando la confianza en el proyecto. De esta manera nuestros stakeholders, pueden ver de manera detallada los cambios que se están realizando y cuáles son los avances que se están llevando a cabo en el proyecto. Además se les hace saber que ha cambiado exactamente y en qué les impacta, ¡Y estas son solo algunas de las ventajas!
Cómo implementarlo en tu proyecto
Cada proyecto es un mundo. Para empezar, hay que analizar como funciona el proyecto para encontrar la fórmula que mejor se adapte. Es por esto que debemos de entender que la realización de un registro de cambios es algo bastante flexible.
En primer lugar, hay que determinar si se desea crear un registro de cambios público, privado o realizar ambos.
Registro de cambios privado.
Un registro de cambios privado, que en mi opinión es el más básico e importante, puede ser mucho más técnico a la hora de documentar los cambios realizados.
En este ejemplo, podemos ver una tabla que registra los cambios de un pase a producción. Con un vistazo rápido, podemos comprender que durante el pase a producción se han actualizado varios componentes, qué cambios se han realizado en cada uno de ellos, la versión que había previamente, cuál es la que subió en ese momento, si hay algo de especial interés a tener en cuenta, el responsable técnico de la solución y un enlace a las pruebas realizadas.
Como se puede observar incluso se puede entrar en el detalle de los cambios realizados en la base de datos. Esto puede ir acompañado con la referencia al nombre del script que se lanzó en el pase a producción por si algún día se quiere revisar que fue lanzado exactamente.
Consejos para el registro privado
A modo de recomendación, este documento y otros registros de cambios deben siempre estar alojados en un lugar donde el equipo pueda ir nutriéndolo según se necesite de manera ágil y sencilla, cumpliendo también con los requisitos de seguridad y accesos necesarios en el proyecto.
También podemos hacer este registro de otras formas. Por ejemplo, si en lugar de hacer el registro sobre una subida a producción, se puede realizar sobre el versionado de cada una de las aplicaciones. O incluso si fuese una herramienta parametrizable, se puede hacer sobre los casos de uso indicando en un documento o página que ha ido cambiando a lo largo del tiempo.
Registro de cambios Público
En cuanto a hacer un registro de cambios público se debe de redactar de manera mas comprensible de cara al usuario o cliente final sin entrar en los detalles técnicos.
El ejemplo de arriba, está relacionado con el registro de cambios de la tabla anterior que a pesar de ser el mismo contenido, el mensaje es completamente distinto.
Consejos para el Registro Público
Como se puede ver en la imagen es aconsejable dividirlo en dos puntos: nuevas funcionalidades y correcciones, pero no deja de ser algo orientativo que puede depender de las particularidades de cada proyecto.
Incluso yendo mas allá del registro de cambios en estas notas se puede añadir un tercer punto donde se indiquen cuáles son las nuevas funcionalidades o qué pueden esperar encontrar en el proyecto a corto o medio plazo. Además, se podría incluir información adicional como cuáles son los siguientes objetivos u otras consideraciones que sean oportunas: desde un agradecimiento a los usuarios, hasta unas disculpas por los inconvenientes ocasionados por un fallo.
Conclusión
Estoy cerca de cumplir una década en esta industria y, no me cabe la menor duda, que a nivel de documentación en un proyecto esta puede ser de las prácticas que más aportan. Ya no solo a nivel de utilidad de cara a historificar los cambios: comprender el qué y cuándo se cambió un elemento, si no a la hora de transmitir como técnico nuestro trabajo tanto a nuestros compañeros como a los clientes o usuarios finales de una forma clara y transparente. Incluso, en mi opinión, resulta satisfactorio ver plasmado el trabajo realizado a lo largo del tiempo. Da exactamente igual que hasta ahora no lo hayas hecho: empieza a hacerlo lo antes posible, es sin duda una muy buena práctica.
