|
|
Con el la revisión del sprint se busca inspeccionar el incremento realizado en el presente sprint y determinar futuras adaptaciones del product backlog.
|
|
Con el la revisión del sprint se busca inspeccionar el incremento realizado en el presente sprint y determinar futuras adaptaciones del product backlog.
|
|
|
|
|
|
|
|
Para ello hay que recordar el objetivo definido del negocio que es aumentar la venta de accesos al campo facilitando a los principiantes que cumplen con un mínimo en la cancha. Alineado con el mismo se define el objetivo del sprint que es **Manejar la asignación, aceptación y visualización de las asignaciones de partidos por parte de los profesores y jugadores.**.
|
|
Para ello hay que recordar el objetivo definido del negocio que es aumentar la venta de accesos al campo facilitando a los principiantes que cumplen con un mínimo en la cancha. Alineado con el mismo se define el objetivo del sprint que es **Poder crear partidos y visualizar los pendientes de confirmar, confirmados y jugados por parte del profesor**.
|
|
|
|
|
|
|
|
Para acometer este sprint se propuso alcanzar dos objetivos con impacto sobre el profesor:
|
|
## Progreso hacia el Product Goal
|
|
|
1. poder organizar partidos con los jugadores que se fueran federando.
|
|
|
|
|
2. poder gestionar la notificacion, consulta, acuerdo y aceptacion de las caracteristicas del partido.
|
|
|
|
|
|
|
|
|
|
Durante el desarrollo se han ejecutado tareas para progresar tanto en la parte de backend como en la de frontend, pudiendo comprobar que las peticiones se realizan correctamente y habiendo quedado pendiente la validacion de detarminados campos desde la API.
|
|
Durante este Sprint 2 se han marcado una serie de PBIs relacionados con los entregables, solicitar un reto por el profesor y aceptar un reto por un federado, en relación a los impactos de incentivar la competitividad entre jugadores y aumentar el número de juegos en el campo y la variedad de sus contrincantes:
|
|
|
|
|
|
|
|
|
- PBI-07 Ver listado de partidos (Profesor)
|
|
|
|
- PBI-08 Poder asignar partidos (Profesor)
|
|
|
|
- PBI-09 Enviar correo electrónico con enlace de aceptación de partido (Profesor)
|
|
|
|
- PBI-10 Gestionar respuesta de los jugadores a través del enlace de correo
|
|
|
|
- PBI-11 Sugerir intercambio de teléfonos
|
|
|
|
- PBI-12 Enviar teléfonos a los jugadores si aceptan el intercambio
|
|
|
|
- PBI-13 Crear landing page para cuadrar partidos por teléfono
|
|
|
|
|
|
|
|
Los incrementos puede verificarse mediante el acceso a la aplicación desde https://gocourt.netlify.app
|
|
Durante el desarrollo se han alcanzado valor para el cliente a la hora de crear partidos mediante correo electrónico desde el aplicativo, aceptar retos, intercambiar teléfonos en caso de rechazar un partido por motivos de agenda, y crear un nuevo partido acordado por las partes. De este modo se completan los tres primeros impactos definidos en el Impact Map.
|
|
|
|
|
|
|
|
## Adaptaciones Futuras
|
|
Los incrementos puede verificarse mediante el acceso a la aplicación desde https://gocourt.netlify.app .
|
|
|
Estas funcionalidades han sido desarrolladas añadiendo incluso funcionalidades que facilitan el filtrado y la búsqueda de jugadores. Sin embargo, es una consideración a tener en cuenta para el siguiente sprint.
|
|
|
|
|
|
La evolución del Sprint puede apreciarse en el siguiente diagrama, donde se muestran las distintas agrupaciones de funcionalidad asociadas a la implementación del correo electrónico.
|
|
|
|
|
|
|
|
- En cuanto a la aplicación, suele tardar en despertar si no se ha usado recientemente. El cliente muestra su acuerdo con el producto, y era lo que esperaba. El diseño de una interfaz previa con el cliente y su posterior desarrollo en la misma línea, ha facilitado el trabajo del desarrollador y la aceptación del cliente.
|
|
|
|
|
|
|
|
|
|
- Un aspecto importante a tener en cuenta en siguientes sprints, es la comprobación de la versión web desde un terminal móvil, ya que el uso será en gran medida por el profesor desde el campo o la cancha de prácticas.
|
|
Como PBI pendiente realacionado con todo lo anterior, y por acotar la creación y concurrencia de partidos, quedaría:
|
|
|
|
- PBI-14 Validación de partidos.
|
|
|
|
|
|
|
|
- Por otro lado sería importante tener los datos reales, para ajustar la precisión de la puntuación simulada en la cancha y los datos de un partido real para verificar la desviación en el cálculo de la puntuación que realiza la aplicación.
|
|
Este item consistiría en dar salidas al campo desde las 8:00h hasta las 22:00 en periodos de 20 minutos, así como no asignar a un jugador más de un partido al día.
|
|
|
|
|
|
|
|
- Los nuevos requerimentos de la aplicación en el siguiente sprint irán encaminados a la validacion de datos de la API, la federacion de jugadores principiantes y a los servicios de fidelizacion de estos.
|
|
## Adaptaciones Futuras
|
|
|
|
En un futuro podría valorarse la implementación de nuevas funcionalidades en este orden:
|
|
|
|
|
|
|
|
|
- Poder gestionar la notificacion, consulta, acuerdo y aceptacion de las caracteristicas del partido.
|
|
|
|
- Federarse mediante un formulario desde la app.
|
|
|
|
- Poder organizar partidos con los jugadores que se fueran federando.
|
|
|
|
- La generación de ofertas personalizadas, para jugar en sus horarios y campos habituales.
|
|
|
|
|
|
|
|
|
Esto aportaría valor al cliente en el sentido de extender la posibilidad de creación de partidos independientemente de la verificación por parte de los profesores.
|
|
|
|
|
|
|
|
|
|
|
