Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Demeter Demeter
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 4
    • Issues 4
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • 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
  • ddcDIM47
  • DemeterDemeter
  • Wiki
    • Sprint_1
  • 5.3 Spring Retrospective

Last edited by Manuel de Blas Pino Jun 15, 2025
Page history

5.3 Spring Retrospective

¿Que fue bien?

La creación de los issues a partir de los PBIs ha proporcionado una solución al problema de forma incremental. El diseño de las entidades en la API también ha sido correcto.

¿Que podría mejorarse?

El hecho de haber diseñado el frontend sin disponer de los conocimientos suficientes de cómo iba a comportarse la API ha provocado una refactorización muy profunda del frontend a la hora de integrarlo con la API. El principal problema ha sido el tratamiento de los objetos en el frontend.

Otro problema ha sido a la hora de inyectar colecciones desde la librería externa en la API. No se realizaban las inyecciones de forma apropiada, por lo que se ha optado por crearlas dentro de la API e integrarlas en el segundo sprint junto con la lógica de negocio.

¿Que se hará diferente?

Estudiar el profundidad cómo deben ser los objetos que debe recibir la API para cambiar la integración frontend-backend y tener más facilidad a la hora de trabajar con los objetos y los stores en JS.

Clone repository
1.-Especificación y formulación del problema
  • 1.1 Nombramiento del equipo Scrum
  • 1.2 Introducción
2. Estudio de Viabilidad del Sistema (EVS)
  • 2.1 MindMap
  • 2.2 ImpactMap
  • 2.3 Alternativas
    • 2.3.1 Sage HR
    • 2.3.2 OrangeHRM
    • 2.3.3 Demeter
    • 2.3.4 Matriz de decisión
3 Especificación de Requisitos del Sistema (ERS)
  • 3.1 Requisitos
  • 3.2 Casos de Uso
  • 3.3 Diseño de la Interfaz de Usuario
4 Definición del MVP
  • 4.1 Product Backlog
  • 4.2 Historias de Usuario
5 Sprint 1
  • 5.1 Sprint Planning
  • 5.2 Sprint Review
  • 5.3 Spring Retrospective
  • 5.4 Burndown
6 Sprint 2
  • 6.1 Sprint Planning
  • 6.2 Sprint Review
  • 6.3 Spring Retrospective
  • 6.4 Burndown