Retrospective
Issue 1
Específico: la descripción de cada tarea debería estar encaminada a facilitar el trabajo al developer definiendo las entidadesy/o los componentes que deben manejarse en el issue para reducir interpretaciones
Medible: al menos debería incluirse un elemento del backend o fronted para trabajar
Alcanzable: todo desarrollo obligatoriamente debe mantener una relación directa con uno de estos elementos
Realista: el PO si es capaz de facilitar esta descripción correcta evita redefinir un issue
Duración limitada: la estimación debe ajustarse a lo establecido para cada issue/jornada facilitando el cálculo total
Issue 2
Específico: los criterios de aceptación en ocasiones no relacionan todas las partes implicadas por lo que el criterio de aceptación debería describir un orden secuencial de la funcionalidad
Medible: un criterio de aceptación debería al menos centrarse en la acción inicial, el proceso seguido para llevar al resultado y un valor final o aque necesario para el siguiente elemento a desarrollar
Alcanzable: es asimilable en el caso del front que funcionalidad debe implementarse y en el back, aquellas entidades que deben manejarse o crearse para llevarlo a cabo
Realista: en ocasiones no se va a poder valorar si un issue por si solo va a alcanzar la funcionalidad por lo que debe asumirse que forma parte de una misma finalidad
Duración limitada: el criterio de aceptación debe poder estimarse de la misma manera que la descripción ajustándose a la jornada
2024-05-29 Se comprueba funcionalidad de los issues PBI-07
como mejora al final del sprint para acceso rápido desde el móvil, podría haberse planteado por el cliente en la interfaz para implementarlo:
añadir atributo html tipo mailto:
añadir atributo html tipo tlf:
Es fundamental una visualización previa de lo que se quiere y los pasos que sigue el usuario. Comparar este proceso de interacción de usuario en el equipo, para contrastar divergencias y acordar una solución concreta.
2024-06-02 Se comprueba funcionalidad de los issues PBI-09 PBI-10
cumple con el objetivo de aceptar o rechazar, el correo muy conciso e intuitivo
la funcionalidad del correo automático evita errores humanos. No obstante, y a efectos prácticos, tanto el profesor como el personal de recepción podrían acceder en cualquier momento a la aplicación para solicitar un nuevo partido a petición de los interesados, así como enviar correos o llamar directamente desde la tarjeta de usuario de la aplicación
2024-06-04 PBI-07 PBI-10 PBI-11
Si bien cada una de las tareas van cumpliendo con el objetivo, se plantean distintas cuestiones:
Se observa que un solo correo no es suficiente para confirmar el partido tanto si es aceptado como si no. Por ello, en caso que el contrincante acepte, sería interesante enviar un segundo correo para confirmar el lugar del encuentro, fecha y participantes.
Por otro lado, en caso de que el contrincante no acepte, el partido se genera indistintamente como ACEPTADO - NO ACEPTADO, por lo que en este caso no debería enviarse el siguiente correo de confirmación del encuentro.
Dada la casuística de la no aceptación del partido, los datos disponibles del jugador y con el objetivo de mantener el foco en el negocio para vender más salidas al campo, sería interesante que el jugador pudiera aceptar compartir un teléfono o correo para concretar un encuentro. De esta manera se añadiría otra oportunidad de generar un partido.
En cuanto a la visualización de partidos, aparecen aquellos con fechas pasadas. Sería de interés poder fitlrar o borrar de alguna manera esos partidos para que no se acumulen.
2024-06-11 PBI-10 PBI-11
Los correos de solicitud se tramitan correctamente con información concisa del estado del partido y las indicaciones para proceder y se comprueba su estado de partidos confirmados y pendientes de jugar en la aplicación. Los correos de intercambio de teléfonos se tramitan correctamente para cada jugador