Retrospectiva – Sprint 1

Fecha: 08/11/2025
Equipo: Carlos Portillo, Santiago Fuentes, Santiago Lasso, Nicolas Paez
Objetivo del sprint: Entregar funcionalidades planificadas del Sprint 1 con alta calidad y sin bloqueos

---

1) Agenda

1. Qué fue bien / Qué no (15 min) – Hallazgos clave
2. Profundizar (25 min) – Temas priorizados por votos
3. Acciones (Start/Stop/Continue) (15 min) – Compromisos SMART
4. Aprendizajes y próximos riesgos (10 min) – Reflexiones para el siguiente sprint
5. Plan de seguimiento (5 min) – Revisar avances de acciones previas

---

1) Qué fue bien / Qué no (15 min)

👍 Qué fue bien

• Comunicación fluida y oportuna entre los miembros del equipo.
• Actividades realizadas con tiempo, sin apuros de última hora.
• No hubo conflictos ni bloqueos en el código (ramas limpias, merges sin fricción).
• Se presentó todo lo planificado e incluso entregables adicionales.

👎 Por mejorar

• Profundizar el conocimiento compartido de la base de código.
• Mantener la calidad del trabajo a medida que aumente el alcance.
• Sostener el buen timing de entrega en sprints más exigentes.
• Mejorar el uso del tablero de trabajo (estado actualizado, granularidad de tareas).

---

2) Profundizar (25 min)

1. Propuesta de temas (5 min): cada persona sugiere 1–2 tarjetas/ítems.
2. Votación (2 min): 3 votos por persona.
3. Discusión (15–18 min): 6–8 min por tema (⏱️ extender solo si hay “dos pulgares arriba”).
4. Notas rápidas: decisiones, riesgos, dueños.

Tema	Votos	Decisiones / Notas	Dueño
Conocimiento de la base de código	4	Hacer “code tours” cortos y rotativos.	Rotativo semanal
Uso del tablero	4	Actualizar estados a diario; tasks ≤ 1 día.	Todos
Calidad y timing de entrega	3	Checklist de PR (tests, lint, cobertura mínima).	Todos

---

3) Acciones – Start / Stop / Continue (15 min)

✅ Acciones priorizadas (próximo sprint)

Tipo	Acción (SMART)	Dueño	Criterio de éxito
Start	Programar 2 code tours de 20 min/semana para explicar áreas del repo.	Rotativo (uno por dev)	Al final del sprint cada dev haber guiado al menos 1 tour.
Start	Política del tablero: actualizar cards a diario; crear subtareas de ≤1 día; mover a Done solo con PR mergeado.	Todos	100% de tareas con estado actualizado; WIP ≤ 2 por persona.
Continue	Comunicación proactiva (daily breve + canal de bloqueos).	Todos	Tiempo de resolución de bloqueos ≤ 24 h y cero sorpresas en la demo.
Continue	Entregas anticipadas con margen para feedback.	Todos	Features clave listas ≥48 h antes de la demo.

---

4) Aprendizajes clave y próximos riesgos

🧠 Aprendizajes

• La comunicación constante habilita entregas anticipadas y sin conflictos de integración.
• Planificar con granularidad (tareas ≤1 día) reduce incertidumbre y facilita seguimiento.

⚠️ Riesgos a considerar

• Deuda de tablero si no se actualiza a diario, generando desalineación.
• Efecto expansión: agregar alcance extra puede erosionar el timing si no hay buffers.

---

5) Plan de seguimiento de acciones

• Semanal: revisar cumplimiento de code tours.
• Diario: tableros al día; WIP controlado por persona.
• PR Review: verificar checklist y cobertura mínima antes de aprobar.
• Inicio del siguiente sprint: evaluar métricas (nº de tours, % PR con checklist, WIP/persona, cobertura) y ajustar acciones.