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 16
    • Issues 16
    • 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
  • Manuel de Blas
  • demeterdemeter
  • Wiki
    • 5.sprint1
  • 5.3 Spring Retrospective

Last edited by Manuel de Blas Pino Oct 07, 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. Introducción
    2. Definición del problema
    3. Descripción del proceso actual
    4. Actores
    5. Alcance y limitaciones
  2. Estudio de Viabilidad del Sistema (EVS)
    1. Mind Map
    2. Impact Map
    3. Historias de Usuario
    4. Alternativas
      1. Sage HR
      2. OrangeHRM
      3. Deméter
      4. Matriz de decisión
  3. Especificación de Requisitos del Sistema (ERS)
    1. Requisitos
    2. Casos de Uso
    3. Diseño de la Interfaz de Usuario
    4. Product Backlog
  4. Definición del MVP
  5. Sprint 1
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  6. Sprint 2
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  7. Sprint 3
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  8. Sprint 4
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Restrospective
  9. Acrónimos y siglas