Sprint 1 ‐ Semana 2 - TheCodeTeamUni/documentacion-proyecto GitHub Wiki
Sprint Burndown Chart
Comparación del trabajo planeado contra el trabajo realizado
Gráfica de trabajo pendiente en el sprint
Informe de trabajo completado
Velocity time chart
Business value chart
Cantidad de trabajo terminado en la semana
Release Burndown Chart
Representa la cantidad de puntos de historia faltantes al inicio y final de cada Sprint
Code coverage chart
Code coverage frontend
Pruebas Unitarias
Code coverage
Pruebas End to End
Code coverage backend
Demotración de funcionalidad
Url Aplicación Web
http://jobs-app-frontends-angular.s3-website-us-east-1.amazonaws.com/landing
APK Aplicación Mobile
https://github.com/TheCodeTeamUni/mobile-proyecto/blob/main/apk/app-debug.apk
Video de demostración del resumen de los entregables del sprint
Evidencias Devops
Commits / pullrequest
Código Backend
-
Repositorio: https://github.com/TheCodeTeamUni/backend-users-proyecto
-
Commits: https://github.com/TheCodeTeamUni/backend-users-proyecto/commits/main
-
Pull Request:
Código Frontend
-
Repositorio: https://github.com/TheCodeTeamUni/frontend-proyecto
-
Commits: https://github.com/TheCodeTeamUni/frontend-proyecto/commits/main
-
Pull Request:
Código Mobile
-
Repositorio: https://github.com/TheCodeTeamUni/mobile-proyecto
-
Commits: https://github.com/TheCodeTeamUni/mobile-proyecto/commits/main
-
Pull Request:
Flujo de trabajo y estrategia de versionamiento
Código Backend
- Flujo trabajo:
- Versión 1: https://github.com/TheCodeTeamUni/backend-users-proyecto/releases/tag/v1.0
Código Frontend
-
Flujo trabajo:
-
Versión 1: https://github.com/TheCodeTeamUni/frontend-proyecto/releases/tag/v1.0
Código Mobile
-
Flujo trabajo:
-
Versión 1: https://github.com/TheCodeTeamUni/mobile-proyecto/releases/tag/v1.0
Ejecución de pruebas
Ejecución de pruebas automática del código
Código Backend
Código Frontend
Retrospectiva
Link Retrospectiva
¿Qué salió bien en el Sprint?
Varios aspectos del sprint resultaron altamente favorables, dado que logramos alcanzar con éxito los objetivos establecidos para cada una de las historias de usuario, al tiempo que entregamos un código impecable siguiendo sólidas prácticas de desarrollo. No obstante, deseamos resaltar especialmente aquellas que consideramos de mayor relevancia:
- Se realizo un proceso de despliegue en la nube que nos permite tener disponible los artefactos del backend, sin necesidad de desplegarlo localmente en nuestras maquinas.
- Se cumplió con un code coverage mínimo del 80% para los componentes del backend y del frontend
- Se presenta una app basada en una arquitectura MVVM utilizando patrones muy estructurados y ordenados de codificación android. Nuestro progreso en cada tarea se ve acorde a lo esperado y por ende tenemos un burndown chart acorde a lo planeado.
- Se mantiene una muy buena comunicación dentro del equipo y esto nos permitió ser mas ordenados a la hora de integrar los diferentes componentes de nuestro sistema.
- Las interfaces de usuario de los dos componentes de Frontend (Android y Web) son claramente agradables y usables para los clientes.
- Se automatizan de forma exitosa los despliegues de los componentes de backend, permitiéndonos ser mas ágiles a la hora de entregar.
¿Qué no salió bien en el Sprint?
Somos conscientes de que, a pesar de entregar todos los elementos a tiempo y de aplicar excelentes prácticas en el desarrollo de nuestros componentes, no todo transcurrió de manera perfecta. Nos enfrentamos a una serie de desafíos que impactaron negativamente en la velocidad que habíamos planificado inicialmente para el sprint, lo que nos obligó a invertir más tiempo del previamente definido. A continuación, destacamos los obstáculos más significativos que encontramos:
- La definición de los elementos de salida del backend no fueron muy claros y a la hora de integrar con lo componentes frontend se presentaron varias inconsistencias que requirieron mas tiempo de desarrollo.
- La integración con el back-end resultó ser un desafío considerable, ya que demandó una curva de aprendizaje muy empinada al intentar comprender la mejor manera de llevarla a cabo.
- En algunas historias de usuarios se definieron tareas que no eran necesarias, ya que muchas se realizaban desde otro componente.
- Planeamos quizás mas puntos de la capacidad del equipo y por ende fue necesario invertir mas tiempo del que inicialmente teníamos planeado.
- Reuniones mas eficientes, es necesario llegar a las reuniones con los puntos claros de que tenemos y los diferentes bloqueos que se presenten