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_2
  • 6.3 Spring Retrospective

Last edited by ddcDIM47 Jun 16, 2025
Page history

6.3 Spring Retrospective

Mejoras aplicadas

En esta retrospective, lo primero que vamos a hacer es detallas que medidas se tomaron respecto al anterior sprint para la mejora de la metodología y el trabajo en equipo, ver el nivel de aplicación y si han sido o no útiles.

  • Reunión semanal con el cliente: Una de las medidas a adoptar ha sido mantener una reunión semanal con todos los miembros del equipo (Cliente, PO, Developer). De esta manera Se pueden resolver dudas de procesos, implementación, etc... y todos los miembros del equipo saben hacia donde se encamina el proyecto. Esta medida tenía como principal objetivo evitar descoordinaciones como la ocurrida con como se visualizaban los componentes en el sprint 1.

En relación a lo anterior el calendario de reuniones ha sido el siguiente:

  • Semana 1 (15/05/2025): Especificación más detallada de algunas dudas del negocio.
  • Semana 2 (22/05/2025): Resolución de dudas de los tipos de solicitudes y puesta en común del diseño requerido para el frontend.
  • Semana 3 (29/05/2025): Especificación de la actualización de los costes por día y de los presupuestos.
  • Semana 4 (05/06/2025): Planteamiento y aprobación de la batería de pruebas. Resolución de dudas respecto a la actualización del presupuesto.
  • Semana 5: review y pruebas.
  • Plan de pruebas funcionales aprobado con el cliente: Esta medida se orienta a que todos los miembros del equipo partan de una misma base para testear el sistema de modo que se puedan aplicar los mismos criterios de evaluación y evitar cambios de última hora o adhoc. Las pruebas a realizar serán las siguientes.

Detalle de las Pruebas

Tabla de Casos de Prueba

ID Caso de Prueba Descripción Pre condiciones Resultado Esperado Estado Responsable Notas
TC-001 Obtención del coste por empleo/día En función de los datos del reservista de la petición obtiene el importe por día Reservista Correcto/Solicitud creada Se obtiene el importe por el empleo y día para el reservista de la petición Hecho Tte. Daniel Dominguez CONCRETADO CON CLIENTE
TC-002 Actualización del coste por empleo/día Comprobación de la correcta actualización de los importes de coste de un reservista en función de su empleo por día. Se tiene acceso a la aplicación. Coste actualizado de forma correcta Hecho Tte. Daniel Dominguez CONCRETADO CON CLIENTE
TC-003 Rechazar Solicitud Se permite validar que se rechaza de forma correcta una solicitud. Enviando la respectiva notificación al solicitante. Solicitud en evaluación/Los datos de contacto son correctos Solicitud rechazada de forma correcta/la solicitud no se muestra por defecto/ El solicitante es notificado Pendientes Tte. Daniel Dominguez CONCRETADO CON CLIENTE
TC-004 Calcular presupuesto Solicitud Se verifica que se calcula de forma correcta el coste de una solicitud y se comprueba se se dispone de créditos suficientes Solicitud en evaluación/solicitud no rechazada Se calcula el presupuesto de la solicitud/Se evalúa la capacidad de pago de la solicitud/se recomienda aceptar/rechazar la solicitud Pendientes Tte. Daniel Dominguez CONCRETADO CON CLIENTE
TC-005 Consultar Credito Disponible Se verifica que se consulta de forma correcta los créditos disponibles para pagar activaciones de reservistas Se tiene acceso a la aplicación Se obtiene el credito restante hasta el momento Pendientes Tte. Daniel Dominguez CONCRETADO CON CLIENTE
TC-006 Actualizar Crédito Disponible Se verifica la correcta actualización del crédito disponible, ya sea de forma manual o tras realizar activaciones Se tiene acceso a la aplicación/Solicitud aceptada Se visualiza el crédito actualizado de forma correcta Pendientes Tte. Daniel Dominguez CONCRETADO CON CLIENTE

Detalle por Caso de Prueba

TC-001 – Obtención del coste por empleo/día

  • Descripción: Para poder realizar el cálculo del coste de una solicitud de activación, es necesario poder recuperar el dato de coste por empleo/día del reservista correspondiente a una solicitud. Por lo tanto se necesita verificar que este dato se recupera de forma correcta.
  • Pre condiciones: Usuario con acceso al sistema
  • Pasos:
    1. Navegar a la pantalla de costes
    2. Se muestran los costes por empleo y día disponibles
    3. Se chequea que los costes son los que corresponde
    4. Se realiza el calculo de coste para una solicitud y se chequea que el importe es correcto
  • Resultado esperado: Se recupera de forma correcta el coste correspondiente.
  • Resultado real: Se visualizan los costes de forma correcta.
  • Estado: Completado.

TC-002_1 – |Actualización del coste por empleo/día

  • Descripción: Puesto que el importe que cuesta un reservista por día y empleo va variando en lo relativo al paso del tiempo, es necesario poder actualizar estos importes en nuestro sistema. Para ello la pantalla de consulta debe permitir la modificación de dichos importes.
  • Pre condiciones: Usuario con acceso al sistema.
  • Pasos:
    1. Navegar a la pantalla de costes
    2. Se muestran los costes por empleo y día disponibles
    3. Se introducen los nuevos valores para los costes
    4. Se comprueba que los costes se modifican de forma correcta
  • Resultado esperado: Se notifica la correcta actualización de los costes/se visualizan de forma correcta los nuevos importes
  • Resultado real: Se actualizan los costes de forma correcta.
  • Estado: Completado.

TC-002_2 – |Actualización errónea del coste por empleo/día

  • Descripción: Puesto que el importe que cuesta un reservista por día y empleo va variando en lo relativo al paso del tiempo, es necesario poder actualizar estos importes en nuestro sistema. Para ello la pantalla de consulta debe permitir la modificación de dichos importes.
  • Pre condiciones: Usuario con acceso al sistema.
  • Pasos:
    1. Navegar a la pantalla de costes
    2. Se muestran los costes por empleo y día disponibles
    3. Se introducen los nuevos valores para los costes
    4. Los costes no se modifican
  • Resultado esperado: Se notifica el error en la actualización de los costes y el motivo.
  • Resultado real: No se ha podido forzar el error.
  • Estado: Completado

TC-003_1 – Rechazar Solicitud

  • Descripción: Como parte de las funcionalidades del sistema, es necesario poder rechazar una solicitud por diferentes motivos.
  • Pre condiciones: Usuario con acceso al sistema. Solicitud en evaluación.
  • Pasos:
    1. Acceder a la solicitud
    2. Se pulsa en "Rechazar Solicitud"
    3. La solicitud se rechaza de forma correcta.
  • Resultado esperado: La solicitud se rechaza de forma correcta. La solicitud solo aparece en rechazadas. Se notifica al solicitante el rechazo.
  • Resultado real: Se rechaza la solicitud y se cambia su estado de forma correcta.
  • Estado: Completado

TC-003_2 – Rechazar Solicitud Erróneo

  • Descripción: Como parte de las funcionalidades del sistema, es necesario poder rechazar una solicitud por diferentes motivos.
  • Pre condiciones: Usuario con acceso al sistema. Solicitud en evaluación.
  • Pasos:
    1. Acceder a la solicitud
    2. Se pulsa en "Rechazar Solicitud"
    3. Se motiva el rechazo y se acepta
  • Resultado esperado: Se muestra un mensaje de error al rechazar la solicitud y el error originado.
  • Resultado real: No se ha podido forzar el error.
  • Estado: Completado

TC-004_1 – Calcular presupuesto Solicitud

  • Descripción: Para evaluar de forma correcta una solicitud, una de las condiciones es que se disponga de créditos suficientes para hacer frente al pago de la misma. Para ello es necesario obtener el coste total de la solicitud y evaluar si se tienen suficientes créditos.
  • Pre condiciones: Usuario con acceso al sistema. Solicitud pte. de evaluación.
  • Pasos:
    1. Recuperar la solicitud
    2. Comprobar que las fechas son correctas.
    3. Clic en calcular presupuesto.
  • Resultado esperado: Se muestra el coste total. Se indica si se debe aceptar o no la solicitud en base al coste.
  • Resultado real: Se calcula el coste de la solicitud de forma correcta.
  • Estado: Completado.

TC-005 – Consultar Crédito Disponible

  • Descripción: Para mantener informado al usuario del crédito con el que cuenta a la hora de decidir si se aprueba o no una solicitud, es necesario poder obtener los créditos restantes para pagar nuevas solicitudes.
  • Pre condiciones: Usuario con acceso a la aplicación.
  • Pasos:
    1. Ir a la pantalla de créditos
    2. Consultar los créditos disponibles
    3. Chequear que la cantidad es correcta
  • Resultado esperado: Créditos disponibles
  • Resultado real: Se muestra el crédito disponible de forma correcta.
  • Estado: Completado

TC-006_1 – Restar Crédito Disponible

  • Descripción: Para poder realizar la correcta gestión de las solicitudes recibidas, es necesario tener actualizado de forma correcta la cantidad de créditos disponibles en cada momento. En este caso se debe calcular de forma correcta el descuento del coste de la activación aceptada. De forma que ya se tenga el crédito actualizado para futuras solicitudes.
  • Pre condiciones: Usuario con acceso a la aplicación.
  • Pasos:
    1. Ir a la pantalla de créditos
    2. Consultar los créditos disponibles
    3. Aceptar una solicitud con coste.
    4. El coste se modifica en función del coste de la solicitud.
  • Resultado esperado: Créditos disponibles después del gasto de la activación.
  • Resultado real: Al aceptar solicitudes se resta de forma correcta el coste al crédito disponible. Si no se tiene presupuesto suficiente no se permite aceptar una solicitud.
  • Estado: Completado

TC-006_2 – Actualizar Crédito Disponible

  • Descripción: Para poder realizar la correcta gestión de las solicitudes recibidas, es necesario tener actualizado de forma correcta la cantidad de créditos disponibles en cada momento. En este caso cuando se asignan nuevos créditos, es necesario añadir este importe al sistema para poder gestionar nuevas solicitudes.
  • Pre condiciones: Usuario con acceso a la aplicación.
  • Pasos:
    1. Ir a la pantalla de créditos.
    2. Ver créditos actuales.
    3. Se introduce la cantidad asignada.
    4. Los créditos disponibles se actualizan con la cantidad asignada.
  • Resultado esperado: Se actualiza de forma correcta el crédito disponible.
  • Resultado real: Se actualiza de forma correcta el crédito con la cantidad introducida
  • Estado: Completado

Resumen de Estado

  • Aprobados: 10
  • Fallidos: 0
  • Bloqueados: 0
  • Pendientes: 0

Conclusiones

Tras realizar la batería de pruebas, se puede llegar a la conclusión de que los casos de uso están cumplidos casi al 100%. El único error encontrado es la actualización de una solicitud en fechas donde no se actualiza el coste de la misma. Si bien puede llegar a ser un error importante en función de las características.

A continuación se realiza el resto de la retrospective de la misma forma que en el primer sprint.

¿Qué fue bien?

  • Mejora de comunicación con el cliente al marcar reuniones periódicas.
  • Consenso de las pruebas entre todos los miembros del equipo

¿Qué podría mejorarse?

  • La lógica de trabajo del proyecto es compleja y difícil de entender aun con con la mejora de la comunicación del cliente.

¿Qué se hará diferente?

  • Se buscará acceso a los usuarios del sistema para ver de primera mano la operativa concreta de cada caso de uso.
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