Definición de roles de recursos en ProjectLibre y gestión del tiempo

Como se ha establecido, se definirá un nuevo archivo de ProjectLibre para cada Sprint que se realice. En concreto, serán cuatro los tramos incrementales a realizar, debido a que el tiempo estipulado para la entrega de desarrollo en la asignatura de Arquitecturas Software para Entornos Empresariales son cuatro semanas y nuestras iteraciones coinciden con las mismas. Los roles definidos en los recursos en dichos ficheros atribuyen que:

• Amanda Merino será la Product Owner (PO).
• Pablo Pérez será el Scrum Master (SM).
• Jaime Masa será el Desarrollador Sénior (DS).
• Alexis Sancho será el Desarrollador Júnior (DJ).

GIT e integración con JIRA

Durante el desarrollo hacemos uso de la tecnología de control de versiones a través de GIT. Esto nos permite conocer el estado del desarrollo a través de las ramas y commits. Una vez definidas dentro de JIRA las subtareas de cada historia de usuario, creamos una rama por cada una de ellas. Podemos conocer las ramas sobre las que se trabaja y las tareas dentro de JIRA que están en progreso, terminadas o por hacer, gracias a que hemos instalado GITHUB para JIRA y hemos enlazado el repositorio sobre el que trabajamos.
El procedimiento consiste en hacer uso de los smartcommits, que nos permiten enlazar los commits con las issues de JIRA, incluyendo el ID de la tarea en el mensaje del commit, añadir comentarios sobre las issues, registrar el tiempo que hemos tardado en realizar la tarea y modificar su estado (en progreso, terminado o por hacer). Se hace uso a su vez de unos campos que denominamos etiquetas, incorporadas dentro de las tareas, que nos permite hacer uso del query language integrado dentro de JIRA para filtrar y recuperar las tareas. Una vez desarrollada y probada la historia de usuario, es llevada a una rama principal de nuestro repositorio en GITHUB que conocemos como 'Develop', que irá anexando todas las historias de usuario.

Integracion Continua mediante Github Actions

Se ha configurado un workflow en GitHub Actions para garantizar la calidad y la estabilidad del proyecto mediante la implementación de un proceso de integración continua (CI). Este workflow automatiza varias tareas críticas, asegurando que el código sea funcional, cumpla con los estándares establecidos y esté listo para integrarse de manera segura en el proyecto principal.

Como parte del workflow, se ha incluido la herramienta flake8 para realizar análisis estático del código Python. Esta herramienta permite detectar errores comunes, como problemas de sintaxis y conflictos relacionados con importaciones o variables. Algunos de los errores que verifica son los de tipo E9, que identifican problemas de sintaxis, y los de tipo F63, F7 y F82, que aseguran que las importaciones sean correctas y que no existan conflictos con variables. En caso de que flake8 detecte errores, el workflow detendrá su ejecución automáticamente, garantizando así que solo el código limpio y funcional progrese en el proceso.

Además, se ha integrado el uso de Docker Compose para verificar la construcción y ejecución de los servicios del proyecto definidos en el archivo docker-compose.yml. Este proceso incluye la construcción de las imágenes Docker necesarias y la ejecución de los servicios en segundo plano mediante el comando docker-compose up --build -d. Posteriormente, se valida que los contenedores se encuentren en ejecución utilizando el comando docker ps, lo que permite identificar de manera temprana posibles fallos en la configuración o el funcionamiento de los servicios.

El workflow está diseñado para ejecutarse automáticamente cada vez que se realiza un push en la rama develop. Esto asegura que todos los cambios sean revisados de manera continua, previniendo errores antes de que lleguen a entornos de producción. Al realizar estas validaciones de manera automatizada, el flujo de trabajo de los desarrolladores se vuelve más eficiente, ya que pueden centrarse en la implementación de nuevas funcionalidades mientras el sistema supervisa la calidad del código.

Este enfoque también refuerza la colaboración en el equipo, ya que garantiza que la rama develop se mantenga estable y lista para futuras integraciones en ramas principales como main. De esta forma, se logra un proceso más seguro y organizado para el desarrollo del proyecto.

En resumen, la integración continua en este proyecto ayuda a identificar problemas en una etapa temprana, mejora la eficiencia del desarrollo y asegura un nivel elevado de calidad en el código y los servicios. La configuración del workflow es un paso clave para garantizar que el proyecto se mantenga estable y funcional a medida que se realizan cambios constantes.

Problemas encontrados

A lo largo del desarrollo con cada interacción PUSH con la rama Develop hemos podido observar que se analizaba también una carpeta "oculta" denominada ".history" dentro de la raíz del proyecto. Esta carpeta se generaba automáticamente y almacenaba versiones antiguas de los ficheros que conforman los microservicios, y que por ende están desactualizadas tanto en las referencias, como las variables. Es así que una parte de los resultados de la ejecución del workflow son erróneos durante la tarea de análisis estático del código, y como consecuencia interrumpe con prontitud la ejecución del workflow dejando comprobaciones como la ejecución de los docker fuera. Para solucionar este problema hemos decidido eliminar la carpeta ".history" de todas las ramas y versiones, asegurandonos de que no exista en la estructura del proyecto en el momento de realizar un PUSH sobre Develop.

Gestión del desarrollo y seguimiento de la planificación

Durante el desarrollo del proyecto a lo largo de las cuatro iteraciones definidas, se ha seguido un patrón de acción. Este ha sido:

1. Reunión de planificación donde analizábamos las tareas asignadas al sprint para definir conjuntamente las subtareas precisadas.
2. Asignación de dichas tareas a los diferentes roles y recursos teniendo en cuenta los roles asignados a las historias de usuario correspondientes.
3. Creación del project del sprint con las tareas y configuraciones necesarias.
4. Paso del project a Jira para la gestión del progreso de desarrollo.

Una vez hecho esto, que eran las actividades realizadas durante las reuniones de sprint grooming y sprint planning, se comenzaba con el desarrollo. Sin embargo, algunas asignaciones del project pueden no coincidir con las de Jira porque, aunque respetando generalmente los roles establecidos en función de lo que mejor podíamos realizar cada uno para aportar al equipo, todos queríamos hacer parte del trabajo de los demás en menor medida para tener los mismos conocimientos que el resto. Así, aunque como PO, Amanda se encargase siempre de organizar las reuniones, preparar los project, entre otras tareas propias, también ha colaborado en ciertas subtareas para haber hecho todos los tipos de desarrollo de nuestro proyecto. Y, por poner otro ejemplo, aunque Jaime estuviese asignado como desarrollador y haya hecho eso mayoritariamente, fue quien, por tiempo, hizo el paso inicial de la planificación a Jira y ayudaba a Amanda en la creación de los project por sprint.

Para cerrar los sprints, hacíamos reuniones de sprint review y sprint retrospective donde:

1. Repasábamos una check-list de todos los objetivos a conseguir para asegurarnos de haber hecho todo lo planeado.
2. Analizábamos las diferencias en tiempo con respecto a las estimaciones ideales de las diferentes tareas.
3. Debatíamos si hacer alguna adaptación, cómo tratar los errores cometidos de cara a la siguiente iteración y qué atraso en los tiempos era necesario para la ejecución del siguiente sprint.

Problemas encontrados

A lo largo del desarrollo, hemos encontrado dificultades o problemas en diferentes ámbitos.

• Estimaciones demasiado optimistas. Aunque algunas estimaciones de tiempo o complejidad sí han sido adecuadas e, incluso, hemos tardado en ocasiones menos en resolver las tareas, en otras los tiempos previstos fueron demasiado optimistas. Esto hizo que la planificación no pudiese cumplirse adecuadamente, especialmente en el último sprint, donde contábamos con un desarrollo del front-end que no pudimos seguir finalmente y el cambio en el último momento conllevaba más trabajo del esperado. Esto llevó a atrasos y dificultades con las que no contábamos y que han afectado directamente en los plazos de entrega, que no hemos podido cumplir, y la rigurosidad del control del progreso.
• Mala gestión de las ramas en la última iteración. En relación con el punto anterior, lo sorpresivo de esta situación hizo que, al ver el tiempo de entrega acercarse, se dejase de seguir el flujo de trabajo tan estrictamente como hasta ese momento, habiendo un período en el que las ramas y los commits no cumplen con dicho flujo. Esto es algo que hemos visto que fue un error porque afectó también a la consistencia del código, algo que nos hizo comprender de primera mano lo importante de un buen seguimiento del workflow establecido.
• Cambios de última hora. Como se ha mencionado y se procede a desarrollar en más detalle, una vez en el proceso de desarrollo del último sprint, durante un laboratorio nos explicaron que la forma de desarrollar el front-end no era la adecuada para el objetivo de la asignatura. Aunque no habíamos avanzado tanto como para que causase un trastorno demasiado grave, sí que fue una noticia repentina que nos obligó a hacer cambios y gestiones sobre la marcha que supusieron retrasos y cierto descontrol del trabajo.

Sin embargo, y a pesar de todos estos problemas encontrados, hemos podido completar el proyecto de forma que nos sintiésemos satisfechos con el trabajo realizado y hemos buscado en todo momento mantener las prácticas adecuadas en la medida de lo posible. Y, principalmente, nos han servido de aprendizaje para saber cómo se debería planificar y gestionar un proyecto en un futuro sin caer en los mismos errores.