Decisiones y justificaciones

En esta página recogemos las principales decisiones que hemos ido tomando durante la planificación de Subsonic Festival y los motivos por los que hemos elegido cada una de ellas.

ID	Decisión	Justificación	Fecha
D-01	Utilizar Scrum	Hemos elegido Scrum porque es el marco de trabajo que seguimos en la práctica y nos permite organizar las tareas por sprints.	01/10/2026
D-02	Organizar el trabajo en seis sprints de una semana	Inicialmente habíamos distribuido el trabajo en cuatro sprints, pero tras revisar las indicaciones de la práctica hemos ajustado la planificación a seis iteraciones semanales.	16/10/2026
D-03	Organizar las entregas en tres releases	Hemos establecido tres releases de dos semanas, agrupando dos sprints en cada una. Las historias de usuario se distribuyen entre las seis iteraciones teniendo en cuenta su prioridad, esfuerzo y dependencias.	16/10/2026
D-04	Priorizar las historias de usuario con MoSCoW	Nos permite diferenciar los requisitos más importantes de aquellos que pueden dejarse para más adelante si no disponemos de tiempo suficiente.	11/10/2026
D-05	Revisar las estimaciones de las historias de usuario	Después de comparar las estimaciones individuales y realizar la revisión de planificación, ajustamos el esfuerzo total de 135 a 115 horas, ya que nos dimos cuenta de que podríamos reutilizar las distintas estructuras de las vistas. Estas 115 horas corresponden exclusivamente al desarrollo de los requisitos.	11/10/2026
D-06	Estimar la disponibilidad del equipo	Hemos considerado 6,25 horas semanales por persona para el desarrollo de los requisitos, equivalentes a una hora y quince minutos diarios de lunes a viernes. Esto supone 31,25 horas semanales entre los cinco integrantes y una capacidad total de 187,5 horas durante las seis iteraciones. Las reuniones y revisiones se realizan fuera de este tiempo.	16/10/2026
D-07	Revisar las dependencias entre requisitos	Durante la revisión detectamos que algunas historias necesitaban tener otras completadas previamente. Por eso añadimos dependencias entre los requisitos y comprobamos que su distribución en las iteraciones respetase el orden de ejecución.	11/10/2026
D-08	Dejar un margen de tiempo en la planificación	Los requisitos tienen un esfuerzo estimado de 115 horas y la capacidad disponible del equipo durante las seis semanas es de 187,5 horas. Esto deja un margen de 72,5 horas ante posibles imprevistos, retrasos o cambios en las estimaciones.	16/10/2026
D-09	Utilizar Excel para organizar la planificación	Hemos utilizado un Excel para reunir las historias de usuario, sus estimaciones, prioridades, responsables, sprints y dependencias. También hemos incluido el reparto de horas, la planificación inicial y un diagrama de Gantt para visualizar mejor la distribución del trabajo.	11/10/2026
D-10	Separar el tiempo de desarrollo de las tareas de gestión	Hemos decidido que las 115 horas estimadas y la disponibilidad de 6,25 horas semanales por persona se destinen únicamente a los requisitos. Las reuniones de Scrum, revisiones y demás tareas de gestión se realizarán aparte, por lo que no se incluyen en las horas ni en el coste estimado de los requisitos.	16/10/2026
D-11	Adaptar el calendario a las seis iteraciones	Hemos organizado la planificación en seis sprints semanales. Para calcular la capacidad de desarrollo hemos establecido una disponibilidad de lunes a viernes, de 09:00 a 10:15, lo que supone 6,25 horas semanales por integrante.	16/10/2026
D-12	Reajustar el reparto de las historias entre los integrantes	Al ampliar la planificación a seis iteraciones, hemos revisado la asignación de los requisitos y distribuido las horas entre los miembros del equipo. Algunas historias se reparten entre varios integrantes para respetar la disponibilidad semanal, manteniendo las 115 horas estimadas para los requisitos.	16/10/2026
D-13	Utilizar ProjectLibre para representar la planificación	Hemos decidido trabajar con dos vistas de la planificación: una organizada por iteraciones (IT-001 a IT-006) y otra agrupada por épicas (EP-001 a EP-007). Ambas deben reflejar las mismas historias, asignaciones, dependencias y estimaciones del Excel actualizado.	16/10/2026
D-14	Fijar las tarifas por rol y el coste estimado en 3.795 €	Hemos asignado tarifas por hora según la responsabilidad de cada rol: Tech Lead (40 €/h), Product Owner (35 €/h), DevOps/QA (35 €/h), Scrum Master (30 €/h) y Developer (25 €/h). Con 23 horas de requisitos asignadas a cada integrante, el coste estimado es de 3.795 €. Este importe corresponde al trabajo asignado y no a toda la capacidad disponible.	16/10/2026

---

Resumen

Después de revisar la planificación y adaptarla a las seis iteraciones, el proyecto queda organizado de la siguiente manera:

• Duración: 6 semanas, divididas en 6 sprints de una semana y agrupadas en 3 releases de dos semanas.
• Horas estimadas: 115 horas para desarrollar los 19 requisitos. Las reuniones de Scrum, revisiones y demás tareas de gestión no están incluidas.
• Capacidad del equipo: Cada integrante dispone de 6,25 horas semanales para desarrollar los requisitos. Entre los cinco integrantes contamos con 31,25 horas semanales y 187,5 horas en las seis semanas.
• Margen disponible: 72,5 horas de capacidad no asignada, que servirán para afrontar posibles retrasos o imprevistos.
• Reparto del trabajo: Cada integrante tiene asignadas 23 horas de requisitos en el conjunto del proyecto, distribuidas entre las seis iteraciones sin superar las 6,25 horas semanales.
• Coste estimado de los requisitos: 3.795 € en total (Javi López: 805 € | Alfonso Guillén: 690 € | Manuel Lorenzo: 920 € | Juan Antonio Jara: 805 € | Raúl Arias: 575 €).
• Herramientas de planificación: Utilizamos Excel para organizar los requisitos, las estimaciones y el reparto de horas, y ProjectLibre para representar el calendario, las dependencias y los recursos.

Posibles problemas que hemos tenido en cuenta

1. Retrasos en el desarrollo: Aunque ahora tenemos un margen de tiempo mayor, revisaremos el avance de los requisitos al finalizar cada sprint. Si surge algún imprevisto, podremos reorganizar las tareas pendientes teniendo en cuenta su prioridad MoSCoW.

2. Dependencias entre historias de usuario: Algunas funcionalidades necesitan que otras estén terminadas previamente. Por eso hemos revisado el orden de las historias en las seis iteraciones para evitar que una tarea comience antes de disponer de lo necesario.

3. Distribución de las horas del equipo: Algunas historias requieren más tiempo del que una sola persona tiene disponible en una semana. Para evitar sobrecargas, hemos repartido estas historias entre varios integrantes, manteniendo sus estimaciones totales.