Metodología de proyecto y documentación técnica
Este dominio evalúa cómo se organiza un proyecto web y cómo se documenta para que otro equipo pueda entenderlo, operarlo y mantenerlo. Se pregunta por requisitos, historias de usuario, criterios de aceptación, planificación, README, documentación de API, control de cambios y revisión de código.
Requisitos y planificación
- Un requisito funcional describe qué debe hacer el sistema; uno no funcional describe rendimiento, seguridad, accesibilidad o disponibilidad.
- Una historia de usuario tiene la forma: como rol, quiero una acción, para obtener un beneficio. Debe incluir criterios de aceptación verificables.
- El backlog prioriza historias; un sprint selecciona un subconjunto y produce un incremento. En enfoques predictivos o en cascada se planifica por fases y los cambios son más costosos.
- Wireframes y prototipos validan estructura y flujo antes de invertir en código.
Documentación útil
- El README explica qué hace el proyecto, requisitos, instalación, variables de entorno, comandos de prueba y despliegue.
- La API se documenta con OpenAPI o similar: rutas, parámetros, cuerpos, códigos y autenticación.
- Un CHANGELOG registra versiones y cambios relevantes; los ADR registran decisiones de arquitectura y sus motivos.
- Los comentarios explican el porqué, no repiten lo que el código ya dice. Nombres claros reducen la necesidad de comentarios.
- La revisión de código busca defectos, seguridad, legibilidad y pruebas, no preferencias personales.
Ejemplo trabajado
Historia: “Como estudiante quiero restablecer mi contraseña para recuperar el acceso”. Criterios: el enlace caduca en 30 minutos; se envía solo si el correo existe; la respuesta es siempre la misma; la nueva contraseña cumple longitud mínima; se registra el evento. De ahí salen tareas: endpoint, plantilla de correo, token de un solo uso, pruebas y documentación. Razonamiento: sin criterios verificables no se puede aceptar la historia ni estimar bien; los criterios también definen casos de prueba y documentación de API.
Errores que cuestan puntos
Documentar al final y no durante el proyecto; aceptar historias sin criterios; escribir comentarios que repiten el código; no versionar la documentación; saltarse la revisión; mezclar requisitos funcionales con soluciones técnicas; no registrar decisiones ni cambios de alcance.