El proyecto PreguntaT se ha desarrollado siguiendo la metodología SCRUM, un marco de trabajo ágil que permite entregar valor de forma iterativa e incremental mediante sprints de duración fija.

SCRUM es un marco de trabajo ágil para gestión de proyectos que se basa en:

• ✅ Iteraciones cortas (sprints de 1-4 semanas)
• ✅ Equipos autoorganizados y multifuncionales
• ✅ Entrega incremental de valor
• ✅ Mejora continua mediante retrospectivas
• ✅ Transparencia, inspección y adaptación

Acciones de Mejora Sprint 3:

1. ✅ Crear colección Postman para API endpoints
2. ✅ Implementar pre-commit hook para ESLint
3. ✅ Daily standups máximo 10 minutos

Seguimiento:

• Acciones se convierten en tareas del Sprint Backlog del próximo sprint
• Se revisan en la siguiente Retrospective para validar implementación

Definición: Lista priorizada de todas las funcionalidades, mejoras y bugs del producto.

Ubicación: GitHub Projects - Columna "Backlog"
Responsable: Product Owner (con input del equipo)

Formato de Items:

**Título:** Como [rol], quiero [funcionalidad] para [beneficio]
Descripción:

Criterios de aceptación claros
Estimación en Story Points
Prioridad (Crítica, Alta, Media, Baja)
Categoría (Backend, Frontend, DevOps, etc.)

Ejemplo:
Título: Como usuario, quiero recibir feedback detallado después de cada respuesta para mejorar mi rendimiento
Criterios de aceptación:

 Feedback aparece inmediatamente después de responder
 Incluye puntuación numérica (0-100)
 Muestra fortalezas y áreas de mejora
 Feedback es personalizado (no genérico)

Estimación: 5 SP
Prioridad: Alta
Categoría: Backend + Frontend

Definición: Subconjunto del Product Backlog seleccionado para el sprint actual.

Ubicación: GitHub Projects - Columnas "To Do", "In Progress", "In Review"
Responsable: Development Team

Características:

• ✅ Tareas seleccionadas en Sprint Planning
• ✅ Estimadas y asignadas a desarrolladores
• ✅ Incluye tareas técnicas (no solo features)
• ✅ Se actualiza diariamente según progreso

Estados de una tarea:

1. To Do: Pendiente de comenzar
2. In Progress: En desarrollo activo
3. In Review: Pull Request creado, esperando code review
4. Done: Merged a main, cumple Definition of Done

Definición: Suma de todos los items del Product Backlog completados en el sprint + incrementos de sprints anteriores.

Requisito: Debe ser potencialmente desplegable (cumple Definition of Done).

En PrepáraT:

• Al final de cada sprint, el increment incluye:
  • Código funcional y testeado
  • Documentación actualizada
  • Desplegable en entorno de staging

Ejemplo Sprint 2:

Increment Sprint 2:
- CRUD completo de entrevistas funcional
- Sistema de estados validado
- 5 componentes React nuevos
- Tests con 82% cobertura
- API documentada en API.md
Estado: ✅ Desplegable en staging

Una tarea/historia se considera "Done" cuando cumple TODOS estos criterios:

• Funcionalidad implementada completamente según criterios de aceptación
• Código sigue convenciones del proyecto (ESLint + Prettier)
• Sin warnings ni errors en consola (navegador o terminal)
• Sin código comentado o debug statements (console.log)

• Tests unitarios escritos y pasando (si aplica)
• Cobertura de tests >80% para funciones críticas
• Testing manual ejecutado por QA Lead
• Sin bugs críticos conocidos

• Pull Request creado en GitHub
• Al menos 1 aprobación del Tech Lead
• Todos los comentarios del review resueltos
• CI/CD pipeline pasando (cuando esté configurado)

• JSDoc completo para nuevas funciones/componentes
• README.md actualizado si hay cambios de setup
• Comentarios en código para lógica compleja
• API.md actualizado si hay nuevos endpoints

• Código merged a rama main
• Build de producción exitoso
• Sin conflictos con otras ramas
• Desplegable en entorno de staging (Sprint 6+)

• Criterios de aceptación 100% cumplidos
• QA Lead ha validado funcionalidad
• Product Owner satisfecho (si revisó)
• Documentado en Sprint Review

Solo cuando se cumplen los 6 criterios, la tarea se mueve a columna "Done" en GitHub Projects.

URL: https://github.com/users/Agsergio04/projects/1

Configuración:

• Columnas: Backlog, To Do, In Progress, In Review, Done
• Campos personalizados:
  • Sprint (S1, S2, S3, S4, S5, S6)
  • Prioridad (Crítica, Alta, Media, Baja)
  • Estimación (horas)
  • Categoría (Backend, Frontend, DevOps, Database, Documentation, Testing)
  • Estado (sincronizado con columnas)
  • Assignee (@Agsergio04, @pablitoclavito04)

Responsabilidad:

• Scrum Master actualiza diariamente antes de 10:00 AM
• Development Team actualiza según progreso en tareas asignadas

Uso:

• Bugs encontrados por QA Lead
• Daily Standups (Issue por sprint)
• Impediments identificados
• Feature requests del Product Owner

Etiquetas (Labels):

• bug - Error funcional
• enhancement - Nueva funcionalidad
• documentation - Mejora de docs
• help wanted - Necesita ayuda externa
• impediment - Bloqueador del equipo
• sprint-X - Pertenece al Sprint X

Canales:

• #general - Comunicación casual
• #standup - Daily standups async
• #tech - Discusiones técnicas
• #resources - Links útiles, docs
• #announcements - Anuncios importantes

Tracking de Story Points completados por sprint:

Story Points
40 │                    ╭─── S6 (est.)
   │               ╭────┤
38 │          ╭────┤    │
   │     ╭────┤    └─── S3 (en progreso)
36 │─────┤    └──────── S5 (proy.)
   │     └──────────── S2
34 │
   │─────────────────── S4 (proy.)
32 │───── S1
   │
30 └─────────────────────────────
   S1   S2   S3   S4   S5   S6

Velocidad promedio: 34-36 SP/sprint

Tracking de trabajo restante durante el sprint:

Horas Restantes
40 │╲
   │ ╲
30 │  ╲     Ideal
   │   ╲___
20 │       ╲___
   │           ╲___  Real
10 │               ╲___
   │                   ╲___
 0 └─────────────────────────╲
   D1  D2  D3  D4  D5  D6  D7

Calculado por: Scrum Master al final de cada día

Estado de tareas a lo largo del sprint:

Nº Tareas
30 │                    ┌─────── Done
   │               ┌────┤
25 │          ┌────┤    └─────── In Review
   │     ┌────┤    └──────────── In Progress
20 │─────┤    └─────────────────
   │     └────────────────────── To Do
15 │
   │
10 └───────────────────────────
   D1  D2  D3  D4  D5  D6  D7

A medida que avanzamos en sprints, hemos adaptado SCRUM a nuestras necesidades:

Sprint 1 → Sprint 2:

• ✅ Daily standups de sync a async (más eficiente para equipo pequeño)
• ✅ Code reviews en <24h (antes era <48h)
• ✅ Añadido buffer de tiempo 10-15% por sprint

Sprint 2 → Sprint 3:

• ✅ Implementado TDD para funciones críticas
• ✅ Swagger docs para API (mejor colaboración)
• ✅ Pre-commit hooks para ESLint

Sprint 3 → Sprint 4 (planificado):

• Implementar CI/CD con GitHub Actions
• Automatizar deployment a staging
• Añadir tests E2E con Cypress

La implementación de SCRUM en PrepáraT nos ha permitido:

✅ Entregas incrementales cada semana
✅ Alta visibilidad del progreso del proyecto
✅ Adaptación rápida a cambios y problemas
✅ Mejora continua mediante retrospectivas
✅ Trabajo en equipo efectivo con roles claros
✅ Calidad alta gracias a Definition of Done estricto

Resultado: Proyecto en tiempo, alta calidad, equipo motivado y aprendiendo continuamente.

Última actualización: 11 de diciembre de 2024
Responsable: @Agsergio04 (Scrum Master Sprint 3)

El proyecto PreguntaT se ha desarrollado siguiendo la metodología SCRUM, un marco de trabajo ágil que permite entregar valor de forma iterativa e incremental mediante sprints de duración fija.

SCRUM es un marco de trabajo ágil para gestión de proyectos que se basa en:

• ✅ Iteraciones cortas (sprints de 1-4 semanas)
• ✅ Equipos autoorganizados y multifuncionales
• ✅ Entrega incremental de valor
• ✅ Mejora continua mediante retrospectivas
• ✅ Transparencia, inspección y adaptación

Representado por: Profesor/Tutor del proyecto

Responsabilidades:

• ✅ Define la visión del producto
• ✅ Prioriza el Product Backlog
• ✅ Valida que los entregables cumplen requisitos
• ✅ Toma decisiones sobre scope y funcionalidades
• ✅ Acepta o rechaza el trabajo completado

Disponibilidad: Reuniones semanales + email

Asignación: Rota cada sprint entre @Agsergio04 y @pablitoclavito04

Responsabilidades:

• ✅ Facilitar ceremonias SCRUM (Planning, Daily, Review, Retro)
• ✅ Actualizar GitHub Projects DIARIAMENTE (antes de 10:00 AM)
• ✅ Remover impedimentos del equipo
• ✅ Gestionar riesgos temporales con buffer de tiempo
• ✅ Calcular velocidad del sprint al finalizar
• ✅ Mantener documentación actualizada (/docs/recursos.md)
• ✅ Asegurar que el equipo sigue la metodología

Rotación por sprint:

• Sprint 1: @Agsergio04
• Sprint 2: @pablitoclavito04
• Sprint 3: @Agsergio04
• Sprint 4: @pablitoclavito04
• Sprint 5: @Agsergio04
• Sprint 6: @pablitoclavito04

Miembros: @Agsergio04 y @pablitoclavito04

Además del Scrum Master, implementamos 3 roles técnicos rotativos:

• Revisar código (Code Reviews)
• Tomar decisiones arquitectónicas
• Asegurar calidad técnica y estándares
• Resolver dudas técnicas del equipo

• Planificar estrategia de testing
• Ejecutar pruebas manuales end-to-end
• Documentar bugs en GitHub Issues
• Validar criterios de aceptación

• Gestionar deployments (staging/producción)
• Mantener CI/CD pipelines (GitHub Actions)
• Monitorizar infraestructura (Docker, MongoDB)
• Gestionar backups y variables de entorno

Ver rotación completa: [Roles del Equipo](./Roles-del-Equipo)

Cuándo: Primer día de cada sprint - Lunes 10:00 AM CET
Duración: 1 hora
Participantes: Todo el equipo + Product Owner (opcional)

Objetivos:

1. Revisar y priorizar Product Backlog
2. Seleccionar tareas para el Sprint Backlog
3. Definir Sprint Goal (objetivo del sprint)
4. Estimar tareas en Story Points
5. Asignar responsables (Assignees)
6. Identificar dependencias y riesgos

Salida:

• ✅ Sprint Backlog completo en GitHub Projects
• ✅ Sprint Goal documentado
• ✅ Tareas estimadas y asignadas
• ✅ Riesgos identificados con mitigaciones

Ejemplo Sprint 3:

Sprint Goal: "Integrar OpenAI/Gemini para generación y evaluación de preguntas con IA"

Tareas seleccionadas:
- Instalar SDK OpenAI (0.5h) - @Agsergio04
- Crear OpenAIService (1h) - @Agsergio04
- Endpoint análisis respuestas (2h) - @Agsergio04
- Componente LiveInterviewPage (2h) - @pablitoclavito04
- MediaRecorder API (1.5h) - @pablitoclavito04
...

Story Points: 42 SP
Riesgos: Web Speech API compatibilidad, costos OpenAI

Cuándo: Lunes a Viernes 9:00 AM CET
Duración: 15 minutos (máximo)
Formato: Asíncrono en GitHub Issues

Cada miembro responde:

1. ¿Qué hice ayer?
2. ¿Qué haré hoy?
3. ¿Tengo algún impedimento?

Implementación en GitHub: Cada dev comenta en el Issue "Daily Standup Sprint X" con el formato:

## @Agsergio04 - 14/11/2024

**Ayer:**
- ✅ Implementé OpenAIService con retry logic
- ✅ Creé endpoint POST /api/ai/analyze-response
- ⚠️ Bug en rate limiting (Issue #45 creado)

**Hoy:**
- [ ] Resolver bug de rate limiting
- [ ] Implementar sistema de caché de respuestas
- [ ] Comenzar endpoint generate-followup

**Impedimentos:**
- Ninguno (rate limiting es menor, se resolverá hoy)

Responsabilidad del Scrum Master:

• Leer todos los dailies antes de 10:00 AM
• Identificar impedimentos y trabajar en removerlos
• Actualizar GitHub Projects según progreso reportado

Cuándo: Último día del sprint - Viernes 4:00 PM CET
Duración: 1 hora
Participantes: Todo el equipo + Product Owner

Objetivos:

1. Demostrar funcionalidades completadas (Demo en vivo)
2. Revisar qué se completó vs. qué quedó pendiente
3. Actualizar Product Backlog según feedback
4. Validar que se cumplió el Sprint Goal

Estructura de la Review:

1. Intro (5 min): Scrum Master presenta objetivo del sprint
2. Demo (40 min): Development Team muestra funcionalidades
3. Q&A (10 min): Product Owner hace preguntas y da feedback
4. Cierre (5 min): Decisiones sobre próximo sprint

Ejemplo Sprint 2:

✅ Completado:
- CRUD de entrevistas (GET, POST, PUT, DELETE)
- Sistema de estados (DRAFT → SCHEDULED → IN_PROGRESS → COMPLETED)
- Página CreateInterviewPage con flujo multi-paso
- 5 componentes React reutilizables
- Tests unitarios >80% cobertura

⚠️ Pendiente para Sprint 3:
- Bug #23: Validación de fecha en DateTimePicker
- Mejora: Swagger documentation para API

📊 Métricas:
- 36/38 Story Points completados (95%)
- 11 Pull Requests merged
- 0 bugs críticos en producción

Cuándo: Último día del sprint - Viernes 5:00 PM CET
Duración: 30 minutos
Participantes: Development Team (SIN Product Owner)

Objetivos:

• Reflexionar sobre el sprint desde perspectiva de proceso (no producto)
• Identificar qué funcionó bien y qué mejorar
• Definir acciones concretas de mejora para próximo sprint

Formato - Start, Stop, Continue:

Acciones de Mejora Sprint 3:

1. ✅ Crear colección Postman para API endpoints
2. ✅ Implementar pre-commit hook para ESLint
3. ✅ Daily standups máximo 10 minutos

Seguimiento:

• Acciones se convierten en tareas del Sprint Backlog del próximo sprint
• Se revisan en la siguiente Retrospective para validar implementación

Definición: Lista priorizada de todas las funcionalidades, mejoras y bugs del producto.

Ubicación: GitHub Projects - Columna "Backlog"
Responsable: Product Owner (con input del equipo)

Formato de Items:

**Título:** Como [rol], quiero [funcionalidad] para [beneficio]

**Descripción:**
- Criterios de aceptación claros
- Estimación en Story Points
- Prioridad (Crítica, Alta, Media, Baja)
- Categoría (Backend, Frontend, DevOps, etc.)

**Ejemplo:**
Título: Como usuario, quiero recibir feedback detallado después de cada respuesta para mejorar mi rendimiento

Criterios de aceptación:
- [ ] Feedback aparece inmediatamente después de responder
- [ ] Incluye puntuación numérica (0-100)
- [ ] Muestra fortalezas y áreas de mejora
- [ ] Feedback es personalizado (no genérico)

Estimación: 5 SP
Prioridad: Alta
Categoría: Backend + Frontend

Definición: Subconjunto del Product Backlog seleccionado para el sprint actual.

Ubicación: GitHub Projects - Columnas "To Do", "In Progress", "In Review"
Responsable: Development Team

Características:

• ✅ Tareas seleccionadas en Sprint Planning
• ✅ Estimadas y asignadas a desarrolladores
• ✅ Incluye tareas técnicas (no solo features)
• ✅ Se actualiza diariamente según progreso

Estados de una tarea:

1. To Do: Pendiente de comenzar
2. In Progress: En desarrollo activo
3. In Review: Pull Request creado, esperando code review
4. Done: Merged a main, cumple Definition of Done

Definición: Suma de todos los items del Product Backlog completados en el sprint + incrementos de sprints anteriores.

Requisito: Debe ser potencialmente desplegable (cumple Definition of Done).

En PrepáraT:

• Al final de cada sprint, el increment incluye:
  • Código funcional y testeado
  • Documentación actualizada
  • Desplegable en entorno de staging

Ejemplo Sprint 2:

Increment Sprint 2:
- CRUD completo de entrevistas funcional
- Sistema de estados validado
- 5 componentes React nuevos
- Tests con 82% cobertura
- API documentada en API.md

Estado: ✅ Desplegable en staging

Una tarea/historia se considera "Done" cuando cumple TODOS estos criterios:

• Funcionalidad implementada completamente según criterios de aceptación
• Código sigue convenciones del proyecto (ESLint + Prettier)
• Sin warnings ni errors en consola (navegador o terminal)
• Sin código comentado o debug statements (console.log)

• Tests unitarios escritos y pasando (si aplica)
• Cobertura de tests >80% para funciones críticas
• Testing manual ejecutado por QA Lead
• Sin bugs críticos conocidos

• Pull Request creado en GitHub
• Al menos 1 aprobación del Tech Lead
• Todos los comentarios del review resueltos
• CI/CD pipeline pasando (cuando esté configurado)

• JSDoc completo para nuevas funciones/componentes
• README.md actualizado si hay cambios de setup
• Comentarios en código para lógica compleja
• API.md actualizado si hay nuevos endpoints

• Código merged a rama main
• Build de producción exitoso
• Sin conflictos con otras ramas
• Desplegable en entorno de staging (Sprint 6+)

• Criterios de aceptación 100% cumplidos
• QA Lead ha validado funcionalidad
• Product Owner satisfecho (si revisó)
• Documentado en Sprint Review

Solo cuando se cumplen los 6 criterios, la tarea se mueve a columna "Done" en GitHub Projects.

URL: https://github.com/users/Agsergio04/projects/1

Configuración:

• Columnas: Backlog, To Do, In Progress, In Review, Done
• Campos personalizados:
  • Sprint (S1, S2, S3, S4, S5, S6)
  • Prioridad (Crítica, Alta, Media, Baja)
  • Estimación (horas)
  • Categoría (Backend, Frontend, DevOps, Database, Documentation, Testing)
  • Estado (sincronizado con columnas)
  • Assignee (@Agsergio04, @pablitoclavito04)

Responsabilidad:

• Scrum Master actualiza diariamente antes de 10:00 AM
• Development Team actualiza según progreso en tareas asignadas

Uso:

• Bugs encontrados por QA Lead
• Daily Standups (Issue por sprint)
• Impediments identificados
• Feature requests del Product Owner

Etiquetas (Labels):

• bug - Error funcional
• enhancement - Nueva funcionalidad
• documentation - Mejora de docs
• help wanted - Necesita ayuda externa
• impediment - Bloqueador del equipo
• sprint-X - Pertenece al Sprint X

Canales:

• #general - Comunicación casual
• #standup - Daily standups async
• #tech - Discusiones técnicas
• #resources - Links útiles, docs
• #announcements - Anuncios importantes

Tracking de Story Points completados por sprint:

Story Points
40 │                    ╭─── S6 (est.)
   │               ╭────┤
38 │          ╭────┤    │
   │     ╭────┤    └─── S3 (en progreso)
36 │─────┤    └──────── S5 (proy.)
   │     └──────────── S2
34 │
   │─────────────────── S4 (proy.)
32 │───── S1
   │
30 └─────────────────────────────
   S1   S2   S3   S4   S5   S6

Velocidad promedio: 34-36 SP/sprint

Tracking de trabajo restante durante el sprint:

Horas Restantes
40 │╲
   │ ╲
30 │  ╲     Ideal
   │   ╲___
20 │       ╲___
   │           ╲___  Real
10 │               ╲___
   │                   ╲___
 0 └─────────────────────────╲
   D1  D2  D3  D4  D5  D6  D7

Calculado por: Scrum Master al final de cada día

Estado de tareas a lo largo del sprint:

Nº Tareas
30 │                    ┌─────── Done
   │               ┌────┤
25 │          ┌────┤    └─────── In Review
   │     ┌────┤    └──────────── In Progress
20 │─────┤    └─────────────────
   │     └────────────────────── To Do
15 │
   │
10 └───────────────────────────
   D1  D2  D3  D4  D5  D6  D7

A medida que avanzamos en sprints, hemos adaptado SCRUM a nuestras necesidades:

Sprint 1 → Sprint 2:

• ✅ Daily standups de sync a async (más eficiente para equipo pequeño)
• ✅ Code reviews en <24h (antes era <48h)
• ✅ Añadido buffer de tiempo 10-15% por sprint

Sprint 2 → Sprint 3:

• ✅ Implementado TDD para funciones críticas
• ✅ Swagger docs para API (mejor colaboración)
• ✅ Pre-commit hooks para ESLint

Sprint 3 → Sprint 4 (planificado):

• Implementar CI/CD con GitHub Actions
• Automatizar deployment a staging
• Añadir tests E2E con Cypress

La implementación de SCRUM en PrepáraT nos ha permitido:

✅ Entregas incrementales cada semana
✅ Alta visibilidad del progreso del proyecto
✅ Adaptación rápida a cambios y problemas
✅ Mejora continua mediante retrospectivas
✅ Trabajo en equipo efectivo con roles claros
✅ Calidad alta gracias a Definition of Done estricto

Resultado: Proyecto en tiempo, alta calidad, equipo motivado y aprendiendo continuamente.

Última actualización: 11 de diciembre de 2024
Responsable: @Agsergio04 (Scrum Master Sprint 3)