Seguimiento del proceso
Para realizar un seguimiento del proceso se ha pasado la planificación de Project Libre a Jira, un producto de software propietario para la gestión de proyectos, seguimiento de errores e incidencias.
Además se proporciona esta sección de la wiki como una documentación más detallada del seguimiento y gestión del proyecto, permitiendo observar la administración de flujos de trabajo seguimiento la metodología ágil SCRUM.
En cuanto a la estructura, cada requisito épico se ha abordado como una "Incidencia Épica", y las tareas correspondientes a cada escenario se han tratado como "Tareas".
En relación a las iteraciones, estas se definen como "Sprints" que agrupan todas las tareas asociadas al progreso de la iteración en cuestión. Cada tarea de historia de usuario se vincula a la "Incidencia Épica" del mismo escenario y se asigna a un Sprint específico, correspondiente a uno de los 7 sprint que abarcará el mismo.
Durante el desarrollo, es importante tener un set de herramientas que nos permitan trabajar de forma correcta y eficiente. Para ello, se da libertad a los miembros del grupo para trabajar con el conjunto de las mismas que cada uno decida individualmente, pero asegurando que se cubren todas las necesidades del proyecto.
Como entorno de desarrollo, se decide utilizar Android Studio.
Este software es un entorno de desarrollo integrado creado específicamente para el desarrollo de aplicaciones móviles en el sistema operativo Android. Es la herramienta oficial proporcionada por Google y se ha convertido en la opción preferida para muchos desarrolladores de aplicaciones Android. Algunas de las características que nos han hecho decantarnos por el son:
- Es el IDE recomendado en la asignatura de ASEE
- Tiene compatibilidad con Kotlin
- Incluye emuladores y dispositivos virtuales
- Es posible depurar
- Tiene un control de gestion de versiones integrado (Git)
- Creación de UI de forma gráfica mediante arrastrar y soltar
Github Desktop o Gitkraken. Ambas opciones son válidas en caso de no querer utilizar el gestor de Git integrado en Android Studio.
-
Github Desktop: GitHub Desktop es una aplicación con interfaz gráfica diseñada por GitHub para simplificar el uso de Git. Con una interfaz intuitiva, facilita operaciones como clonar repositorios, gestionar ramas y realizar confirmaciones. Se integra directamente con GitHub, muestra el historial de cambios y ofrece notificaciones visuales. Es multiplataforma (Windows y macOS) y está pensado para hacer que Git y GitHub sean accesibles para usuarios sin experiencia en la línea de comandos, siendo una opción amigable para principiantes.
-
Gitkraken: GitKraken es una herramienta visual para el control de versiones Git. Ofrece una interfaz gráfica intuitiva que facilita la clonación de repositorios, la gestión de ramas y las confirmaciones de código. Destaca por su diseño visual de ramas, permitiendo a los usuarios trabajar de manera eficiente. Además, brinda integración con plataformas como GitHub y GitLab, soporta sistemas operativos como Windows, macOS y Linux, y proporciona una experiencia visual atractiva para simplificar el flujo de trabajo en Git. GitKraken es apreciado tanto por principiantes como por usuarios avanzados gracias a su enfoque intuitivo.
En caso de tener un equipo limitado en potencia, se da la posibilidad de emular la aplicación a desarrollar en el dispositivo personal de la persona. Para ello, cada persona se hace responsable de las modificaciones necesarias a realizar en el dispositivo
Como gestor de tareas, se utilizará Jira.
Este software es una plataforma de gestión de proyectos. Proporciona una interfaz visual para la planificación, seguimiento y administración de proyectos de software. Jira permite la creación y asignación de tareas, la gestión de sprints, y proporciona herramientas avanzadas para la colaboración en equipo. Su flexibilidad nos permite utilizar una metodología como SCRUM. Además, Jira integra funciones de seguimiento de errores, mejoras e informes, proporcionando una visión completa del progreso del proyecto.
El reparto de roles dentro del equipo es el siguiente:
- Scrum Master: Sr. Blanco
- Project Owner: Sr. Marrón
- Desarrollador Senior: Sr. Naranja
- Desarrollador Junior: Sr. Azul
El Sr. Blanco será el jefe de proyecto del equipo 1, encargado de finalizar los Sprint 1 y 5, siendo encargado de realizar las historias de usuario GD05-12, GD05-13, GD05-14, GD05-15 y GD05-16, según la planificación seguida en Jira. Las tareas asignadas son las siguientes:
Para la planificación del primer Sprint, se han seleccionado tareas sencillas de configuración para que el equipo empiece a acostumbrarse al proceso de trabajo al mismo tiempo que se familiarizan con el IDE, lenguaje y método de trabajo. Al mismo tiempo, se seleccionan tareas de configuración ya que de su implementación dependerá la forma de asignar ciertos atributos a los estilos aplicados en la aplicación.
La asignación de las tareas merece una justificación, pues cada rol está mas especializado en el cumplimiento de cierto tipos de tareas. También hay que tener en cuenta la carga de trabajo, pues no podemos sobrecargar a un recurso y, aunque no sea lo optimo, a veces hay que utilizar un recurso sub-optimo con el objetivo de no sobrepasar el límite de horas del recurso óptimo. Para este caso se ha utilizado la siguiente lógica:
-
Product Owner: Se le han asignado las tareas mas cercanas al look and feel de la aplicación y su funcionamiento, ya que es el mayor conocedor del producto. También le han sido asignadas las tareas relacionadas con QA, como es el testing para asegurar que la calidad del producto final es la adecuada.
-
Desarrollador Senior: Se le han asignado las tareas lógicamente mas abstractas y complicadas, como pueden ser las partes de programación pura.
-
Desarrollador Junior: Se le han asignado las tareas de programación menos complicadas. Gran parte de ellas siendo lógicas sencillas sin mucha probabilidad de fallo en su desarrollo.
-
Scrum Master: Se le ha utilizado como desarrollador de apoyo, rellenando huecos para tareas que el resto de roles no podía cumplir debido a la carga de trabajo total.
-
GD05-5: Configuración y ajustes de la aplicación.
-
GD05-12: Cambiar tamaño de letra
-
GD05-37 Asignar tamaños de fuente:
- Persona asignada: Scrum Master
-
GD05-38 Aplicar ajustes:
- Persona asignada: Scrum Master
-
GD05-39 Botón de "Ajustes":
- Persona asignada: Product Owner
-
GD05-40 Lanzar "Settings" desde "Home"
- Persona asignada: Desarrollador Junior
-
GD05-41 Pantalla "Settings"
- Persona asignada: Desarrollador Junior
-
GD05-42 Testing
- Persona asignada: Product Owner
-
GD05-37 Asignar tamaños de fuente:
-
GD05-12: Cambiar tamaño de letra
-
GD05-5: Configuración y ajustes de la aplicación.
-
GD05-13: Activar modo oscuro
-
GD05-43: Crear tema claro
- Persona asignada: Desarrollador Senior
-
GD05-44: Crear tema oscuro
- Persona asignada: Desarrollador Senior
-
GD05-45: Aplicar ajustes
- Persona asignada: Desarrollador Junior
-
GD05-46: Crear aplicación base
- Persona asignada: Desarrollador Senior
-
GD05-47: Pantalla "Home"
- Persona asignada: Product Owner
-
GD05-48: Barra de búsqueda
- Persona asignada: Product Owner
-
GD05-49: Barra de navegación
- Persona asignada: Product Owner
-
GD05-50: Testing
- Persona asignada: Desarrollador Junior
-
GD05-43: Crear tema claro
-
GD05-13: Activar modo oscuro
El Sr. Marrón ha tenido dudas con una pantalla debido a que el diseño inicial de la UI no estaba correctamente definido.
El Sr. Azul ha estado indispuesto varios dias, lo que ha obligado a hacer su parte de forma rápida, por lo que no tiene mucho que decir.
El Sr. Naranja no ha tenido problemas en hacer su parte del trabajo, pero ha tenido dudas en cuanto a la metodología.
El Sr. Blanco está teniendo problemas con la Wiki al clonarla. Tuvo que hacer su parte deprisa debido al acoplamiento de tareas dependientes de las de el Sr. Azul.
En esta gráfica podremos ver el cumplimiento total del Sprint. Como podemos observar, se hizo un primer Sprint de 9 horas. Debido a la falta de soltura del equipo, se quedó de forma conjunta para hacer el cierre entre todos y que todo el mundo viese el proceso, por lo que el gráfico muestra como se pasa de un 0% del trabajo a un 100% en el mismo dia.
En la siguiente gráfica se muestran los estados de las incidencias con el tiempo. Esto ayuda a identificar cuellos de botella potenciales que tienen que tenerse en cuenta.
Como se han añadido una gran cantidad de incidencias en general pero solo se va a hacer una pequeña parte, solo una pequeña parte se pintan de verde, mientras que las que quedan pendientes están en lila.
Durante el paso a "develop", se siguió la directriz de pasar "develop" a la rama pertinente, comprobar que la rama sigue funcionando correctamente y, acto seguido, pasar la rama a "develop" una vez se ha comprobado que la integración de ambas ramas es correcta y no hay nada estropeado.
- Verde: El inicio del proyecto quedó marcado por un mal inicio, ya que la subida inicial se hizo una vez creadas las ramas, por lo que hubo que llevarse ese cambio posteriormente a las ramas creadas.
- Rojo: En esta sección puede verse como, al tratar de llevarse "develop" a otra rama, hubo un error y se llevo una rama sobre otra del desarrollo, lo cual trató de revertirse pero al ser un merge, se decidió continuar con ello ya que era la primera vez que se hacia el proceso.
- Azul: Tras el error anterior de la zona roja, se hizo el merge de la rama que quedaba, la cual, al no haber tenido modificaciones desde la creación, no había posibilidad de llevar "develop" a la rama.
- Definición del proyecto: Gracias a la creación entre todos de la UI; todo el mundo tiene una idea clara de las lineas generales del proyecto.
- Wireframe: Completado con pequeños detalles gracias a las dudas del Sr. Marron.
- Aclaración de tareas: Debido a la falta de detalles en las tareas, ha habido bastante tiempo perdido por aclarar puntos. Tambien relacionado con la falta de pulido de la UI.
- Sobrecarga: Debido a cuestiones externas al proyecto, varios de los miembros del equipo se han sentido sobrecargados al haber tenido que hacer sus tareas de forma tardía.
- Sensaciones del equipo: Sensación de no llegar a la fecha límite debido al comienzo tardio del proyecto debido al alargamiento de la planificación.
- Seguimiento de tareas: Utilizar algún método de seguimiento de tareas o una mayor definición. Para ello, se utiliza un filtro en Jira para ver las tareas asignadas a ti mismo y se añadirá descripción a las tareas.
assignee=@TuIdJira
- Reunión a mitad de Sprint: Se plantea la posibilidad de asignar una reunión a mitad de Sprint para su mejor control sobre el proceso y los problemas acarreados. Esta reunión no tiene un caracter fijo y se hará bajo demanda de los miembros del equipo.
Debido a cambios con las fechas de entrega de proyecto se ha realizado una recomposición de la planificación en 4 sprints, manteniendose el primero que ya ha sido realizado y modificando los posteriores, de esta forma se mantiene que cada miembro rota por los distintos roles y se completa el trabajo en la fecha estimada.
El reparto de roles dentro del equipo es el siguiente:
- Scrum Master: Sr. Marrón
- Project Owner: Sr. Naranja
- Desarrollador Senior: Sr. Azul
- Desarrollador Junior: Sr. Blanco
En el equipo número 2, el jefe de proyecto será el Señor Marrón. Durante esta fase el equipo trabajará en la implementación de la búsqueda de piezas mediante la API y la implementación de la sección "Mi Inventario". A continuación, se presenta un desglose detallado de las tareas asignadas y las responsabilidades de los miembros del equipo:
Debido al cambio en la fecha de entrega aunque los roles se sobrecargan todos los miembros han decidido ocupar más tiempo en el proyecto para su debido cumplimiento, una vez repartidos los roles se ha decidido asignar las tareas según el conocimiento y experencia de estos, manteniendo siempre un balance de horas entre los propios miembros.
-
Product Owner: - Se le han asignado las tareas de creación de pantallas quedando así al gusto de este el diseño a aplicar, además de la implementación de la búsqueda y la relación entre pantallas
-
Desarrollador Senior: - Se le han asignado las tareas relacionadas a la gestión de piezas, especificamente su borrado, además será el encargado de probar una de las partes fundamentales de la aplicación la búsqueda de piezas.
-
Desarrollador Junior: - Se le han asignado las tareas relacionadas con la API pues es quien dispone de un mayor conocimiento del tema, además de testear la consulta del inventario.
-
Scrum Master: - Se le han asignado las tareas de la modificación de cantidad de piezas del inventario y su testeo, además se encargará de la creación de la base de datos.
-
GD05-6: Gestión de "Mi Inventario".
-
GD05-14: Consultar Inventario.
-
GD05-51: Crear clase de datos local.
- Persona asignada: Product Owner
-
GD05-52: Crear pantalla "Mi Inventario".
- Persona asignada: Product Owner
-
GD05-53: Crear pantalla "Pieza Nº".
- Persona asignada: Product Owner
-
GD05-54: Navegación de una pieza de "Mi Inventario" a "Pieza Nº".
- Persona asignada: Product Owner
-
GD05-55: Crear base de datos Room.
- Persona asignada: Scrum Master
-
GD05-56: Crear clase de consulta a BBDD.
- Persona asignada: Scrum Master
-
GD05-57: Crear metodo para consultar todas las piezas.
- Persona asignada: Scrum Master
-
GD05-58: Testing.
- Persona asignada: Desarrollador Junior
-
-
GD05-15: Modificar cantidad piezas de "Mi Inventario".
-
GD05-59: Crear método cambiar cantidad piezas de "Mi Inventario".
- Persona asignada: Scrum Master
-
GD05-60: Añadir botones +, - en "Pieza Nº".
- Persona asignada: Scrum Master
-
GD05-61: Añadir botones +, - en "Mi Inventario".
- Persona asignada: Scrum Master
-
GD05-62: Testing.
- Persona asignada: Scrum Master
-
-
GD05-16: Eliminar pieza de "Mi Inventario".
-
GD05-10: Buscar pieza.
-
GD05-66: Crear modelo de datos de API.
- Persona asignada: Desarrollador Junior
-
GD05-67: Crear clase de consulta a la API.
- Persona asignada: Desarrollador Junior
-
GD05-68: Crear mapper del modelo de la API al local.
- Persona asignada: Desarrollador Junior
-
GD05-69: Búsqueda funcional.
- Persona asignada: Product Owner
-
GD05-70: Navegación desde "Home" a "Pieza Nº".
- Persona asignada: Product Owner
-
GD05-71: Testing.
- Persona asignada: Desarrollador Senior
-
-
“Somos los que somos y hacemos lo que podemos”.
Nota el retraso del anterior Sprint y siente que hemos sobrecargado el trabajo de este Sprint.
Sensación similar a la del anterior Sprint, aunque ya se va cogiendo ritmo. Se nota el retraso provocado por el último Sprint, pero se lleva bien.
El retraso del anterior Sprint ha tenido un gran impacto en la cantidad de trabajo, y el reparto de tareas pudo haber sido bastante mejor.
En esta gráfica vemos el trabajo realizado en el sprint 2. Como se ha comentado durante este sprint hubo una sobrecarga de los recursos debido a la entrega de la asignatura ASEE, llevando a una reorganización de la idea inicial del sprint, por esto vemos que en la gráfica las tareas se marcaron todas como finalizadas en el última día con los miembros del equipo.
En la siguiente gráfica podemos ver que el grupo pudo conseguir un proceso sustancial de las tareas realizadas.
Podemos ver que la gráfica está ajusta a la semana que duró el sprint 2, y aunque se conseguió terminar con éxito vemos que existe un margen de horas por hacer, esto se puede explicar pues se excedieron las estimaciones iniciales de algunas tareas, provocando así que el sprint acabe con horas por hacer.
Se muestra además el proceso de unión o finalización del sprint en github a la rama develop, se siguió la directriz de pasar "develop" a la rama pertinente, comprobar que la rama sigue funcionando correctamente y, acto seguido, pasar la rama a "develop" una vez se ha comprobado que la integración de ambas ramas es correcta y no hay nada estropeado. Como hemos visto más tarde este no es el proceso correcto a seguir, pues se debería haber llevado cada rama una vez finalizada a develop y se deberían sacar desde aquí en caso de querer realizar merges con alguna rama que dependiese de otra.
- El equipo ha cogido ritmo
- La implementación está siendo limpia
- El equipo de desarrollo se ha adaptado al flujo de trabajo correctamente
- El retraso acumulado
- El repartimiento de trabajo es mejorable
- Retrasos debido a tareas dependientes asignadas a distintos miembros del equipo
- Repartir tareas por dependencia, en vez de por rol, para evitar dependencias de trabajo entre miembros
El reparto de roles dentro del equipo es el siguiente:
- Scrum Master: Sr. Naranja
- Project Owner: Sr. Azul
- Desarrollador Senior: Sr. Blanco
- Desarrollador Junior: Sr. Marrón
En el equipo número 3, para realizar el sprint 3, el encargado de la organización del equipo será el Señor Naranja. Esta fase del proyecto se centrará en la implementación de la sección de sets favoritos y la gestión de datos de las piezas de sets en "Mi Inventario". A continuación, un resumen de las tareas de la fase:
A la hora de planificar el sprint 3 se realizó un cambio significativo en la estructura organizativa del proyecto completo, esto se debe a la necesidad de reducir de las 7 semanas de proyecto estimadas a 4 con el fin de cumplir con los plazos de entrega. Este cambio en la planificación general supuso un importante problema a la hora de predecir las horas de trabajo y carga de trabajo por cada componente del equipo.
Sumado a la reestructuración general, la compaginación del desarrollo del sprint con otras asignaturas supuso una adaptación en la asignación de tareas del sprint para algunos miembros que no podían dedicarle todo el tiempo necesario.
Teniendo en cuenta el trabajo desarrollado en sprints anteriores, la asignación de las tareas se se deben a la suma de la carga de trabajo de cada miembro y a la especialización de cada uno en ciertas partes del proyecto; y sobretodo y más importante, teniendo en cuenta los problemas de dependencias de trabajo entre miembros para poder realizar las tareas en sprints anteriores, se ha actuado en consecuencia. Para este caso se ha utilizado la siguiente lógica:
-
Product Owner: - Este recurso es uno de los dos que va a trabajar en quizás la parte más importante de este Sprint (el requisito épico: "Gestión de búsqueda y filtrado a través de una API"), y por ello se ha decidido dividir las tareas implicadas entre dos de los recursos.
-
Desarrollador Senior: - Se le han asignado múltiples tareas relacionadas con la gestión de sets favoritos, la gestión del inventaro de piezas, y el filtrado de estas. Es el recurso más sobrecargado en este sprint debido a su mayor disposición de tiempo en esta ocasión, por lo que se intentará corregir esta sobrecarga en el próximo Sprint.
-
Desarrollador Junior: - Este es el segundo recurso de los dos que va a trabajar en quizás la parte más importante de este Sprint (el requisito épico: "Gestión de búsqueda y filtrado a través de una API"), pues es quien dispone de un mayor conocimiento del tema. También participará en la gestión de sets favoritos.
-
Scrum Master: - Se le han asignado las tareas relacionadas con una parte muy concreta: compartir un set. Para realizar esto, depende de la realización de las tareas del resto de recursos
-
GD05-6: Gestión de "Mi Inventario".
-
GD05-7: Gestión de sets favoritos.
-
GD05-25: Guardar Favoritos
-
GD05-94: Añadir funcionalidad del botón de añadir sets a favoritos.
- Persona asignada: Desarrollador Junior
-
GD05-94: Añadir funcionalidad del botón de añadir sets a favoritos.
-
GD05-26: Eliminar Favoritos
-
GD05-96: Añadir funcionalidad del botón de eliminar sets de favoritos.
- Persona asignada: Desarrollador Junior
-
GD05-96: Añadir funcionalidad del botón de eliminar sets de favoritos.
-
GD05-19: Compartir Set
-
GD05-24: Ver Favoritos
-
-
GD05-9: Gestión de búsqueda y filtrado a través de una API.
-
GD05-18: Buscar Set
-
GD05-74: Botón de tipo de búsqueda (Bloque/Set).
- Persona asignada: Desarrollador Senior
-
GD05-75: Búsqueda funcional de Set.
- Persona asignada: Desarrollador Senior
-
GD05-76: Test de búsqueda.
- Persona asignada: Desarrollador Senior
-
GD05-77: Pantalla de "Set"
- Persona asignada: Product Owner
-
GD05-78: Navegación desde "Búsqueda" a "Set".
- Persona asignada: Product Owner
-
-
No ha tenido problemas con este Sprint.
El Sr. Azul esta teniendo problemas con el emulador Android de Android Studio y no es capaz ni de simular el proyecto ni de instalarselo en su móvil.
Ha tenido problemas con la conexión con la API debido a un bug de otra parte del proyecto.
El Sr. Blanco no ha tenido problemas con este Sprint.
En esta gráfica podemos ver que se ha logrado cumplir el Sprint en menos tiempo del estimado, esto se debe a una clara sobrecarga de trabajo entre los días 26 y 27 de Noviembre donde, por cuestiones de compatibilidad con otras asignaturas, se realizó prácticamente todo el trabajo.
También se aprecian algunas anomalías en la línea de alcance del trabajo, causadas por la edición de la predicción de horas en mitad del sprint lo que, aunque forma un diagrama poco habitual, no supone una diferencia en el resultado real del sprint.
En la siguiente gráfica se muestran los estados de las incidencias con el tiempo. Esto ayuda a identificar cuellos de botella potenciales que tienen que tenerse en cuenta.
Como se puede apreciar en el diagrama, se han añadido nuevas incidencias para representar las asignaciones del sprint y, posteriormente, han sido completadas, es por esta razón, que el área por hacer ha aumentado para posteriormente aumentar la zona completada.
Durante el paso a "develop", se siguió la directriz de pasar "develop" a la rama pertinente, comprobar que la rama sigue funcionando correctamente y, acto seguido, pasar la rama a "develop" una vez se ha comprobado que la integración de ambas ramas es correcta y no hay nada estropeado.
En el siguiente diagrama se puede ver cómo el sprint se origina de la división de la rama /develop/ de forma correcta y el desarrollo del sprint es normal aunque, se aprecia en las zonas marcadas en rojo que, debido a dependencias entre ramas para el desarrollo de ciertas partes, se lanzaron merges entre ramas. Esta forma de trabajar no es correcta, pues se debería haber empleado la rama develop como intermediaria para la actualización entre ramas, haciendo merge desde la rama origen a /develop/ y posteriormente, de /develop/ a la rama destino.
- El equipo ya ha cogido rodaje: Ya nos hemos acostumbrado al flujo de trabajo y ha habido una mayor comodidad con las tareas.
-
Problemas con el entorno: Ha habido problemas con la estabilidad del entorno, ya que al Sr. Azul le ha dejado de funcionar correctamente Android Studio
-
Sobrecarga: Debido a la aproximación de la fecha de entrega, cuestiones externas al proyecto y el incremento de tareas debido al acortamiento de plazos, el equipo lleva dos Sprints con sobrecarga lo cual empieza a notarse.
- Seguimiento de tareas: Se hará una reunión a mitad de semana presencial en la que se tratara de arreglar el entorno del Sr. Azul entre todos.
El reparto de roles dentro del cuarto y último equipo es el siguiente:
- Scrum Master: Sr. Azul
- Product Owner: Sr. Blanco
- Desarrollador Senior: Sr. Marrón
- Desarrollador Junior: Sr. Naranja
En el equipo número 4 (con el Sr. Azul como Scrum Master) se realizará el desarrollo del respectivo sprint 4 del proyecto, el último con el que finalizamos el trabajo de creación de todas las funcionalidades de la app.
Se implementará el requisito épico "Consultar información de Sets". Una vez teniendo esta implementación, se desbloquean las dos últimas historias de usuario (eliminar y guardar las piezas de los sets, previamente consultados, en el Inventario) que forman parte del requisito épico "Gestión de Mi Inventario". Por ello, en este Sprint nos centraremos en la gestión de la información de dichos sets, con sus respectivas consultas de piezas. Concretamente, se desarrollan las últimas 4 historias de usuario del proyecto que faltan.
Adicionalmente, al ser el último sprint de la construcción, se sobrecargarán los recursos para subsanar algunos errores leves surgidos de anteriores historias de usuario y los surgidos en la realización de estas nuevas tareas.
En este último sprint la organización del trabajo se ha enfocado teniendo en cuenta el trabajo restante por realizar. Para facilitar la realización del trabajo, siendo estas últimas historias de usuario parte de dos requisitos épicos donde dos historias de usuario de uno dependen de las otras dos historias del otro requisito, se ha asignado a cada recurso las tareas de una única historia de usuario. También se ha tenido en cuenta la cantidad de trabajo disponible de cada uno de los recursos para asignar las tareas.
-
Product Owner: - Tanto su trabajo como el del Scrum Master dependen del trabajo de los desarrolladores. Una vez está implementado el primer requisito épico, finaliza el trabajo con su funcionalidad.
-
Desarrollador Senior: - Este recurso, al haber sido sobrecargado en exceso en sprints anteriores, es el que menos carga de trabajo tiene asignada. Eso sí, una vez finalizada la historia de usuario del desarrollador junior, debe realizar con urgencia su tarea para poder continuar el trabajo.
-
Desarrollador Junior: - El desarrollador Junior, debido a los reajustes y motivos explicados anteriormente, es el encargado de iniciar el sprint con su implementación. Puesto que el resto de tareas del sprint dependen de la consulta de "Piezas de un Set", este recurso debe ser el que emplee su capacidad antes, para permitir la continuación del sprint.
-
Scrum Master: - El Scrum Master es el encargado de acabar la funcionalidad del sprint, y por tanto, de la aplicación. Puesto que es el último en realizar su implementación y por tanto su rama contiene toda la funcionalidad completa de la app, se le asigna también el deber de revisar y testear el código de este último sprint; y de corregir los errores que han ido surgiendo durante el proceso.
-
GD05-8: Consultar información de Sets
-
GD05-6: Gestión de "Mi Inventario".
El Sr.Marron realizó su trabajo con eficiencia, y debido a la situación, lo más rápido posible para permitir el trabajo de sus compañeros.
El Sr.Azul se encargó de completar el sprint con la última funcionalidad, y para compensar los problemas del sprint anterior, se sobrecargó para arreglar errores de la aplicación en los dos días extra del sprint.
El compañero fue el encargado de iniciar el sprint y de realizar la historia de usuario más costosa.
El Sr.Blanco realizó su trabajo con eficiencia, y debido a la situación, lo más rápido posible para permitir el trabajo de sus compañeros.
Este es el último gráfico de trabajo realizado durante el sprint 4; donde podemos observar como se realizó correctamente todas las tareas pendientes para acabar las historias de usuario, y con ello la primera versión de la aplicación completa.
Como se puede ver, se fueron realizando las 4 historias de usuario asignada a cada uno de los recursos. Al ser depender en cadena una funcionalidad de la siguiente, se realizaron por orden de dependencia. Pero debido a la extensión del plazo de entrega de este último sprint, se puede observar cómo se acabó el trabajo fuera del plazo previsto. Se aprovechó estos días extra para arreglar errores acomulados, añadiendo esta implementación en las últimas tareas asignadas al Scrum Master.
En esta gráfica se muestran los estados de las incidencias en el tiempo, desde el 30 de noviembre al 7 de diciembre (puesto que se alargó un par de días la finalización del sprint).
Como se puede apreciar en el diagrama, se han realizado todas las incidencias planificadas, pero sin embargo no se han completado el 100% de las tareas puesto que se decidión no realizar una historia de usuario programada como opcional, y por tanto, prescindible.
La integración de las ramas de trabajo del proyecto se realizó siguiendo la misma metodología de sprints anteriores.
Sin embargo, se cometieron varios errores que influyen en la correcta visualización de la integración realizada entre las ramas (aunque esto no afecctó a la implementación del trabajo). Principalmente, en este sprint se utilizan ramas creadas anteriormente, puesto que en el sprint anterior hubo que reorganizar el trabajo planificado, por lo que no es posible ver su creación. Por otro lado, un compañero realizó un merge por error, como se puede apreciar el día 3 de diciembre, puesto que por dependencias del trabajo necesitaba lo que había realizado el otro compañero. Por último, debido a que esta integracón se realizó desde Android Studio, se observa como faltan ciertos "merges", puesto que a la hora de actualizar la rama /develop/ con ciertas ramas de trabajo, no se pudo realizar puesto que las ramas ya estaban actualizadas.
Pero como se ha indicado ya, pese a parecer errónea la integración, a efectos prácticos se ha ido actualizando progresivamente la rama /develop/ hasta contener toda la funcionalidad.
- Implementación: Gracias al trabajo individual de aprendizaje realizado por cada uno de los miembros del este equipo durante estos dos meses, en este último sprint se ha alcanzado una buena calidad de programación.
- Trabajo en equipo: Se ha creado un buen entorno de trabajo, los miembros del equipo hemos creado un vínculo que ha favorecido a la comunicación y por ende al desarrollo del proyecto.
- Objetivo alcanzado: Después de todo el trabajo conjunto realizado, se ha alcanzado el objetivo principal del proyecto: la creación de una versión funcional de nuestra aplicación Android. Se han completado todas las historias de usuario planificadas a tiempo para la entrega, junto con toda la documentación pertinente.
- Sobrecarga final: Al igual que en el resto de sprints, hemos sufrido una cierta sobrecarga de trabajo frente a lo previsto. Aunque el resultado final ha sido satisfactorio, se ha trabajado más de lo que deberíamos.
-
Tests y pruebas: Se realizarán las pruebas necesarias para comprobar la calidad del software.
-
Refactorización: Se llevará a cabo una refactorización de la aplicación para aplicar ciertos patrones de diseño.