Principiante
Unas 12 horasProyecto 1 de 4Plan de proyecto ágil para una app real
Una asociación de vecinos quiere una aplicación para reservar las pistas deportivas del barrio. Antes de programar nada, tu equipo debe decidir cómo se va a trabajar: elegir y justificar la metodología, convertir lo que pide el cliente en historias de usuario estimadas, planificar los primeros sprints y preparar la documentación inicial.
MarkdownGitHub Projects o TrelloPlantUML
Tu avance0/18 · 0 %
Objetivos de aprendizaje
- •Elegir un modelo de ciclo de vida razonando ventajas e inconvenientes
- •Redactar requisitos funcionales y no funcionales y convertirlos en historias de usuario
- •Estimar con puntos de historia y planificar sprints con una velocidad realista
- •Documentar las decisiones de un proyecto de forma profesional
Requisitos mínimos
Fases sugeridas
- 1
Entrevista y requisitos
- 2
Metodología
- 3
Backlog y estimación
- 4
Planificación y tablero
Qué entregar
- Documento del plan (PDF o Markdown) con requisitos, metodología, backlog y planificación
- Enlace al tablero del proyecto
- Diagrama de casos de uso (.puml y su imagen)
Para ir más allá
- Calcula el camino crítico de las tareas del primer sprint
- Haz un prototipo en papel de las 3 pantallas principales
- Prepara la sprint review del primer sprint como si lo hubieras terminado
Rúbrica de evaluación
| Criterio | Peso | Para la máxima nota |
|---|---|---|
| Requisitos | 25 % | Completos, sin ambigüedades, bien clasificados y con al menos 3 no funcionales medibles |
| Elección de metodología | 20 % | Justificada con argumentos del caso concreto, no genéricos |
| Historias y criterios de aceptación | 25 % | Historias con valor para el usuario, independientes y comprobables; criterios que se podrían automatizar |
| Planificación | 20 % | Sprints con objetivo claro, carga coherente con la velocidad estimada y riesgos identificados |
| Presentación | 10 % | Documento estructurado, sin faltas y fácil de seguir |
Úsala para autoevaluarte antes de entregar. Tu profesorado puede usar otros criterios.
Consejos y errores típicos
- Una historia técnica («crear la tabla usuarios») no es una historia de usuario: es una tarea dentro de una.
- Los requisitos no funcionales deben poder medirse: «rápida» no sirve, «responde en menos de 2 s» sí.
- No estimes en horas: los puntos comparan esfuerzo entre historias.