-
Notifications
You must be signed in to change notification settings - Fork 0
🎯Definición of Done
📌 Este documento evoluciona sprint a sprint para reflejar los criterios de calidad acordados por el equipo.
Una Historia de Usuario o funcionalidad se considera "Hecha" cuando cumple con los siguientes criterios:
🔲 El código ha sido escrito, versionado y fusionado en la rama main o equivalente del repositorio.
🔲 Se cumplen todos los criterios de aceptación definidos en la Historia de Usuario.
🔲 El código cumple con las normas de estilo acordadas por el equipo (convenciones de nombres, etc.).
🔲 No se introdujeron errores nuevos en funcionalidades existentes.
🔲 Las funcionalidades fueron probadas manualmente en el entorno local.
🔲 El testeo fue validado por al menos un integrante diferente al autor del código (principio de revisión cruzada).
🔲 La interfaz fue implementada respetando el diseño aprobado por el equipo.
🔲 Es totalmente funcional en dispositivos móviles y navegadores estándar.
🔲 Los textos y etiquetas en la UI están revisados y sin errores ortográficos.
🔲 La Historia de Usuario está actualizada y marcada como Completada.
🔲 Se actualizó la documentación técnica y funcional en caso de cambios relevantes.
🔲 Se documentó cualquier decisión técnica que afecte al desarrollo futuro (en README o Wiki).
🔲 El acceso a la funcionalidad está correctamente restringido según el rol del usuario (Docente/Admin).
🔲 Se respetan los principios mínimos de seguridad en validación de datos y almacenamiento de credenciales.
🔲 La funcionalidad está desplegada en el entorno de staging o producción.
🔲 El equipo fue notificado sobre la nueva versión disponible.
Una Historia de Usuario o funcionalidad se considera "Hecha" cuando cumple con:
🔲 El código fue versionado en la rama main e integra maquetado estático responsive (HTML + CSS + Bootstrap).
🔲 Se incluye el portafolio individual de cada integrante, con diseño propio.
🔲 El código mantiene consistencia en la estructura de carpetas (maqueta) y sigue convenciones de estilo.
🔲 No se introdujeron errores en páginas ya construidas.
🔲 Se verificó la responsividad de las vistas en dispositivos móviles y navegadores estándar.
🔲 Al menos un integrante distinto validó la funcionalidad (revisión cruzada).
🔲 Las páginas (Home, Registro/Login, Gestión de Contenido, Dashboard, Quiénes Somos, Portafolios) mantienen coherencia visual.
🔲 El diseño es responsive y accesible.
🔲 Textos y etiquetas en la UI revisados sin errores ortográficos.
🔲 Wiki actualizada con: IEEE830 + Historias de Usuario + Criterios de Aceptación + Novedades de Equipo + Ceremonias Scrum.
🔲 Se documentaron los issues y milestones del Sprint 2.
🔲 El acceso básico a formularios de registro/login respeta validaciones mínimas.
🔲 El código está en la carpeta maqueta (rama main) junto con el Readme actualizado.
🔲 El tablero Kanban actualizado refleja el estado de las tareas.
Una Historia de Usuario o funcionalidad se considera "Hecha" cuando cumple con:
🔲 El código fue desarrollado en Angular (SPA estática) y versionado en la rama main.
🔲 Se implementó el sistema de routing (navegación entre páginas).
🔲 Formularios reactivos con validaciones: login, registro, CRUD (alta).
🔲 CRUD inicial implementado (alta de datos) en la sección de Gestión de Contenido.
🔲 Se respetó la modularidad de componentes Angular.
🔲 Se verificó la navegación SPA en navegadores estándar.
🔲 Formularios reactivos validados en ingreso de datos.
🔲 Revisión cruzada por otro integrante del equipo.
🔲 Las páginas cumplen con la estética definida y mantienen diseño responsive.
🔲 Los formularios y la navegación son claros e intuitivos.
🔲 Wiki actualizada con: IEEE830 + Historias de Usuario + Criterios de Aceptación + Novedades de Equipo + Ceremonias Scrum.
🔲 Issues y Milestone del Sprint 3 actualizados en GitHub.
🔲 Readme actualizado, Release v0.1.0-alpha creado según SemVer.
🔲 Sistema de Branching actualizado incluyendo rama release.
🔲 Validaciones implementadas en formularios de login y registro.
🔲 Carpeta frontend (Angular) creada en el repositorio (rama main).
🔲 Release publicado en GitHub con descripción de cambios.
🔲 Tablero Kanban actualizado con el estado real de los issues.
Una Historia de Usuario o funcionalidad se considera “Hecha” cuando cumple con:
🔲 Código en Angular conectado a una API REST (httpClient) → sin datos hardcodeados.
🔲 CRUD implementado con verbos HTTP correctos (GET/POST/PUT/DELETE).
🔲 Diseño de Base de Datos entregado: modelo conceptual, lógico, físico + script SQL.
🔲 Estructura de código clara y modular en frontend (Angular).
🔲 Peticiones API verificadas con datos reales de prueba.
🔲 Revisión cruzada por otro integrante (validación de consumo correcto de datos).
🔲 Páginas mantienen diseño responsive y navegación fluida.
🔲 Formularios validan datos antes de enviarlos a la API.
🔲 Wiki actualizada con: IEEE830, Historias de Usuario, Criterios de Aceptación, Novedades de Equipo, Ceremonias Scrum.
🔲 Issues y Milestone del Sprint 4 actualizados.
🔲 Readme actualizado + Release v0.2.0-alpha creado (SemVer).
🔲 Validaciones mínimas en formularios para prevenir datos inválidos.
🔲 Acceso a funcionalidades controlado por rol (Docente/Admin, si aplica).
🔲 Carpeta frontend (Angular) en la rama main.
🔲 Script SQL de la base de datos incluido.
🔲 Kanban actualizado.
Una Historia de Usuario o funcionalidad se considera “Hecha” cuando cumple con:
🔲 El código utiliza la nueva sintaxis de Angular 20 (@if, @for) y componentes standalone.
🔲 Guards de rutas implementados y probados para todos los roles (Admin, Docente).
🔲 No quedan dependencias de datos hardcodeados ni mocks en producción.
🔲 Se eliminaron archivos, rutas y componentes obsoletos o no utilizados.
🔲 El código fue probado manualmente en los flujos críticos (login, registro, CRUD) y se documentaron los resultados. No se incorporaron pruebas unitarias automáticas en esta versión.
🔲 Validación cruzada por al menos dos integrantes distintos (peer review doble).
🔲 Accesibilidad básica validada.
🔲 Iconografía y estilos revisados para coherencia visual en todo el sistema.
🔲 Responsive comprobado en dispositivos móviles y escritorio.
🔲 Documentación técnica y funcional actualizada (README, Wiki, IEEE830, diagramas de arquitectura).
🔲 Endpoints de la API documentados y probados (Postman).
🔲 Registro de decisiones técnicas relevantes (en Wiki).
🔲 Validaciones de datos robustas en frontend y backend.
🔲 Manejo seguro de credenciales.
🔲 Pruebas de acceso indebido (intentos de saltar guards, manipulación de roles, etc.).
🔲 Release publicado con changelog detallado y versión según SemVer.
🔲 El equipo fue notificado y la demo final fue realizada.
🔲 Todas las historias del sprint están en estado “Done” en el tablero.
🔲 Retrospectiva realizada y lecciones aprendidas documentadas.