DEFINICIÓN DEL PROCESO DE DESARROLLO

El proceso de desarrollo a seguir será un proceso ágil. Las ventajas de este tipo de proceso que nos han llevado a seleccionarlo son las siguientes:

• Se adapta a proyectos pequeños y medianos. Esto nos permite la libertad de ajustar los diferentes pasos y las metodologías a un proyecto universitario.
• Iterativo. Las reuniones semanales con el maestro permitirán implementar el feedback recibido más fácilmente.
• Buena definición del equipo. Dado que somos estudiantes universitarios con diferentes horarios, este proceso nos ayudará a organizarnos mejor.
• Hace hincapié en el producto final. Al estar centrados en resultados, se adecua a las evaluaciones académicas que determinan nuestra nota.
• Requisitos y garantía de calidad basados en pruebas. Una adecuada definición de los requisitos y pruebas para validar la calidad de nuestro trabajo serán claves para el éxito.

Desventajas

• Difícil de ampliar a grandes proyectos: Esto no será un problema dado que nuestro proyecto es de tamaño medio.
• Requiere experiencia y habilidades: Aunque relevante, el contexto estudiantil nos ofrece un mayor margen de error.
• La construcción de casos de prueba es compleja: La experiencia previa en la universidad nos ha ayudado a desarrollar esta habilidad, lo cual reducirá el impacto.

IDENTIFICACIÓN DEL MODELO DEL PROCESO DE DESARROLLO

Decidimos utilizar SCRUM como metodología para nuestro proyecto debido a:

• Flexibilidad y adaptabilidad a equipos pequeños.
• Gestión de requisitos cambiantes gracias a la retroalimentación semanal con el profesor.
• Sprints cortos para la entrega incremental de funcionalidades.
• Reuniones frecuentes para mantener la comunicación constante y resolver problemas rápidamente.
• Roles claramente organizados que nos permiten ajustar el desarrollo según las necesidades.

DEFINICIÓN DEL EQUIPO DE TRABAJO

Hemos definido cuatro roles principales para garantizar una colaboración efectiva:

• Product Owner (PO): Define y prioriza las funcionalidades del producto, gestionando el backlog.
• Scrum Master (SM): Facilita el proceso ágil y ayuda al equipo a seguir las prácticas de SCRUM.
• Desarrollador Senior (DS): Lidera el desarrollo técnico y guía al equipo en la arquitectura.
• Desarrollador Junior (DJ): Apoya al Desarrollador Senior y colabora en tareas más básicas.

CÁLCULO DEL ESFUERZO DEL EQUIPO

Usaremos la métrica de horas-esfuerzo para calcular la capacidad del equipo. A continuación, mostramos las horas disponibles de cada miembro:

Pablo Pérez Risco

Día	Mañana	Tarde
Lunes	Ocupado	2 horas
Martes	Ocupado	Ocupado
Miércoles	2 horas	2 horas
Jueves	2 horas	2 horas
Viernes	Ocupado	Ocupado

• Horas disponibles por iteración: 13 horas
• Horas disponibles para otros proyectos: 3 horas
• Tiempo personal (20%): 2 horas
• Tiempo de Gestión: 2.5 horas
• Relación horas-esfuerzo disponible: 10.5 horas

Amanda Merino Tapia

Día	Mañana	Tarde
Lunes	Ocupado	2 horas
Martes	Ocupado	Ocupado
Miércoles	2 horas	2 horas
Jueves	2 horas	3 horas
Viernes	Ocupado	Ocupado

• Horas disponibles por iteración: 14.5 horas
• Horas disponibles para otros proyecto: 3.5 horas
• Tiempo personal (20%): 2.2 horas
• Tiempo de Gestión: 2.5 horas
• Relación horas-esfuerzo disponible: 11.3 horas

Jaime Masa Pastor

Día	Mañana	Tarde
Lunes	Ocupado	2 horas
Martes	Ocupado	Ocupado
Miércoles	2 horas	2 horas
Jueves	Ocupado	Ocupado
Viernes	2 horas	Ocupado

• Horas disponibles por iteración: 10 horas
• Horas disponibles para otros proyecto: 2 horas
• Tiempo personal (20%): 1.6 horas
• Tiempo de Gestión: 1 horas
• Relación horas-esfuerzo disponible: 7.4 horas

Alexis Sancho Garrido

Día	Mañana	Tarde
Lunes	Ocupado	2 horas
Martes	2 horas	Ocupado
Miércoles	Ocupado	2 horas
Jueves	2 horas	Ocupado
Viernes	Ocupado	2 horas

• Horas disponibles por iteración: 19 horas
• Horas disponibles para otros proyecto: 10 horas
• Tiempo personal (20%): 2 horas
• Tiempo de Gestión: 0 horas
• Relación horas-esfuerzo disponible: 7 horas

DEFINICIÓN DE LA PLANIFICACIÓN ADAPTADA AL PROCESO

• Sprint: Los sprints son bloques de tiempo en los que se crean incrementos del producto para desarrollar poco a poco una versión entregable y funcional del mismo. En un proyecto comercial, los sprints durarían como máximo un mes, pero en nuestro caso serán de una semana aproximadamente, al tener que desarrollar un proyecto de dimensiones más reducidas.

• Reunión de planificación del Sprint (Sprint Planning Meeting): Estas reuniones se realizan al comienzo de cada sprint para designar los objetivos a desarrollar durante el mismo, así como su forma de consecución. De esta forma, se sabrá cuántas funcionalidades pueden hacerse correctamente por bloque de tiempo, definiendo así la capacidad de trabajo del equipo. En nuestro caso, sí podremos implementar estas reuniones al comienzo de cada sprint.

• Scrum diario (Daily Scrum): En este tipo de reuniones se chequea el progreso diario del equipo, así como se revisan los obstáculos que han tenido en la realización de tareas y se proporcionan posibles soluciones a estos problemas por parte del resto del equipo. En nuestro caso no nos es posible implementar las reuniones diariamente, sino que se pueden tratar en reuniones esporádicas (cada 2-3 días) en su lugar.

• Revisión del Sprint (Sprint Review): Son reuniones concertadas al final de cada sprint en las que se chequea la funcionalidad del incremento de trabajo realizado, así como se habla de los problemas surgidos a raíz de desarrollar los problemas y se determinan las tareas a concluir durante el próximo sprint. En nuestro caso, al delimitar los sprints por semanas, se haría esta reunión semanalmente.

• Retrospectiva del Sprint (Sprint Retrospective): En estas reuniones se proponen e implementan mejoras para el próximo sprint. En nuestro caso, estas reuniones se harían junto con las anteriores, unificando el tiempo de ambas en aproximadamente 1 ó 2 horas, ya que los sprints se darían semanalmente.

• Product Backlog: Es la lista de tareas que son necesarias en el proyecto. Están definidas por el Product Owner y evoluciona a lo largo del proyecto con funcionalidades, mejoras y requisitos nuevos. Se ordena por prioridad o complejidad de tareas. En nuestro caso, este artefacto difícilmente será expandido, ya que el proyecto no tiene una meta comercial y no es necesario que se añada más de lo que ya se tiene planificado en un principio.

• Sprint Backlog: Es el conjunto de tareas del Product Backlog que se seleccionan para un sprint, es decir, el incremento de trabajo del proyecto para cada bloque de tiempo del que este dispone. En ocasiones, puede eliminarse alguna tarea de esta pila, ya que pueden ser consideradas innecesarias o pueden demorarse hacia el sprint siguiente, alargando también la longitud temporal del proyecto. En nuestro caso, cada Sprint Backlog constará de las tareas de una historia de usuario a cada vez, ya que el desarrollo del proyecto debe hacerse en un mes y disponemos de 4 historias de usuario.