Documento resumen Sprint nº2
Nos presentamos con un nivel 2 de aplicación con un total de 6 nuevas entidades que se usan en el proyecto y 25 historias de usuario.
- La asignación de dichas historias de usuario es la que se muestra al final de la página principal de la wiki de Github.
- Hemos creado una sola tarea y rama para implementar la funcionalidad que se indica en cada historia de usuario.
- Se han creado ramas adicionales para solventar errores e integrar diferentes elementos como la API REST o TravisCI
- La creación de las seis nuevas entidades se fue realizando conforme los miembros del grupo las iban necesitando para implementar sus historias de usuario, siguiendo el modelo del UML realizado por el grupo.
- Para implementar el código hemos utilizado la metodología de programación por parejas. De esta forma mientras un miembro de la pareja programaba el otro integrante observaba el proceso para detectar el máximo nº de errores posibles durante el desarrollo.
- En la imagen siguiente se muestra las parejas que han desarrollado los distintos archivos necesarios (con respecto a entidades, controladores, validadores y servicios) para implementar las funcionalidades requeridas.
P1: Francisco Antonio Arroyo Aponte y Francisco Javier Romero González-Regueral
P2: Alejandro Blanco Pérez y Carlos Cruz Martínez
P3: Adrián Fernández Fernández y Maria de Gracia Piñero Pastor
A parte de la creación de los archivos señalados también se han modificado otros para poder implementar las funcionalidades
- Para llegar al nivel de 6 puntos hemos ido realizando las pruebas unitarias tanto de los servicios, validadores y controladores conforme íbamos implementando las funcionalidades. Las pruebas de los controladores se realizaron más tarde en algunas historias de usuario que ya estaban implementadas debido a que el contenido teórico necesario para realizarlas no se había dado. Por cada controlador, servicio y validador se han realizado pruebas unitarias respectivamente. Dichas pruebas las desarrollaron los mismos integrantes que implementaron dichos controladores, servicios y validadores previamente, como se muestra en la imagen superior.
En dichas pruebas hemos seguido las pautas que se nos daban en la teoría contemplando los casos positivos y negativos que pudiesen ocurrir durante la ejecución del sistema. Para asegurarnos de que no implementábamos ninguna funcionalidad que pudieses incluir posibles errores las ramas de funcionalidades no eran “mergeadas” con la rama maestra hasta que dichas pruebas fuesen exitosas.
- Para alcanzar el nivel de 8 puntos hemos configurado las pruebas automáticas en la web TravisCI. Está configuración se ha realizado cuando ya teníamos implementadas la mayor parte de las historias de usuario, debido a que preferimos centrarnos primero en implementar las funcionalidades esenciales de la web, por lo que no existen muchas “builds” realizadas a fecha de 27 de marzo de 2020.
La imagen muestra dos builds con errores ya que hubo un problema de codificación con tres ficheros y no permitía ejecutarlas
Hemos realizado un par de “builds” customizadas sobre la rama maestra para asegurarnos que el repositorio estaba bien configurado y que todas las pruebas hasta esa fecha implementadas eran exitosas.
- Para alcanzar el nivel de 9 puntos hemos implementado la API REST de MAILJET . Dicha API ofrece un endpoint para enviar correos electrónicos a los destinatarios que se elijan. Aprovechamos dicho servicio para enviar un e-mail a los usuarios a los que un veterinario añade una receta a una mascota de su propiedad, para avisarlos de tal evento y comunicarles que pueden ver la información completa de la receta en la web. Para implementar este servicio hemos utilizado la librería que ofrece el propio MailJet (importándola con Maven) y usando las clases y métodos que esta ofrece.
Finalmente hemos implementado diversas pruebas unitarias parametrizadas para probar distintos rangos de valores que se pudieran dar en la ejecución de la web. Dichas pruebas se encuentran en las pruebas de los servicios. Un ejemplo de las mismas se muestra en la siguiente imagen.
El Segundo Sprint ha ido bastante mejor de lo esperado. Hemos tenido dificultades, retrasos y varias dudas, pero hemos sabido solventar todo eficientemente. Una de las ventajas claras del trabajo en pareja es que obtienes el feedback de otra persona al momento de la programación. Esto agiliza mucho las revisiones.
Pareja 1 Miembros: Francisco Javier Romero González-Regueral (25 horas) y Francisco Antonio Arroyo Aponte (24 horas)
Esta pareja ha realizado un esfuerzo total de 49 horas.
Analisis retrospectivo de la Pareja 1 sobre el primer Sprint:
- Que seguir haciendo: Dividir la tareas equitativamente, para así evitar sobrecargar a un miembro.
- Que dejar de hacer: No pedir ayuda, ya que si cuando nos atascamos en algún HU pedimos ayuda a nuestros compañeros, estos pueden ayudarnos y resolver el problema antes. Esto nos haría aprovechar más el tiempo.
- Que empezar a hacer: Comunicarnos más entre nosotros para ser asi más productivos y reforzar las relaciones humanas.
Pareja 2 Miembros: Carlos Cruz Martínez (23 horas) y Alejandro Blanco Pérez (22 horas)
Esta pareja ha realizado un esfuerzo total de 45 horas.
Analisis retrospectivo de la Pareja 2 sobre el segundo Sprint:
- Que seguir haciendo: Mantener el nivel de comunicación que hemos llevado hasta ahora, ya que nos ha ido bastante bien.
- Que dejar de hacer: No actualizar las issues cuando debemos, ya que nuestros compañeros no saben el estado actual de nuestra parte del trabajo y puede llevar a confusión.
- Que empezar a hacer: Debemos ser más puntuales, para asi aprovechar más el tiempo y ser más eficientes. También es una muestra de respeto hacia el otro compañero.
Pareja 3 Miembros: María de Gracia Piñero Pastor (22 horas) y Adrián Fernández Fernández (26 horas)
Esta pareja ha realizado un esfuerzo total de 48 horas.
Analisis retrospectivo de la Pareja 3 sobre el segundo Sprint
- Que seguir haciendo: Tener actualizadas las "issues", para asi tener claro el estado en el que se encuentran cada una de ellas y el estado general del Sprint.
- Que dejar de hacer: Hacer varias funcionalidades en una misma rama, ya que después hay que volver a hacer la funcionalidad que ha sido realizada en el sitio equivocado en la rama correspondiente.
- Que empezar a hacer: Preveer un tiempo "de colchón" para imprevistos, por si aparece algún problema que nos ocupe más tiempo del esperado, poder solventarlo y llegar a tiempo al "Milestone"