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

Estimación del proyecto

En el desarrollo del proyecto Feudalia, se adoptó un enfoque práctico y evolutivo hacia la estimación del esfuerzo. Se priorizó el aprendizaje iterativo y la validación empírica sobre la predicción teórica. Las técnicas de estimación utilizadas han sido adaptadas y validadas a través de la experiencia real del equipo durante los sprints.

Este documento describe las técnicas de estimación que se implementaron en Feudalia, su justificación práctica, su evolución a lo largo del ciclo de desarrollo.

Los resultados obtenidos se reflejan en el Kanban de cada Sprint.

1. Retraso de la Estimación Formal

Durante los Sprints 1 y 2, no se realizaron estimaciones formales de esfuerzo. El foco se centró en:

Familiarización con el motor Godot.
Definición del flujo de trabajo del equipo.
Análisis de la viabilidad técnica de las funcionalidades clave.

La ausencia de estimaciones formales en esta fase se debe a:

La ausencia de tareas de implementación de funcionalidades definitivas a comienzos del Sprint 1.
La falta de experiencia previa programando en Godot en el Sprint 2. Las estimaciones informales de este sprint fueron altamente imprecisas y no se consiguieron lograr todos los objetivos planificados.

Al retrasar la estimación hasta el Sprint 3, el equipo mejoró:

Reducir la variabilidad en las predicciones de esfuerzo.
Fundamentar las estimaciones en datos reales, no en suposiciones.

Conclusión: El retraso de la estimación sistemática fue una práctica efectiva que mejoró la calidad de las predicciones posteriores.

2. Estimación por Analogía como Técnica Principal

A partir del Sprint 3, la técnica dominante de estimación fue la estimación por analogía, basada en tareas previamente completadas.

La funcionalidad de recolección de recursos (Sprint 2) se convirtió en el caso de referencia para estimaciones posteriores, debido a su complejidad representativa: implicaba interacción con objetos, validación de recursos, animaciones y actualización de estado.

Referencia: la recolección de recursos se terminó en 7 días aproximadamente.

Tarea	Tarea de referencia	Estimación	Justificación
Construcción de edificios	Recolección de recursos	8 días	Similar estructura de interacción, pero requiere nuevos elementos de programación (como la instanciación de objetos en el mapa durante el juego), más estados de animación y más conflictos potenciales (construir en zonas no designadas para ello).
Compra de soldados	Recolección de recursos	3 días	Misma lógica de consumo de recursos y creación de entidad, mismo número de tipos y sin animación de recolección.
Crecimiento de la población	Recolección de recursos	3 días	Misma lógica de comunicación entre objetos del mapa y gestor de recursos. Se le añade la complejidad de modificar la población de forma lineal.

Esta técnica permitió:

Reducir la subjetividad en las estimaciones.
Establecer una base de comparación coherente y reproducible.
Aumentar la confianza del equipo en nuestras predicciones.

Observación clave: Hay tareas que no pudimos estimar en base a la Recolección de Recursos por ser esencialmente distintas e incomparables. Este es el caso de la implementación de:

Multijugador.

Sistema de login.

Sistema de ataque.

3. Descomposición del Proceso por Fases

En las reuniones de equipo discutimos la estimación de cada tarea del Sprint en base a las siguientes fases estandarizadas:

Fase	Descripción	Tiempo típico por tarea
Análisis	Definición de requisitos, condiciones de éxito y dependencias.	1-2 horas
Diseño	Selección de nodos, estructura de escena, señales, flujos de control y diseño de pruebas unitarias.	2-6 horas
Codificación	Implementación de scripts en C#, configuración de propiedades y conexión de componentes.	4-18 horas
Pruebas	Validación funcional, corrección de bugs, ajuste de parámetros y pruebas de integración.	3–8 horas

Ejemplo: Modo multijugador

Análisis: 6 horas - Definir qué tipo de funcionalidad multijugador buscamos y cómo se relaciona con el login. Investigación de herramientas nativas de Godot y análisis de otros proyectos hechos en Godot para decidir cómo trasladarlo a Feudalia.
Diseño: 5 horas - Estructura del Multijugador, plugins necesarios, adaptación de nodos ya existentes para que se coordinen con este cambio.
Codificación: 10 h - Scripts necesarios, carga de escena principal y timer en ambos usuarios...
Pruebas: 6 horas - Comprobación de que todas las funcionalidades se coordinan para todos los jugadores, funciona bien entre máquinas con distinto Software...
Total estimado (suponiendo un trabajo medio de 2 horas por día): 11 días → Total real: ???

La descomposición por fases nos facilita:

Identificar qué fases son más problemáticas en términos de estimación.
Mejorar la asignación de tareas según las habilidades del equipo.
Aumentar la transparencia en la planificación.

4. Estimación por Puntos de Función (PF)

Dado que Feudalia se desarrolla en Godot Engine, donde gran parte de la funcionalidad se implementa mediante nodos, animaciones y configuraciones visuales en lugar de código lineal, se rechazó la estimación por Líneas de Código (LDC) como métrica inadecuada.

En su lugar, se adoptó una métrica de Puntos de Función (PF), definida como:

Una unidad funcionalidad observable en el juego que se implementa o configura como un nodo, script, animación o interacción independiente.

4.1. Ejemplos de PF:

Botón de "Comprar Soldado" → 1 PF
Animación de personaje caminando → 1 PF
Pantalla de inicio de juego → 1 PF
Colisión entre jugador y recurso → 2 PF (porque intervienen el nodo del jugador y del recurso)
Timer visible por el jugador → 1 PF (no se crean nodos, pero se programa el script pertinente)
Creación de un documento de la Wiki → 1 PF (estimamos también tareas de índole administrativa porque la documentación estructurada y completa es una parte significativa de nuestro proyecto)

4.2. Calibración de la métrica

Tras analizar el desempeño de las tareas de los primeros Sprints, se determinó empíricamente que:

Cada PF requiere aproximadamente 1 día de trabajo de implementación (fase de codificación) y 1 día de revisión (fase de pruebas: unitarias y de integración). Excepto, los PF de tareas que requieren tienen una fase de análisis y diseño más complejas. En este caso son 3-5 días de trabajo.

Esta relación fue validada con una precisión del ±1 día en tareas posteriores.

4.3. Tabla: Estimación por Puntos de Función (PMV)

Nota: estimamos las funcionalidades principales esenciales para Feudalia. Estas tareas se abordaron como "objetivo principal" en algún Sprint.

División de Feudalia	PF Estimados	Tipo de PF	Horas Estimadas (PF × 3 horas)	Notas
Pantallas iniciales (inicio de sesión y menús)	8	Media	24 horas	3 botones (inicio de sesión, registro de usuario y play), 2 inputs (registro de usuario e inicio de sesión), 1 menú, 1 pantalla de estadísticas.
Recolección de recursos	8	Media/Compleja	24 horas	Interacción (2 PF), animación (1 PF), contador (2 PF), implementación en los 3 recursos (3 PF)
Construcción de edificios	9	Compleja	27 horas	Casas (1 PF), 3 edificios de recolección especializados (3 PF), menú de construcción (2 PF), visualización de dónde se construye la casa (3 PF)
Compra de soldados	8	Media	24 horas	Similar a la recolección de recursos, sin animación de construcción, con menú desplegable
Sistema de ataque	12	Compleja	36 horas	Campo de batalla, movimiento de NPCs, animación, pantalla win/loose
Multijugador	15	Muy compleja	45 horas	Investigación sobre cómo implementarlo, conexión, sincronización, estado de jugador, manejo de errores
TOTAL	60 PF	—	180 h

5. Resultados Reales

Las estimaciones realizadas para cada funcionalidad se pueden comprobar en cada Kanban Sprint en la visualización de "Roadmap".

Precisión general: La estimación de cada tarea se cumplió en términos generales a partir del Sprint 3.
Tendencia: Las tareas más complejas (multijugador, recolección de recursos) se subestimaron al comienzo del Sprint en el que se implementaron, pero dentro del rango esperado para tareas de implementación de funcionalidades no conocidas por el equipo.

6. Aplicación de la Ley de Parkinson

La Ley de Parkinson ("el trabajo se expande para llenar el tiempo disponible") fue aplicada de forma estratégica y proactiva, como una herramienta de gestión del flujo.

Cada sprint incluye 1-3 tareas, desglosadas en subtareas, de "relleno" de baja prioridad, registradas en el Kanban tras las tareas críticas.

Impacto:

Mantuvo el ritmo de entrega: El equipo nunca está parado.
Fomentó la mejora continua: Se implementan mejoras no planificadas a lo largo de los Sprints.
Redujo la presión: No consideramos "errores de estimación" la no finalización de estas tareas.
Aumentó la satisfacción del equipo: El incremento por Sprint es igual o mejor al esperado.

7. Aclaraciones

7.1. ¿Cómo se reflejan las Técnicas de Estimación en el Kanban de cada Sprint?

En la práctica estimamos el coste de las tareas del Kanban en días de trabajo porque consideramos que es más óptimo teniendo en cuenta que nuestros horarios son bastante dispares. Así, cuando una tarea está en "In progress", es más sencillo que el resto del equipo sepa cuándo puede empezar a desarrollar tareas que dependen de esta.
Todas nuestras técnicas de estimación son de descomposición en el sentido de que las tareas más amplias y de mayor coste estimado se descomponen en problemas más pequeños y fácilmente abordables.
- Procuramos que en el Kanban las tareas queden divididas en base a su tamaño en Puntos de Función, de manera que cada subtarea es un nodo simple, sprite, función o animación sencilla.
Todas las estimaciones que se encuentran en el Kanban se asignan en base a un valor medio. Si tenemos información previa, nos basamos en los datos y en la experiencia, y si estamos implementando funciones nuevas que no conoce ninguno de los programadores, nos basamos en la intuición.

7.2. Rechazo de la Estimación por Líneas de Código (LDC)

La estimación por LDC fue descartada desde el inicio por las siguientes razones:

Godot es un entorno visual: Gran parte del desarrollo se realiza mediante la configuración de nodos, animaciones y señales, no mediante código lineal.
La cantidad de código no refleja el esfuerzo: Una función de 5 líneas puede requerir 6 horas de depuración por errores de conexión de señales.
No es una métrica razonable en nuestro juego: No medimos la productividad en líneas, sino en funcionalidades observables.

Por todo ello, se optó por una métrica funcional (PF) que refleja mejor el esfuerzo real.