retrospectivaSprints.md - UCM-FDI-DISIA/proyectois1-algoritmos GitHub Wiki

Retrospective Sprint

En todas las reuniones de retrospectiva abordamos lo siguiente:

  • Análisis del equipo.
    • ¿Cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas?
    • ¿Qué ha salido bien? ¿Y cómo podemos mantenerlo?
    • ¿Qué ha salido mal? ¿Y cómo podemos cambiarlo?
  • Cómo mejorar en el siguiente Sprint.

Nos basamos en el Método Estrella:

  1. Start doing.
  2. Keep doing.
  3. Stop doing.
  4. More of.
  5. Less of.

Sprint 1

  1. Start doing:
    • Vamos a empezar a especificar e implementar historias de usuario.
  2. Keep doing:
    • Vamos a seguir dividiendo el trabajo en tareas pequeñas e independientes, y repartiendo estas últimas organizadamente.
    • También continuaremos reuniéndonos frecuentemente (daily) para ir comentando el estado de trabajo de cada uno, y hablar sobre los posibles conflictos que hayamos tenido.
  3. Stop doing:
    • Debemos parar de utilizar herramientas externas a Github (como Trello o Drive) para que toda la información esté centralizada en un mismo sitio, en el que todos podamos tener un seguimiento continuo de los avances que cada uno hemos hecho.
  4. More of:
    • El uso de tablas de reparto de tareas como los kanban que hemos creado en el apartado de proyectos (el del sprint y el del backlog), que nos ayudan a tener una perspectiva general de lo que se está desarrollando en cada momento, y el trabajo que queda por hacer.
  5. Less of:
    • Tendríamos que adelantar menos trabajo que luego pueda resultar inútil, y centrarnos en llegar bien a los objetivos principales que se hayan fijado.

Sprint 2

En este sprint hemos tenido varias complicaciones técnicas con Godot, además de dificultades respecto a la distribución del tiempo. Todo esto ya lo previmos en el plan de gestión de riesgos.

De cara al siguiente Sprint, pretendemos ser más realistas con el trabajo que somos capaces de realizar, ser más comunicativos y aumentar la frecuencia de las reuniones grupales. El principal objetivo a conseguir es que todos los integrantes sean conocedores del trabajo que está desarrollando cada miembro del equipo, para que nadie se pise ni mucho menos sienta confusión. Esto también permitiría la cooperación activa de diferentes miembros del equipo en una misma tarea si se detectan complicaciones a la hora de desarrollarlas.

  1. Start doing:
    • Vamos a empezar a hacer las reuniones mucho más frecuentemente, óptimamente a diaro.
  2. Keep doing:
    • Vamos a seguir autoasignándonos pequeñas tareas para al finalizar el sprint tener las historias de usuario implementadas.
    • Además hemos ejecutado de forma muy satisfactoria la política de intensive commit y pretendemos continuar así.
  3. Stop doing:
    • Vamos a parar de llevar cada tarea de forma completamente individual y comentar con el resto de compañeros si hay alguna cuestión o dificultad a tratar.
    • Vamos a comentar las dificultades de forma grupal aunque la tarea sea entre dos, para poder estar todos al día.
  4. More of:
    • Comentarios en los commits y en las tareas del kanban, para estar más al tanto de los avances.
    • Vamos a intentar seguir el órden de prioridades establecido en el Kanban.
  5. Less of:
    • Trabajo descompensado entre compañeros y poca interacción o preguntas a individuos en vez del grupo.
    • Trabajar sin mirar el trabajo en progreso o de mayor prioridad.

Sprint 3

Por un lado, en este sprint, hemos tenido varias complicaciones técnicas con GitHub y los merges de Godot. Por otro lado, hemos sido capaces de cooperar entre todos y apoyarnos en el resto de miembros del equipo para ayudarnos cuando nos encontráramos un problema. En definitiva destacamos:

  • Gestión de riesgos efectiva: Los problemas identificados en el plan de riesgos se materializaron, pero estábamos preparados para afrontarlos.
  • Resiliencia del equipo: La respuesta colaborativa ante las dificultades técnicas fue muy satisfactoria.
  • Aprendizaje continuo: Cada problema resuelto ha fortalecido nuestro conocimiento técnico colectivo.

De cara al siguiente Sprint, pretendemos seguir trabajando de la misma manera, comunicándonos activa y frecuentemente, manteniendo la frecuencia de reuniones de equipo que hemos conseguido tener en este sprint. También vamos a procurar que todos los desarrolladores estemos en la misma línea de pensamiento creativo, es decir, que todos tengamos la misma idea de lo que queremos hacer con cada funcionalidad del juego. Para lo cual planteamos comenzar a realizar RTFs sistemáticas en las que se revisará la especificación del juego colectivamente.

  1. Start doing:
    • Vamos a empezar a realizar RTFs periódicas sistematizadas.
    • Vamos a empezar a comentar la disponibilidad de horarios de cada miembro del equipo para afrontar mejor la carga de trabajo del proyecto.
  2. Keep doing:
    • Vamos a seguir trabajando como un equipo, con comunicación fluida entre los miembros y reuniones dailys frecuentes.
    • También vamos a seguir cooperando en caso de que tengamos alguna dificultad. El pasado Sprint comenzamos a hacer sesiones de debugging colaborativo que resultaron muy útiles.
    • Vamos a seguir siendo flexibles en cuanto a las tareas que tenemos que hacer, trabajando en la que más dificultades estén presentando, o en las más prioritarias de la lista.
    • Además hemos ejecutado de forma muy satisfactoria la política de intensive commit y pretendemos continuar así.
  3. Stop doing:
    • Vamos a dejar de mover las tareas del Kanban antes de revisar los comentarios que tengan.
    • También notamos que no todas las tareas del Kanban tienen fecha y estimate, por lo que vamos a dejar de crear o modificar tareas sin actualizar sus metadatos.
  4. More of:
    • Comentarios en los Commits y en las tareas del Kanban, para estar más al tanto de los avances.
    • Hablar sobre los detalles específicos de las funcionalidades a implementar para evitar el conflicto entre diferentes perspectivas a nivel creativo.
  5. Less of:
    • Tareas estancadas en "In Progress" sin ningún commit asociado (hacer push diario).

Sprint 4

En este Sprint, el objetivo principal era implementar las funcionalidades multijugador (simultaneidad y ataque/batalla) y avanzar en el sistema de registro e inicio de sesión. También se dedicó tiempo a pulir tareas pendientes de construcción y mejorar la documentación interna (RTF y Documento Técnico). Aunque se completaron la mayoría de los incrementos planificados, la transcripción del código a GDScript y la integración del multijugador consumieron más tiempo del previsto.

Además, hubo diferencias de disponibilidad entre semanas debido a los exámenes, lo que provocó una carga de trabajo desigual. A pesar de esto, el equipo mantuvo una actitud resiliente y colaborativa.

  1. Start doing:

    • Iniciar pruebas de sincronización multijugador más tempranas en el Sprint para evitar detectar errores al final.
    • Comunicar mejor los cambios grandes (como la transcripción de código) para evitar pérdida de funcionalidades durante merges.

  2. Keep doing:

    • Vamos a seguir cooperando activamente cuando surjan problemas técnicos complejos.
    • Continuar diseñando escenas y sistemas modulares, lo que ha facilitado las ampliaciones del multijugador.
    • Continuar aislando funcionalidades en escenas separadas para evitar conflictos de merge.

  3. Stop doing:

    • Vamos a dejar de planificar objetivos demasiado ambiciosos sin revisar previamente la disponibilidad del equipo.
    • Vamos a dejar de mover tareas en el Kanban sin revisar comentarios, estimate y fechas.

  4. More of:

    • Ajustar la planificación del Sprint en función de la disponibilidad real del equipo, especialmente en semanas con alta carga académica.
    • Más pruebas sistemáticas del multijugador y la sincronización entre jugadores.
    • Más comunicación técnica sobre problemas derivados del plugin multijugador.

  5. Less of:

    • Menos reimplementación duplicada de funcionalidades (como los timers de batalla).
    • Menos trabajo en paralelo en escenas con alta dependencia sin planificación previa.

Sprint 5

El objetivo principal fue consolidar la funcionalidad multijugador (capacidad de múltiples partidas simultáneas y fallback a PvE) e iniciar el desarrollo de estructuras de recolección automatizada con spawneo de NPCs.

El equipo logró consolidar el multijugador, permitiendo la simultaneidad de partidas en lobbies separados y completando el ciclo de juego (iniciar y retornar al menú). Implementamos los modos PvE y PvP con lógica de transición/fallback automática si un jugador abandona o no encuentra oponente. Adicionalmente, se completaron el Manual del Jugador y la funcionalidad de construcción de puentes.

No obstante, el sprint se vio afectado por: la incompatibilidad del plugin GDSync con la exportación a Itch.io. En el desarrollo de estructuras, tuvimos problemas con las colisiones de los edificios instanciados y con el spawneo de NPCs en terreno inválido (agua/subsuelo). La mayor deuda técnica es el Pathfinding de los NPCs, que actualmente se bloquea al no evitar obstáculos, evidenciando la necesidad de normalizar las capas de colisión del mapa.

  1. Start doing:

    • Realizar pruebas unitarias en cada iteración del multijugador para detectar errores lo antes posible, para que no se magnifiquen más adelante.
    • Al implementar nuevas funcionalidades, no pegar el código completo "corregido" proporcionado por la IA sobre el código ya funcional, porque hay características ya funcionales que se pierden por el camino al ser sobreescritas.
    • Diseñar un sistema de “máscara de terreno” que defina áreas transitables (sin agua, y sin obstáculos) antes de continuar con la implementación de código que dependa de él (como la recolección automática de recursos).
    • Compartir el estado actual de tus tareas periódicamente, para evitar que el equipo trabaje en solitario y descubra problemas demasiado tarde.

  2. Keep doing:

    • Diseñar sistemas modulares y aislarlos en escenas separadas. Gracias a esto pudimos desarrollar el multijugador sin romper el modo single-player. Así, continuaremos creando una escena para cada subsistema importante.
    • Finalizar y actualizar la documentación en paralelo al desarrollo. Por ejemplo, el manual del jugador ya está completo y fue muy útil para las pruebas internas.
    • Cooperar activamente cuando surge un problema técnico complejo. Cuando el equipo de multijugador tuvo problemas con los lobbies, dos desarrolladores se unieron temporalmente para resolverlo. Seguiremos con esta cultura: si alguien está atascado > 1 día, se asignará esa tarea a otro miembro del equipo que e vea capaz de ayudar.

  3. Stop doing:

    • A partir de ahora, ningún plugin y funcionalidad se integra al proyecto principal sin antes haber sido probado en una build de exportación a todas las plataformas objetivo (Windows, IOS, Linux, Web/Itch.io, Android). Si no pasa la prueba y se encuentran errores de compatibilidad, se busca alternativa antes de continuar.
    • Instanciar elementos críticos (casas, NPCs, objetos interactuables) fuera de la escena principal.
    • No mover tareas en el Kanban sin cumplir los criterios de “Listo para pasar” que se especifican en los comentarios. Muchas veces se cambiaba una tarjeta a “Done” sin que hubiera sido probada al completo.
    • Si se detecta algún fallo en una tarea terminada, no reabrir directamente la tarea, sino hacer un pull absoluto para comprobar que el error es generalizado y avisar al responsable de la tarea.

  4. More of:

    • Hacer más pruebas de estrés del multijugador. Simular 4 jugadores reales conectándose, iniciando partidas, desconectándose y reconectándose diariamente. Con el objetivo de detectar fugas de memoria, desincronizaciones o caídas del servidor.
    • Hacer reuniones de retroalimentación con jugadores de prueba. Invitar a múltiples personas externas al equipo a jugar una build. Recoger feedback y documentar cada observación y convertirla en una tarea si procede.

  5. Less of:

    • Menos tiempo invertido en funcionalidades cosméticas o “nice to have” mientras existan bloqueantes críticos. Por ejemplo, no se deberían añadir efectos de sonido “ambientales” en el menú hasta que no se resuelvan GDSync y el Pathfinding.
    • Antes de escribir código nuevo, buscar en el proyecto si ya existe algo similar y reutilizarlo.

Sprint 6