Sprint Review - G10-ISPC/Frontend-Mobile GitHub Wiki
Sprint 0 Review
-Objetivos del Sprint 0
Definir el alcance del proyecto Establecer los objetivos y entregables Preparar el entorno de trabajo Identificar y asignar roles y responsabilidades
-Logros del Sprint 0
Se ha definido el alcance del proyecto y se han establecido los objetivos claros Se han identificado y asignado los roles y responsabilidades del equipo Se ha configurado el entorno de trabajo y se han establecido las herramientas necesarias Se ha creado un plan de trabajo preliminar para el siguiente sprint
-Pruebas y validaciones
Se han validado los objetivos y alcance del proyecto con los stakeholders Se han probado las herramientas y entorno de trabajo
-Retos y desafíos
Se han identificado algunos desafíos en la asignación de roles y responsabilidades Se han detectado algunas necesidades de capacitación en herramientas específicas
-Acciones para el siguiente sprint
Iniciar el desarrollo de las historias de usuario prioritarias Continuar con la capacitación y soporte para el equipo Refinar el plan de trabajo y establecer metas claras para el siguiente sprint
Sprint 1 Review
-Objetivos del Sprint 1:
Cumplir con las tareas de desarrollo y actualización en backend, frontend y ciberseguridad para la aplicación móvil. Incluir la planificación de pruebas y la correcta gestión del proyecto.
-Logros del Sprint 1:
Se ha definido el método de autenticación con JWT, fundamentando su elección. Se ha continuado con la estructura de ramas propuesta: main, develop y release. Se ha documentado el progreso en el repositorio de GitHub y se han entregado los avances en ciberseguridad.
-Pruebas y Validaciones:
Se ha validado la columna Testing QA, que debe estar previa a Done para seguir la secuencia lógica de los pasos. Se han documentado y ejecutado casos de prueba (Test Cases), aunque algunos requerían mayor precisión en la redacción: Ejemplo: TC001 debe indicar que el usuario tiene una cuenta y suscripción activa, y ha iniciado sesión en la aplicación. Se ha observado que la columna PASS/FAIL se completó con NOT RUN debido a que la aplicación aún no tiene funcionalidad. Se requiere que la evidencia haga referencia a capturas de pantalla y se propone un único video por celda para la visualización de resultados. Las etiquetas deben hacer referencia a los tipos de prueba aplicados (por ejemplo, #Funcionales, #Login, #Exploratoria, #Usabilidad, etc.).
-Retos y Desafíos:
Se han identificado desafíos en la precisión y el acceso a la planilla de Test Cases, que inicialmente no tenía permisos de acceso. No se cuenta con evidencia de test cases de Delfina Aricoma por inconvenientes de conexión y Felix Figueroa, este último dejo la cursada.
-Acciones para el siguiente Sprint:
Mejorar la redacción de los Test Cases, asegurando que contengan precondiciones claras. Revisar y ajustar la planificación de pruebas, estableciendo claramente quién ejecuta y quién diseña cada prueba. Actualizar el documento IEEE830 según las sugerencias, agregando descripciones breves a los requerimientos funcionales. Disponer la columna Testing en el Kanban, antes de Done.
Sprint 2 Review
-Objetivos del Sprint 2
Consolidar la funcionalidad completa de la aplicación móvil, incluyendo el desarrollo de operaciones CRUD, la validación de pruebas de accesibilidad, y mejoras en ciberseguridad y gestión del proyecto.
-Logros del Sprint 2
Desarrollo y Funcionalidades: Se implementaron y completaron las operaciones CRUD en los módulos de Productos y Usuarios, asegurando su conexión con la base de datos remota mediante API REST. La aplicación fue exportada en formato .apk y subida al repositorio de GitHub como respaldo.
Accesibilidad y Pruebas de Software: Se evaluó y documentó la accesibilidad, registrando resultados en la planilla “Automatización de Accesibilidad”. Además, se documentaron las pruebas realizadas en “Test Case”, “Test Ciberseguridad” y “Registro de Errores” en la Wiki, con capturas y logs.
Ciberseguridad: Se mejoraron las políticas de seguridad y se implementaron roles y permisos a través de JWT, documentando en video la elección de esta estrategia. Gestión del Proyecto: El documento IEEE830 fue actualizado con descripciones técnicas, y se ajustaron milestones, issues y el Kanban.
-Pruebas y Validaciones
Las observaciones del equipo se atendieron incorporando un switch de stock para los productos, evitando la pérdida de historial. Además, se actualizaron los casos de prueba para reflejar estas modificaciones y errores detectados, incluyendo un registro detallado en la Wiki.
-Retos y Desafíos
El equipo se enfrentó a desafíos en la implementación de nuevas funcionalidades, como el switch de stock, y la adecuada documentación de las pruebas en distintos documentos.