Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GearSolid GearSolid
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3
    • Issues 3
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GuerreroDIM46
  • GearSolidGearSolid
  • Wiki
    • Documentacion
  • Sprint Review 1

Last edited by Rodrigo de Dios García May 08, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Sprint Review 1

Información

  • Descripción: Primer Sprint del proyecto de desarrollo de la aplicación Gearsolid
  • Duración: 28 días (del 8 abril al 5 mayo de 2024)
  • Tiempo invertido: 26,5 horas (0,9h/día) (previsto)

Diagrama Burndown

Sprint1 burndown

Sprint review

Objetivo de producto

Nuestro objetivo es desarrollar una aplicación web para la Fundación Coordinadora Solidaria, que facilite a las trabajadoras sociales la gestión de los usuarios. Esta aplicación deberá permitir la asignación flexible de los recursos limitados disponibles para la formación de los usuarios, la priorización de estos basada en sus ingresos y la cantidad de menores a su cargo, el manejo de nuevos usuarios, la distribución del acceso según franjas horarias y semanalmente, y la automatización de tareas básicas, como la impresión de listados de control.

Sprint Goal

Permitir establecer una relación entre usuarios e compromisos así como visualizarlos. Consideraremos el objetivo alcanzado cuando las trabajadoras sociales puedan seleccionar usuarios y ver, modificar o asignar los compromisos que tienen asociadas a ellos, ordenarlos por franjas, e imprimir el mensual de esa franja.

Incremento por impactos

  • Localizar compromisos disponibles
    • CRUD Compromisos
  • Disminuir el tiempo usado en generar listados:
    • Listado automático de control de recogida de alimentos

Valor del siguiente incremento46

|||Configuración básica de VUE (Componente principal + navbar) | 2h| |||Crear almacén de usuarios en JSON |1 h | |||Crear componente Usuario en Vue | 0,5 h | |||Crear componente Lista de Usuarios en Vue| 1h | |||Alojar Web en Netlify| 1 h | | PBI-02 | Asignar compromisos a usuario||| |||Generar Testde GET, POST PUT y DELETE en POSTMAN |1 h| |||Inicialización básica de Spring |1 h| |||Generar Entidad y repositorio para compromisos|1h| |||Crear formulario Vue para asignar compromisos (el formulario muestra el total de compromisos para una franja horaria y el total de los que se han cargado ya en dicha franja)|2 h| |||Carga de datos desde VUE hacia API|2 h| | PBI-03 | Ver compromisos por usuario||| |||Generar componente compromiso| 1h| |||Generar un nuevo compoenente VUE con el listado de compromisos para un usuario| 1h |46 |||Modificar componente de Usuario para que se muestren sus compromisos(nuevo componente listado de compromisos) | 0,5 h| | PBI-04 | Modificar compromisos de usuario ||| |||Incluir un botón de modificar compromiso en componente Compromiso en VUE|0,5h| |||Lanzar PUT hacia API desde VUE con datos de formulario anterior (Se realiza PUT no PATCH)|1h | | PBI-05 | Borrar compromisos de usuario||| |||Botón de eliminar compromiso en componente Compromiso en VUE|0,5h| |||Lanzar Delete desde front|1h| | PBI-06 | Mostrar filtro por franjas de compromiso de alimentación ||| |||Test JUnit para GET con filtro búsqueda por grupo| 1h| |||Controlador Get para busqueda con filtro de grupo (A lunes, miercoles, jueves... B: martes...), incluye método personalizado |4 h| |||Componente Listado General Compromisos |1h| |||Select de grupos (A,B,C) en el componente Lista General de componentes |1 h| | PBI-07 | Imprimir listado mensual de compromisos por franja ||| |||Botón en Vue para imprimir en listado general de componentes| 2 h|

Demostración

La aplicación se encuentra desplegada Netlify y es accesible desde Internet a través del siguiente enlace https://gearsolid.netlify.app

Rendimientos por página en modo escritorio

Rendimiento Home

Rendimiento Home

Rendimiento Lista de Usuarios

Rendimiento Lista Usuarios

Rendimiento Recogidas Alimento

Rendimiento Recogidas Alimento

Restrospectiva

Impedimentos

Individuos

El desarrollador no había comprendido el objetivo del cliente al fijarse más en el impact map que en la pila de producto por lo que inicialmente se orientó de manera incorrecta el sprint. El desconocimiento técnico del desarrollador provocó que no se especofocasen adecuadamente las tareas de la pila de Sprint Ha sido necesario añadir items a la pila de Sprint ya que no se contó con:

  • Despliegue de al API
  • Especificación del elemento franja imprescindible a partir del elemento #21 (closed) Se ha incluido un item #27 (closed) "Generar método personalizado para filtrar compromisos por nombre de usuario" no incluido en el planning que no aporta valor y ha supuesto deuda técnica. El desarrollador no calculó adecuadamente los tiempos de cada tarea lo que derivó en una carga de trabajado de más del doble de lo previsto.
Interacciones

El desarrollador no ha hecho accesible la aplicación en internet por lo que ni propietario de producto ni partes interesadas han podido seguir el incremento de cada elemento de la pila Sprint.

Herramientas

No se han tenido en cuenta el despliegue de la API en las tareas. Mal uso de repositorios o herramientas CI/CD, varias versiones de lo mismo.

Definición de hecho

  • El código sigue la guía de estilo de google.
  • El código esté límpio (sin código muerto ni de depuración).
  • El código haya sido revisado por un desarrollador distinto al que lo generó. No cumple ya que sólo hay un desarrollador en el equipo.
  • Se haya comprobado el correcto funcionamiento de la aplicación en los tres principales navegadores(Firefox, Chrome y Edge).
  • Al usuario se le sugiere el contenido de los campos a rellenar
  • La aplicación debe ser compatible con varios sistemas operativos, incluyendo Windows, macOS, Linux.
Clone repository

GearSolid


Fase de concepto (Presentación)

1. Estudio de Viabilidad del Sistema (EVS)

  • Análisis del problema
  • Mind Map
  • Impact Map
  • Requisitos
  • Alternativas
  • Matriz de Cumplimiento de Funcionalidades
  • Matriz de decisión

2. Especificación de Requisitos de Software (ERS)

  • Planificación General
  • Diagrama de Clases y Modelo de Datos
  • Interfaz de Usuario

3. Producto Mínimo Viable (MVP)

  • Definición del MVP

4. Desarrollo

  • Historias de usuario

  • Product Backlog

  • Definicion del Hecho

    4.1.  Sprint 1
    - Sprint Backlog
    - Sprint Planning
    - Sprint Review
    - Sprint Retrospective

    4.2.  Sprint 2
    - Sprint Backlog
    - Sprint Planning
    - Sprint Review
    - Sprint Retrospective

  • Anexo I

  • Anexo II