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

Sprint planning

La planificación desglosada en tareas está detallada en la sección de "Projects" en los Kanban Sprint pertinentes.

Incluimos la siguiente información para cada Sprint:

  • Aspectos que abordamos del Product Backlog.
  • El último Incremento de producto, la capacidad proyectada del Equipo de Desarrollo para el Sprint y el rendimiento pasado del Equipo de Desarrollo.
    • ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
    • ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?
  • Durante el Sprint Planning el Equipo Scrum define el objetivo del Sprint (Sprint Goal).

Sprint 1

Este Sprint es especial porque aún no está elaborado el Product Backlog y por ende los objetivos que tenemos no responden a ninguna tarea del Backlog. Por el mismo motivo, no tenemos un "Incremento" en el sentido estricto de la palabra.

Sprint Goal: Documentar el proyecto y probar las herramientas de desarrollo.

Documentación

El objetivo principal de este Sprint es tener una documentación Scrum clara, accesible y ubicada en un único lugar que forme una base sólida para la gestión del proyecto. En mayor detalle, queremos tener la documentación de especificación de proyecto bien definida y estructurada en GitHub.

Objetivos detallados:

  • Valorar la idea inicial y discutir mejores opciones de planes de proyecto.
  • Trabajar en la estructura de la Wiki de GitHub.
    • Documento de Especificación sección 1.
    • Documento de Especificación sección 2.
    • Documento de Especificación sección 3.
      • Aspecto visual (trasladado aquí para mayor claridad).
      • Funciones y mecánicas: describir de manera precisa y exacta qué debe hacer cada mecánica.

Historias de usuario

  • Creación de usuarios de Feudalia.
    • Elaborar historias de usuario que respondan a las necesidades de cada Usuario.
  • Ordenar por prioridades las historias de usuario definitivas.
    • Decidir qué historias de usuario deben abordarse primero y plantearlas de cara al siguiente Sprint.

Probar Godot: elaboración de un prototipo.

  • Investigar sobre posibles recursos y herramientas complementarias.
    • Probar la coordinación entre GitHub y Godot (probar el plugin de Godot).
    • Encontrar herramientas que nos faciliten las tareas de diseño gráfico (buscar assets gráficos).
  • Probar la herramienta de trabajo.
    • Elaborar un primer prototipo con los assets y movimientos animados de personajes.

Sprint 2

Sprint Goal: implementar un mapa funcional y la mecánica de recolección de recursos.

  • Incremento: mapa funcional.
  • Incremento: recolección de recursos.
  • Wiki de GitHub (completar documentación).

¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?

De cara a conseguir el primer Incremento de Feudalia, el objetivo de este Sprint es abordar los siguientes aspectos del Product Backlog.

  • desarrollar un mapa cuadriculado (grid) funcional que el personaje principal pueda explorar.
  • implementar una de las mecánicas básicas del PMV de Feudalia: la recolección manual de recursos.

Como deuda técnica, nos proponemos terminar de pulir el movimiento del personaje principal (se inició el Sprint pasado con el prototipo) para que la cámara siga al personaje.

¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?

Primero, de cara a centrar mejor nuestra gestión de proyecto, nos comprometemos a terminar de elaborar los documentos Scrum que faltan (DoD, PMV, pruebas unitarias, Identificación y gestión de Riesgos), así como revisar conjuntamente las historias de Usuario teniendo en cuenta el feedback del profesor.

Después, como objetivo secundario, queremos usar este Sprint para medir nuestra capacidad de desarrollo como equipo en vista de definir objetivos realistas en futuros Sprints. En este Sprint, trabajamos de forma independiente en cada tarea y compartimos los avances realizados en clase.

Sprint 3

Sprint Goal: mecánicas de recolección de recursos, construcción de casas y reclutamiento de soldados.

  • Incremento: recolección de recursos.
  • Incremento: construcción de casas.
  • Incremento: reclutamiento de soldados.

¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?

El objetivo principal de este Sprint es abordar las mecánicas de recolección de recursos y construcción de casas (que tiene Prioridad Must Have en el Product Backlog). De esta forma, quedarían abordados todos los recursos primarios: recursos humanos (aldeanos) y materiales (madera, piedra y oro).

  • La mecánica de recolección se inició en el Sprint pasado y es de máxima prioridad.
  • La mecánica de construcción de casas se va a implementar desde cero y depende de lo anterior.
  • La mecánica de reclutamiento de soldados se va a implementar desde cero y depende de la construcción de casas.

En menor orden de prioridad, se plantea como objetivo secundario ampliar el mapa. Sin embargo, esto sólo se hará si nos sobra tiempo, porque las mecánicas esenciales del PMV se pueden testar en el mapa actual.

¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?

Primero, de cara a mejorar nuestra gestión de proyecto como equipo y después de hacer retrospectiva del Sprint 2, hemos decidido lo siguiente.

  • Cualquier avance, retroceso, dificultad o estancamiento en una tarea se notifica al equipo entero.
  • Las tareas relativas a la programación de las funcionalidades de las mecánicas principales serán hechas por grupos de 3-4 personas auto-coordinadas que compartirán avances y recursos para la implementación.
    • Estas tareas se abordarán tan pronto como sea posible.
    • Pretendemos terminar las mecánicas de recolección de recursos y construcción de casas la primera semana del Sprint.

En este Sprint, no trabajaremos de forma independiente, sino que procuraremos comunicarnos mejor y trabajar en equipos pequeños cuando una tarea no se abordable por una persona.

Sprint 4

Sprint Goal: multijugador, ataque y refinamiento de la construcción de casas.

  • Incremento: implementar el juego multijugador.
  • Incremento: implementar la mecánica de ataque.
  • Incremento: construcción de casas.

¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?

El objetivo principal de este Sprint es abordar la mecánica de ataque, que decidirá el ganador de la partida. Para lograrlo, también abordaremos la implementación de juego multijugador, que es esencial en Feudalida. Ambas cuestiones suponen un incremento sustancial que nos permite alcanzar nuestra visión de PMV por lo que tienen Prioridad Must Have en el Product Backlog (véase en el kanban ubicado en el apartado de projects). De esta forma, quedaría abordado el desarrollo de una partida: recolección de recursos, construcción y compra de soldados (funcionalidades ya implementadas) en una primera etapa, ataque en una segunda etapa y decisión del ganador después de la batalla.

  • La mecánica de construcción se hizo funcional en el Sprint pasado y es de gran prioridad que se termine de pulir para conseguir una experiencia de juego limpia.
  • La mecánica multijugador es imprescindible y de máxima prioridad en este Sprint.
  • La mecánica de ataque se va a implementar desde cero y depende del modo multijugador.

En menor orden de prioridad, se plantea como objetivo secundario elaborar un sistema de inicio de sesión y registro de nuevos usuarios. Sin embargo, esto sólo se hará si nos sobra tiempo, porque la disponibilidad del equipo en este Sprint es más reducida que en el anterior.

¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?

Mantenemos lo dicho en el Sprint 3 y añadimos lo siguiente teniendo en cuenta la retrospectiva de este Sprint y la introducción de Revisiones Técnicas formales a nuestro proceso Scrum:

  • Cada miembro del equipo comunicará su disponibilidad horaria para facilitar la fluidez del desarrollo.
  • Las Revisiones Técnicas Formales de otros equipos se harán en equipos de 2-3 personas.
  • Pretendemos implementar la función multijugador y el diseño de las escenas necesarias para el ataque en la primera semana del Sprint.
  • Implementaremos un proceso de RTF más estandarizado para pulir las mecánicas hechas y por hacer.
  • Implementaremos el campo de batalla en un nodo separado del main, para facilitar el trabajo en paralelo y evitar merges de GitHub problemáticos.

También, en vista de la Retrospectiva del Sprint 3, nos comprometemos a ser más cuidadosos al mover y crear tareas en el Kanban. Así que, en este Sprint, vamos comprobar constantemente si ha habido comentarios nuevos en las tareas en las que estemos involucrados, así como que todos los metadatos de nuestras tareas estén completados bajo los criterios acordados en el Product Backlog.

Sprint 5

Sprint Goal: refinamiento de multijugador, NPCs (recolectores automáticos), bot para 1 jugador y construcción de puentes.

  • Incremento: refinar y terminar el juego multijugador.
  • Incremento: implementar la recolección automática con NPCs.
  • Incremento: implementar una opción de juego contra la máquina.
  • Incremento: implmentar la mecánica de exploración en el cuadrante asignado mediante la construcción de puentes.

¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?

El objetivo principal de este Sprint es refinar el funcionamiento del modo multijugador, gestionar las caídas, desconexiones, creación de varios lobbys en red... Este incremento se complementa con otra funcionalidad nueva: crear una opción que permita al jugador jugar una partida contra la máquina, sin el modo multijugador. Ambas cuestiones son una continuación de funcionalidades que ya comenzamos en el Sprint anterior.

Por otro lado, pretendemos implementar desde cero la recolección automática de recursos. Esto implica la construcción de "edificios especializados" (véase el Documento de Especificación) y de NPCs "recolectores". De esta forma, incluimos en nuestro proyecto algoritmos avanzados, cumpliendo todos los requisitos del proyecto planteado en esta asignatura.

  • La mecánica de multijugador se hizo funcional en el Sprint pasado y es de gran prioridad que se termine de pulir para que el jugador no tenga problemas para unirse o crear un lobby.
  • La opción de jugar contra la máquina es imprescindible y de máxima prioridad en este Sprint, puesto que permite juegos de 1 jugador y nos facilitará el testeo del programa.
  • La mecánica de recolección automática es muy importante en este Sprint, y es independiente del resto de incrementos.
  • La mecánica de construcción de puentes es una mejora potencial del juego significativa, pero tiene menor prioridad que el resto de incrementos por ser una funcionalidad extra.

En menor orden de prioridad, se vuelve a plantear como objetivo secundario elaborar un sistema de inicio de sesión y registro de nuevos usuarios. De nuevo, esto sólo se hará tras completar el resto de tareas, porque la disponibilidad del equipo en este Sprint es aún más reducida que en el anterior.

¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?

Mantenemos lo dicho en el Sprint 4 y añadimos lo siguiente teniendo en cuenta la retrospectiva de este Sprint y la introducción de Revisiones Técnicas formales (internar y externas) a nuestro proceso Scrum:

  • Haremos un esfuerzo por mantener la comunicación de todo el equipo activa.
  • Avanzaremos en los 3 incrementos de forma paralela, por ser independientes.
  • Nos comprometemos a organizar todo el código en carpetas, dependiendo de la funcionalidad, para facilitar la legibilidad.
  • Comunicaremos al resto del equipo cuándo iniciamos procesos de depuración, puesto que, si dos programadores depuran a la vez, podría darse el caso de que se conectasen al mismo lobby con versiones distintas. Así evitamos problemas de sincronización.

También, en vista de la Retrospectiva del Sprint 4, nos comprometemos a tener más presente la prioridad de tareas en el Kanban. Además, en vista de que quedan 2 Sprints de trabajo, hemos abordado de manera general qué tareas queremos y podemos abordar del producto final de cara a la entrega final. En este Sprint buscamos que el juego sea completamente funcional, pero sin terminar de pulir el aspecto gráfico.

Sprint 6

Sprint Goal: refinamiento visual del juego y pulido de mecánicas.

  • Incremento: refinar el aspecto del juego (añadir pantallas de transición, mensajes para el jugador, efectos audiovisuales...).
  • Incremento: pulir la recolección automática con NPCs.
  • Incremento: pulir la construcción de puentes.

¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?

El objetivo principal de este Sprint es refinar la experiecia de juego en general. Este incremento incluye pulir las mecánicas ya existentes (principalmente cuestiones del modo multijugador y recolección automática). Ambas cuestiones son una continuación de funcionalidades que ya comenzamos en el Sprint anterior y en el caso particular del modo multijugador, debemos valorar si el esfuerzo que implica conseguir que funcione en versión web (si fuera siquiera posible) es asumible.

Por otro lado, pretendemos probar nuestro juego con un público general. Es decir, en cuato el juego funcione y esté libre de bugs, se enviará un fichero exportable a terceros que no estén familiarizados con esta asignatura, para poder testear el juego, identificar posibles bugs y comprobar si el juego es suficientemente intutitivo o si necesita más aclaraciones. De esta forma, incluimos en nuestro proyecto un control de calidad más elaborado que el que podemos conseguir probándolo entre nosotros.

  • La mecánica de recolección automática se empezó el Sprint pasado y es de máxima prioridad terminar de depurarlo.
  • La mecánica de construcción de puentes se completó el Sprint pasado, pero es importante reforzarla con animaciones y efectos visuales.
  • Añadir mensajes informativos para el jugador es imprescindible para que sea consciente del estado de su partida en todo momento.
  • Añadir transiciones y efectos visuales no es imprescindible, pero es muy beneficioso para la experiencia del jugador. No obstante, coincidimos en que algunos añadidos son más prioritarios:
    • Tener una sala de espera que informe al jugador del estado de su conexión cuando intente unirse a una partida PVP.
    • Tener un color distinto para cada jugador.
  • Valorar la factibilidad de tener un modo multijugador en web es imprescindible para lanzar el producto.

Al ser este el Sprint final, el Sprint de pulido, no añadiremos taras extra planificadas. Cada programador incluirá las aportaciones visuales que considere y aplicaremos esta dinámica (manteniendo al equipo informado de cualquier cambio en todo momento) hasta la fecha de entrega del proyecto, aplicando la Ley de Parkinson.

¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento?

En vista al Sprint pasado y debido a la complejidad del proyecto identificamos un problema significativo de solapamiento y revisión de errores. Para facilitar el flujo de trabajo nos comprometemos a lo siguiente:

  • Realizar pruebas de integración constantemente: antes y después de realizar ningún cambio.
  • Informar de cualquier avance y error encontrado lo antes posible.
  • Solucionar los problemas y errores en el momento en el que se encuentran, para no acumularlos.
  • Informar al programador correspondiente si hay algún aspecto de una funcionalidad que da problemas, en qué modo (PVE, PVP o ambos), cuándo y bajo qué inputs ocurre.

También, en vista de la Retrospectiva del Sprint 5, nos comprometemos a asegurarnos de que no se sobreescriben funcionalidades al implementar otras, ya que esta cuestión ha sido un problema continuado en el tiempo que no nos ha permitido avanzar de manera lineal, constante y estable.