Distribución del trabajo y estructuración del proyecto.

Jira es una plataforma ampliamente utilizada para la gestión de proyectos, especialmente en entornos que siguen metodologías ágiles como Scrum. Permite a los equipos planificar, rastrear y gestionar su trabajo mediante la creación de issues que pueden ser categorizados en diferentes tipos, como épicos, historias de usuario, tareas y subtareas, que será el formato que nosotros seguiremos.

En nuestro equipo, la distribución del trabajo en Jira se ha organizado de la siguiente manera:

• Amanda se encargó de revisar, modificar y añadir campos a los diferentes tipos de incidencias para asegurarnos de añadir toda la información relevante.
• Jaime se encargó de crear las epics y las historias de usuario, definiendo los grandes bloques de trabajo y las funcionalidades específicas que debe cumplir nuestra plataforma.
• Posteriormente, en colaboración con Alexis, rellenaron los campos correspondientes para cada elemento y finalizaron la configuración del proyecto en Jira.
• Finalmente, se hizo una reunión de todo el equipo donde se revisó todo el trabajo realizado en Jira, se hicieron los ajustes pertinentes y se preparó la entrega definitiva.

Este proceso ha permitido estructurar el proyecto de forma eficiente, facilitando la asignación de tareas y el seguimiento del progreso en la plataforma.

Consideraciones y decisiones sobre Jira

• A la hora de asignar los recursos, se han creado equipos de trabajo. Estos son 'Management', que incluye Project Owner y Scrum Master; 'Project Control', con Project Owner, Scrum Master y Desarrollador Senior; y por último 'Project Development', que aglutina al Scrum Master, al Desarrollador Senior y al Desarrollador Junior. Sin embargo, lo anteriormente comentado sólo es posible como un campo dentro del elemento (tanto Incidencias como Historias); la asignación en Jira como tal se produce unívocamente, pudiendo elegir solo un miembro del equipo. Es así que hemos tomado la decisión de que el miembro del equipo que más horas desempeña es el asignado.

• Se establecieron las dependencias de las subtareas de forma que no puedan realizarse las propias de una historia de usuario posterior a las que ya se están haciendo en ese momento (p. ej., mientras se estén implementando subtareas de la HU1.1, no puede realizarse ninguna de la HU1.2). De esta manera, las subtareas de cada historia de usuario "heredan" esa dependencia de la historia predecesora.

Estrategia de migración de datos desde ProjectLibre

Para trasladar las tareas desde una aplicación local (como es ProjectLibre) a una compartida (como es Jira, que trabaja en línea y cuyos usuarios pueden operar con las tareas de manera óptima y adaptativa), es necesario explicar el proceso de migración de historias de usuario, epics y sprints, a esta última.

En primer lugar se anotan todas las historias de usuario, así como las reuniones de cada sprint, para posteriormente ordenar cada una de las tareas en el incremento de trabajo que corresponda. Para ello, se configuraron los campos de los componentes ofrecidos por Jira de Epic y Story para hacer el paso de datos por épicas y los tableros. para establecer las historias de usuarios y tareas MGT vinculadas a cada reunión. Además, para facilitar la búsqueda, se establecieron etiquetas para clasificar los diferentes elementos siguiendo la nomenclatura de Scrum utilizada en ProjectLibre. Por último, se definen los tiempos de cada tarea y la duración de las mismas, fechas de comienzo y fin estimados, descripciones, informadores, personas y equipos asignados, así como la prioridad que se estimó durante una de las reuniones de equipo.

Por otro lado, a la hora de gestionar el progreso con Jira marcando las tareas de tipo MGT, correspondientes a las reuniones propias de SCRUM, se ha seguido un patrón por el que, al haber fusionado las reuniones de grooming y planning por un lado y las de review y retrospective por otro, se marcan conjuntamente ambas reuniones porque se realizaban el mismo día y se describe lo realizado en los logs del trabajo solo de la segunda MGT, englobando ambas. Además, a la hora de elaborar las actas, se hacía un acta por cada conjunto de dos reuniones plasmando todos los temas tratados durante ambas a la vez. Esto debido a que las sesiones de laboratorio por lo general se destinaban precisamente a estas tareas y a trabajar mientras el encargado de elaborar el ProjectLibre del sprint y trasladar la nueva información a Jira elaboraba estos con los datos recabados durante la reunión.

NOTA: Al existir un desfase de tres semanas desde el momento de definir las fechas de las tareas y sprints hasta el inicio de estos, se han desplazado dichos elementos en el mismo lapso, es decir, si el primer sprint comenzaba anteriormente el día 7 de octubre ahora lo hace el día 28 del mismo mes. A su vez, se han desplazado de manera subsecuente todas las tareas posteriores, finalizando el día 22 de noviembre lo que antes acababa el día 1 en la planificación inicial.