ESCUELA POLITÉCNICA NACIONAL

FACULTAD DE INGENIERÍA DE SISTEMAS

INGENIERÍA EN CIENCIAS DE LA
COMPUTACIÓN

SISTEMA DE RESERVAS – SPRINT 3

GRUPO: 7
INTEGRANTES:
Arias Diego
Cárdenas Fernando
Guamán Sergio
Guerrero Mattew
Vargas Anthony

Quito, Ecuador
Tabla de contenido
DESARROLLO.................................................................................................................3
1. PRODUCT BACKLOG ACTUALIZADO.......................................................................3
1.1. Sprint Backlogs:..............................................................................................4
2. SPRINT PLANNING...................................................................................................4
3. RIESGOS EVIDENCIADOS.........................................................................................7
4. DESARROLLO DEL SPRINT.......................................................................................8
4.1. Sprint Review..................................................................................................8
4.2. Sprint Retrospective......................................................................................12
4.2.1. Criterios de Aceptación Recolectados:..................................................13
4.2.2. Problemas y Desafíos:...........................................................................18
4.2.3. Aspectos Positivos:................................................................................18
4.3. Burndown Chart............................................................................................18
5. CONCLUSIONES.....................................................................................................20
6. EVIDENCIAS..........................................................................................................20
Objetivo del Sprint
Implementar funcionalidades complementarias para el inicio de sesión de
los usuarios, agregar el apartado del historial de usuario y la validación de
la reserva además de la del pago.
Objetivos Técnicos
Asegurar la interoperabilidad entre el frontend, backend y la base de datos
e integrar las funciones de pago con el uso de la API de Paypal, además de
implementar las funciones necesarias para garantizar:
 La disponibilidad de las habitaciones,
 La selección de varias habitaciones,
 La modificación de parámetros,
 El guardado de reservas, y
 El guardado de pagos.
Equipo
ROL Integrante
Scrum Master Anthony Vargas
Tester Fernando Cárdenas
Diego Arias
Sebastián Guamán
Scrum Team
Mattew Guerrero
Fernando Cárdenas
Anthony Vargas
Product Owner Maritzol Tenemaza
Desarrollo
1. Product Backlog Actualizado
A continuación, se muestra el Product Backlog actualizado:
 1.1.Sprint Backlogs:

2. Sprint Planning
Se han considerado los riesgos del Sprint anterior ya que estos nos
ofrecieron una perspectiva más amplia para la realización de tareas más
técnicas y esta vez priorizando también la carga de trabajo asignada para
que las áreas críticas de desarrollo no se estanquen.
Además de eso se decidió continuar con los Products Backlogs
asignados ya en el anterior Sprint porque el objetivo de ellos era
priorizar el valor del negocio, pero dotándolos de más tareas en este
Sprint.
Y dados los resultados desfavorables del anterior Sprint relacionados a
la capacidad del equipo, se decidió aumentar el tiempo de trabajo total
para cada participante del equipo.
Horas x Tareas x Spike x Día Tiempo total x Día
Día
3:30 h 1:00 h 4:30 h
El tiempo de trabajo total para los 13 días de duración del Sprint es de
60 horas aproximadamente y mediante un acuerdo entre el equipo se
decidió traducir esto a puntos de historia, esto a través de una
conversión en la que 2 puntos de historia conforman 1 hora. Dando
como resultado un total de 120 puntos de historia como capacidad del
equipo durante todo el Sprint:

Para la distribución de trabajo se volvió a optar por la técnica de pair

programming entre algunos de los integrantes más capaces del equipo
de desarrollo:
 Pair Programming N°1: Conexión entre base de Datos y Backend

o Mattew Guerrero

o Fernando Cárdenas

 Pair Programming N°2: Conexión entre frontend y backend

o Diego Arias

o Anthony Vargas

En los días que se hayan establecido como los más críticos para el
Sprint, el equipo priorizó las entregas continuas y cortas para darle más
valor al producto.

Para esto se asignó a Fernando Cárdenas como Tester, pero a su vez

también se realiza la corrección de código e integración y lanzamiento
de la aplicación en un entorno de producción (Deploy) de la mano de
Sebastián Guamán.

Este último al realizar la integración del código se encargó de la

corrección de los errores de este y ofreciéndole al resto del equipo una
retroalimentación valiosa que sirvió para la generación de nuevas ideas
que facilitarían la lógica de varias tareas, como lo fue la de integrar un
buen retorno a las funciones que hacían parte del código, a la vez que
estas estaban acompañadas de mensajes de error descriptivos.

Tareas principales:
En base a lo mencionado, se prepararon las siguientes tareas:
 La estimación de estas tareas dio como resultado un total de 125 puntos
de historia por cubrir en 13 días de duración para el Sprint.
3. Riesgos Evidenciados
Dentro del periodo de tiempo asignado para el Sprint 3 (2 semanas
desde el 15 de febrero del 2024) se han evidenciado los siguientes
riesgos y opciones de mitigación usadas:

1. Tas optar por la tecnología de React, Sanity y Stripe el equipo

enfrentó problemas relacionados a la gestión del sistema de
reservas de lado del administrador a razón de una mala
capacitación en relación con la tecnología Sanity.
 Y la forma en la que se abordó este problema fue a través de la
siguiente forma:

 El equipo notó una similitud con Wordpress y al encontrar

más guías de este, se pudo hacer un uso correcto de la
tecnología Sanity.

2. Existían inconformidades en cuanto a la modificación y

eliminación de la reserva de lado del cliente ya que esto generaba
muchos errores y empezaba a retrasar el resto de las tareas.

Por lo que para hacer frente a este problema el equipo optó por lo
siguiente:

 No implementar las funcionalidades de eliminación y

modificación de la reserva hasta que se logre la
implementación correcta de la misma y su guardado en un
historial.

3. A partir del punto anterior podemos agregar que existe un

requerimiento importante y se relaciona por la confirmación del
pago mediante un correo electrónico.

La implementación de esta función requería una gran cantidad de

cambios en lo establecido para las funcionalidades básicas de la
aplicación, por lo que se optó por:

 Preparar al equipo para la capacitación respectiva para

lograr la implementación de esta importante funcionalidad.
A pesar de haber evidenciado varios riesgos que exponen la integridad y
éxito del proyecto, se pudo recoger buenos aspectos positivos que nos
seguirán sirviendo en mejoras a futuro.
4. Desarrollo del Sprint
4.1.Sprint Review
Se mostrarán a continuación los productos resultantes del Sprint:
1. Inicio de la aplicación:
2. Creación de una cuenta:

3. Perfil de usuario (vacío)

4. Habitaciones disponibles

5. Habitación seleccionada
6. Proceso de pago

7. Perfil de usuario con el historial de reservas

Para evidenciar de mejor manera el Sprint Review en base a los
productos resultantes del Sprint N°2 se mostrará el tablero Kanban
para complementar la información mostrada.
4.2.Sprint Retrospective
En la reunión llevada a cabo el día 27 de febrero del 2024 se realizó
el Sprint Retrospective como se muestra en la siguiente imagen:

Y se evidenció lo siguiente:
4.2.1. Criterios de Aceptación Recolectados:

Los criterios de aceptación llevados a cabo serán especificados

individualmente por las historias de usuario que correspondieron
al Sprint.
 US001-1: Definir Características de la Búsqueda:

Escenario Criterios de Aceptación Cumplimiento Comentario

Positivo: Se ingreso Se ingresan correctamente las
correctamente los datos, fechas de check-in y check-out
de ingreso y puede ver (fechas posteriores al día
todas las características actual).
que el sistema de reserva Se selecciona el número de
de habitaciones requiere personas adultas/niños por
(fecha check-in, fecha habitación.
check-out, número de
personas adultas/niños por Se selecciona el tipo de La elección
habitación) hospedaje. del tipo de
hospedaje no
se encuentra
en el mismo
apartado que
los demás.
Se activa el botón de
búsqueda.

Negativo: Se ingresan Se ingresa una fecha de check- El sistema

datos in anterior al día actual o se evita que
incompletos/incorrectos, ingresa una fecha de check-out pueda
dado que ingreso los datos anterior a la fecha de check-in. seleccionar
sin completar todos los fechas
campos, no funciona incorrectas.
adecuadamente. No se selecciona el número de El sistema
personas adultas/niños por muestra un
habitación. mensaje
indicando que
debe
especificar la
cantidad de
personas.
No se activa el botón de El botón sigue
búsqueda. activo, pero no
realizará
ninguna
acción.
 US001-2: Mostrar los resultados de búsqueda

Escenario Criterios de Aceptación Cumplimiento Comentario

Positivo: Se puede El cliente puede visualizar los Esto en base
visualizar los Resultados resultados de la búsqueda. únicamente a
de Búsqueda, dado que el la elección del
cliente ha ingresado tipo de
correctamente todos los hospedaje.
datos de búsqueda.

Negativo: Sin Resultados El cliente no puede visualizar Esto en base

Disponibles, dado que el ningún resultado en la únicamente a
cliente ha ingresado datos búsqueda. la elección del
de búsqueda válidos, pero tipo de
no hay resultados hospedaje.
disponibles.

US001-3: Seleccionar el Hospedaje

Escenario Criterios de Aceptación Cumplimiento Comentario

Positivo: Selección exitosa Se despliega el apartado
de la habitación, dado que correspondiente para la opción
el cliente ha pulsado sobre seleccionada, mostrando
una habitación/plan de su claramente la información
interés se desplegará el deseada y un botón para
apartado correspondiente realizar la reserva.
dicha opción.
Negativo: Selección El sistema no realiza ninguna El cliente
fallida de la habitación, opción o lo lleva a una página experimenta la
dado que el cliente ha de error. falta de
pulsado sobre una respuesta o es
habitación/plan de su redirigido a
interés, no ocurre nada. una página de
error.

US002-1: Mostrar el precio total

Escenario Criterios de Aceptación Cumplimiento Comentario
Positivo: Se actualiza el Se muestra el precio total a
precio del hospedaje pagar por el hospedaje.

Negativo: No se actualiza El precio de la habitación no se

el precio del hospedaje actualiza.

US002-2: Selección de método de pago

Escenario Criterios de Aceptación Cumplimiento Comentario

Positivo: El cliente puede Se habilita el botón de pago.
seleccionar de entre los
métodos de pago
desplegados.

Negativo: El cliente no El cliente no puede seleccionar

puede seleccionar de entre de entre los métodos de pago
los métodos de pago. (No se habilitan los botones).

El método de pago elegido por Esto puede

el cliente no puede ser producirse al
validado debido a falta de ingresar mal
fondos, tarjeta los datos de
expirada/bloqueada/no pago del
existente. cliente.

US002-3: Ingreso de datos personales y de pago para

confirmar la reserva
Escenario Criterios de Aceptación Cumplimiento Comentario
Positivo: El cliente puede El cliente puede ingresar sus
ingresar sus datos en cada datos de pago en cada uno de
uno de los campos. los campos y efectúa su
transacción.

Negativo: El cliente no El cliente no puede ingresar Si el cliente

puede ingresar sus datos o sus datos de pago o deja deja los
deja alguno de los campos campos vacíos. campos vacíos
obligatorios vacíos. y pulsa el
botón de pago
se le notifica
que debe
llenar los
campos
obligatorios.

US002-4: Despliegue de un resumen de información

Escenario Criterios de Aceptación Cumplimiento Comentario

Positivo: El cliente puede Se despliega un resumen de Solo se
visualizar el resumen de información que incluye incluyen los
información antes de detalles de la habitación, detalles de la
confirmar el pago. comodidades, datos de emisión habitación y el
de factura y el precio final. precio final a
pagar.

Negativo: El cliente no El cliente no puede visualizar

puede visualizar el el resumen de información.
resumen de información
antes de confirmar el
pago.

US003-1: Despliegue de mensaje acerca de la reservación

realizada

Escenario Criterios de Aceptación Cumplimiento Comentario

Positivo: El cliente puede Se muestra un aviso de Solo se
visualizar el aviso de confirmación de pago exitoso muestra un
confirmación de pago además de observar la “visto” al
exitoso. confirmación mediante correo completar la
electrónico. transacción y
el cliente
puede
visualizar su
reserva en su
perfil.
Negativo: El cliente no El cliente no puede ver el aviso
puede visualizar el aviso de confirmación y no recibe
de confirmación de pago. detalles del recibo.

Se muestra un aviso de Esto puede

confirmación de pago, pero deberse a un
indica que la transacción falló. fallo en la API
de pago usada.

Aunque el aviso es positivo, el

cliente no encuentra detalles
del recibo en su correo
electrónico.

4.2.2. Problemas y Desafíos:

 La incertidumbre de llevar ciertas tareas preocupaba al

equipo de desarrollo ya que su inexperiencia con las
tecnologías a implementar implicaba una capacitación
constante.

 Falta de una confirmación vía correo electrónico.

 No se implementó la funcionalidad para modificar una

reserva.
  Dificultad elevada a momento de realizar el deploy de la
aplicación en un entorno de producción.

4.2.3. Aspectos Positivos:

 A través de reuniones diarias y retroalimentación por

parte externa (docentes y compañeros de otros equipos) se
han logrado solventar varias dudas con respecto a las
tecnologías a usarse.

 Los resultados que otorga el uso de metodologías como

XP para el desarrollo de proyectos ayudó mucho a la
gestión y elaboración de código. Por lo que en este Sprint
seguimos usando la técnica de pair programing además de
facilitar el proceso de entregas cortas y continuas.

4.3.Burndown Chart
A continuación, se presenta la gráfica relacionada al Burndown en
cuanto a la suma de trabajo restante:
 A continuación, se presenta la gráfica relacionada al Burndown en
cuanto al recuento de trabajo restante:

5. Conclusiones
 Para la conclusión del Sprint, consideramos que cumplimos con los
objetivos propuestos, sin embargo, si se dejó de lado ciertos aspectos
importantes que hubieran garantizado un mejor producto tanto en el
aspecto visual como funcional para una mayor satisfacción del
usuario.

 Como equipo, hemos concluido que debemos priorizar las tareas que
le otorguen valor al negocio con el fin de que en cada Sprint
podamos entregar un MVP que resulte funcional para los encargados
del manejo de la aplicación.
6. Evidencias
Sprint Planning meeting (15/02/2024)
A continuación, se muestran las descripciones de las 3 de las Daily
Meetings consideradas como las más importantes (de un total de 10):

Daily meeting (23/02/2024)

Anthony Vargas Que hice hoy: Spike para la implementación de
una función que permita cambiar el valor booleano
de una habitación disponible.
Que voy a hacer mañana: Preparar informes para
la presentación final del proyecto, tomando en
cuenta los comentarios realizados e implementar
correcciones útiles.
Duda: Ninguna
Fernando Cárdenas Que hice hoy: Corregir y analizar la
implementación entre front, back y la base de
datos.
Que voy a hacer mañana: Implementar las
funciones CRUD junto con el postman para el
manejo de datos.
Duda: ¿Cómo cargaremos las imágenes?
Mattew Guerrero Que hice hoy: Terminar diseño de interfaces y
conexión.
Que voy a hacer mañana: terminar de cargar las
tablas
 Duda: como realizar una conexión con el back y
eso se refleje en el front
Sergio Guamán Que hice hoy: Probar y unificar código
Que voy a hacer mañana: Inicio del despliegue de
la aplicación
Duda: Ninguna
Diego Arias Que hice hoy: Spike para entender el
funcionamiento del historial de compras
Que voy a hacer mañana: Corrección para la
visualización del historial de compras en el perfil
de usuario
Duda: Integración del historial en el perfil del
usuario.

Daily meeting (24/02/2024)

Anthony Vargas Que hice hoy: Preparar informes para la
presentación final del proyecto, tomando en
cuenta los comentarios realizados e implementar
correcciones útiles.
Que voy a hacer mañana: Consultar al equipo
para la realización de la integración de la Stripe
de Paypal.
Duda: Ninguna
Fernando Cárdenas Que hice hoy: Definir la lógica de compras y
reservaciones.
Que voy a hacer mañana: Implementar esta
 lógica.
Duda: ¿Cómo implementar esto con el front y el
back?
Mattew Guerrero Que hice hoy: Terminar de cargar las tablas
Que voy a hacer mañana: Realizar conexiones
faltantes con los métodos adecuados.
Duda: Ninguna
Diego Arias Que hice hoy: Corrección para la visualización
del historial de compras en el perfil de usuario
Que voy a hacer mañana: Implementación de
funciones dentro del frontEnd y backEnd para
realizar la reserva
Duda: Dificultad en relación a las colecciones
definidas en MongoDB

Daily meeting (26/02/2024)

Anthony Vargas Que hice hoy: Consultar al equipo para la
realización de la integración de la API de Stripe e
integración del botón de pago.
Que voy a hacer mañana: Elaboración de la
documentación final de los Sprints y del proyecto
en general.
Duda: Ninguna
Mattew Guerrero Que hice hoy: Búsqueda de fallas
Que voy a hacer mañana: avanzar en el
desarrollo de la base
 Duda: Ninguna
Sergio Guamán Que hice hoy: Spike
Que voy a hacer mañana: Terminar crude
Duda: Ninguna
Diego Arias Que hice hoy: spike de librerias Bootstrap y Font
Awesome
Que voy a hacer mañana: avanzar con el
desarrollo del historial de compras
Duda: Funciones JS con respecto al Backend y
Fronted