Planificación del proyecto - UniExtremadura/proyecto-gps-25-26-gb05 GitHub Wiki
Modelo de proceso de desarrollo
El equipo ha barajado distintos modelos a la hora de desarrollar el producto. Entre estos modelos destacan: Modelo convencional, proceso unificado y SCRUM.
Dentro de estas opciones se han identificado las distintas ventajas e inconvenientes que cada uno de ellos presenta para así poder elegir el que mejor se adecúe al equipo de desarrollo.
Finalmente, después de debatirlo internamente, se ha elegido SCRUM como el más adecuado para este equipo y proyecto.
Equipo de trabajo
El equipo de trabajo estará conformado por los siguientes integrantes:
- Alejandro Paniagua García — Product Owner (PO). Encargado del Product Backlog, comunicación con los stakeholders, creación de historias y seguimiento de los objetivos del cliente.
- Miguel Alejandro García Sevilla — Scrum Master. Encargado de la organización de las reuniones, control del proceso y el tiempo, impulsor del equipo, gestión de retrospectivas, acuerdos de trabajo y comunicación dentro del equipo.
- Iván Ruiz López — Tech Lead (TL). Visión principal en la arquitectura, estándares, proceso técnico (toma decisiones y gestiona deuda y riesgos técnicos). Descomposición de las historias del Product Backlog en tareas. Principal apoyo para los DevOps y Developers.
- Pablo Rebanales Álvarez — DevOps/QA. Principal responsable de las pruebas del software, CI/CD, gestión de entornos, preproducción y despliegue del software.
- Daniel Barrantes Pulido — Developer. Encargado del desarrollo de funcionalidades siguiendo las tareas técnicas definidas por el Tech Lead priorizando las historias del Product Backlog. Generador de código del software y de pruebas.
Product Backlog
El Product Backlog es el único punto de referencia y la lista priorizada de todo el trabajo que se debe realizar para mejorar, mantener y hacer evolucionar el producto. Sirve como un artefacto vivo y dinámico que refleja la visión y la estrategia del producto.
Este Backlog es una herramienta fundamental en el desarrollo ágil, ya que asegura que el equipo de desarrollo siempre esté trabajando en los elementos de mayor valor para los stakeholders y el usuario final. Los elementos del Product Backlog se detallan progresivamente, priorizan continuamente y se refinan para garantizar que el equipo tenga claro qué entregar en cada Sprint.
La tabla a continuación representa la lista actual de funcionalidades, requisitos, mejoras y correcciones, ordenados por prioridad, valor y estimación de esfuerzo, y servirá como la base de planificación para los próximos ciclos de desarrollo.
| Identificador | Definición | Historias de usuario | Tipo de requisito | Horas-Hombre | Prioridad | Escala MoSCoW | Depende de |
|---|---|---|---|---|---|---|---|
| HU-01 | Registrarse mediante OAuth. | Como usuario y como artista, me gustaria poder registrarme en la plataforma | Estructural | 4 | 10 | MUST HAVE | |
| HU-02 | Iniciar sesión mediante OAuth. | Como usuario y como artista, me gustaria poder iniciar sesión en la plataforma | Estructural | 4 | 10 | MUST HAVE | HU-01 |
| HU-04 | Subir canciones y/o álbumes. | Como artista, me gustaría subir mis canciones y mis álbumes | Estructural | 5 | 10 | MUST HAVE | |
| HU-05 | Visualizar el perfil de un artista. | Como usuario registrado, me gustaría ver el perfil del artista | Estructural | 4 | 10 | MUST HAVE | |
| HU-06 | Modificar datos personales. | Como usuario registrado y como artista, me gustaría modificar mis datos personales del perfil | Estructural | 3 | 10 | MUST HAVE | HU-02 |
| HU-03 | Comprar un producto. | Como usuario registrado, me gustaría poder comprar un producto | Estructural | 7 | 10 | MUST HAVE | HU-04, HU-09 |
| HU-07 | Visualizar la información de un producto. | Como usuario, me gustaría poder ver la información de los productos disponibles | Estructural | 4 | 9 | MUST HAVE | HU-04 |
| HU-08 | Modificar un lanzamiento (canción o álbum). | Como artista, me gustaría cambiar la fecha de un lanzamiento | Estructural | 3 | 9 | MUST HAVE | HU-04 |
| HU-09 | Poner a la venta merchandising. | Como artista, me gustaria poner a la venta productos de mis canciones o álbumes | Estructural | 6 | 8 | SHOULD HAVE | |
| HU-10 | Buscar a artistas por diferentes filtros. | Como usuario, me gustaría buscar artistas por su nombre y el tipo de música que crea | Estructural | 4 | 7 | SHOULD HAVE | HU-05 |
| HU-11 | Reproducir lanzamientos en soporte digital. | Como usuario registrado, me gustaría escuchar desde la plataforma la música que compro | Estructural | 6 | 7 | SHOULD HAVE | HU-04 |
| HU-12 | Obtener estadísticas y el rendimiento de los lanzamientos. | Como artista, me gustaría ver un resumen de cómo estan yendo mis lanzamientos | Estructural | 10 | 7 | SHOULD HAVE | |
| HU-13 | Darse de baja (eliminar cuenta). | Como usuario registrado y artista, me gustaría dejar de formar parte de la plataforma | Estructural | 1 | 7 | SHOULD HAVE | HU-02 |
| HU-14 | Buscar productos por diferentes filtros. | Como usuario, me gustaría realizar búsquedas de productos por género, precio y año de publicación | Estructural | 4 | 6 | COULD HAVE | HU-04 |
| HU-15 | Personalizar el perfil de artista. | Como artista, me gustaría poder modificar como se ve mi perfil | Estructural | 3 | 6 | COULD HAVE | HU-05 |
| HU-16 | Eliminar un producto. | Como artista, me gustaría dejar de vender un producto | Estructural | 1 | 6 | COULD HAVE | HU-04, HU-09 |
| HU-17 | Consultar el centro de ayuda para resolver dudas. | Como usuario, usuario registrado y artista, me gustaría que hubiera un sitio donde resolver las dudas frecuentes | Estructural | 3 | 4 | COULD HAVE | |
| HU-18 | Recibir notificaciones sobre lanzamientos o eventos. | Como usuario registrado, me gustaría recibir notificaciones de eventos o lanzamientos que haya dicho que me interesen | Estructural | 4 | 4 | COULD HAVE | |
| HU-19 | Crear una lista de productos deseados. | Como usuario registrado, me gustaría tener un sitio donde ver productos que me gustaía obtener | Estructural | 2 | 4 | COULD HAVE | |
| HU-20 | Visualizar el perfil de un usuario. | Como usuario, me gustaría ver los perfiles de otros usuarios registrados en la plataforma | Estructural | 3 | 3 | COULD HAVE | |
| HU-21 | Personalizar el perfil de usuario. | Como usuario registrado, me gustaría modificar mi perfil y personalizarlo | Estructural | 3 | 3 | COULD HAVE | HU-20 |
| HU-22 | Crear una lista de reproducción. | Como usuario registrado, me gustaría poder crear una lista utilizando las canciones que tengo adquiridas | Estructural | 2 | 3 | COULD HAVE | |
| HU-23 | Calificar o reseñar un lanzamiento. | Como usuario registrado, me gustaría opinar sobre una canción o album de un artista | Estructural | 2 | 3 | COULD HAVE | HU-04 |
| HU-24 | Buscar usuarios por diferentes filtros. | Como usuario, usuario registrado y artista, me gustaría buscar a ususario registrados por distintos filtros de búsqueda | Estructural | 4 | 3 | COULD HAVE | HU-20 |
| HU-25 | Gestionar el envío de un producto. | Como usuario registradom me gustaría ver información sobre como va mi envío | Estructural | 5 | 3 | COULD HAVE | HU-03 |
| HU-26 | Plataforma accesible para usuarios con distintas discapacidades. | Como usuario con discapacidad, me gustaría una plataforma para que cualquier persona con discapacidad pudiera acceder | No estructural | 8 | 2 | WILL NOT HAVE | |
| HU-27 | Calificar o reseñar un producto de merchandising. | Como usuario registrado, me gustaría dar mi opinión sobre los productos que vende un artista que no sean canciones o álbumes | Estructural | 2 | 1 | WILL NOT HAVE | HU-09 |
| HU-28 | Revisar las ediciones de mis lanzamientos mediante un historial de cambios. | Como artista, me gustaría ver las distintas versiones que ha tenido uno de mis lanzamientos | Estructural | 12 | 0 | WILL NOT HAVE | HU-04, HU-08 |
| HU-29 | Preguntar a un chatbot para resolver dudas. | Como usuario, usuario registrado o artista, me gustaria poder escribir con un bot para resolver dudas | Estructural | 3 | 0 | WILL NOT HAVE |
Esfuerzo del equipo
Horas/Hombre
Esta hoja de cálculo, "Capacidad del equipo", registra las horas de trabajo de los participantes en diferentes categorías. Incluye:
- Participantes: Nombres de los individuos.
- Horas de trabajo/día: El total de horas trabajadas por día.
- Horas clase: Horas dedicadas a clases.
- Otros proyectos: Horas asignadas a otros proyectos.
- Tiempo personal: Horas dedicadas a tiempo personal.
- Actividades SCRUM: Horas dedicadas a actividades SCRUM.
- Totales: La suma total de las horas.
El propósito de la hoja de cálculo es controlar las horas de trabajo de los participantes, desglosadas por diferentes tipos de actividades.
Selección final de requisitos
Con la priorización final de los requisitos utilizando la Escala MoSCoW, se ha definido con claridad el alcance del producto. Los elementos clasificados como MUST HAVE son los requisitos fundamentales e imprescindibles que el producto debe incluir para ser viable y funcional en su primera versión. Estos, como el registro, inicio de sesión (HU-01, HU-02) y la subida de contenido (HU-04). Los requisitos SHOULD HAVE se consideran de alta importancia y se incluirán si el tiempo lo permite, mientras que los COULD HAVE son deseables pero de baja prioridad inmediata. Finalmente, los elementos marcados como WILL NOT HAVE se han descartado de este backlog y del alcance del proyecto actual, asegurando así que el equipo se concentre exclusivamente en entregar el máximo valor en el menor tiempo posible.
Los requisitos a implementar son los siguientes:
| Identificador | Definición | Prioridad | Escala MoSCoW | Viabilidad en el Sprint |
|---|---|---|---|---|
| HU-01 | Registrarse mediante OAuth. | 10 | MUST HAVE | Viable |
| HU-02 | Iniciar sesión mediante OAuth. | 10 | MUST HAVE | Viable |
| HU-04 | Subir canciones y/o álbumes. | 10 | MUST HAVE | Viable |
| HU-06 | Modificar datos personales. | 10 | MUST HAVE | Viable |
| HU-07 | Visualizar la información de un producto. | 9 | MUST HAVE | Viable |
| HU-08 | Modificar un lanzamiento (canción o álbum). | 9 | MUST HAVE | Viable |
| HU-13 | Darse de baja (eliminar cuenta). | 7 | SHOULD HAVE | Viable |
| HU-14 | Buscar productos por diferentes filtros. | 6 | COULD HAVE | Viable |
| HU-03 | Comprar un producto. | 10 | MUST HAVE | Viable |
| HU-09 | Poner a la venta merchandising. | 8 | SHOULD HAVE | Viable |
| HU-11 | Reproducir lanzamientos en soporte digital. | 7 | SHOULD HAVE | Viable |
| HU-16 | Eliminar un producto. | 6 | COULD HAVE | Viable |
| HU-17 | Consultar el centro de ayuda para resolver dudas. | 4 | COULD HAVE | Viable |
| HU-18 | Recibir notificaciones sobre lanzamientos o eventos. | 4 | COULD HAVE | Viable |
| HU-19 | Crear una lista de productos deseados. | 4 | COULD HAVE | Viable |
| HU-22 | Crear una lista de reproducción. | 3 | COULD HAVE | Viable |
| HU-23 | Calificar o reseñar un lanzamiento. | 3 | COULD HAVE | Viable |
| HU-25 | Gestionar el envío de un producto. | 3 | COULD HAVE | Viable |
| HU-05 | Visualizar el perfil de un artista. | 10 | MUST HAVE | Viable |
| HU-10 | Buscar a artistas por diferentes filtros. | 7 | SHOULD HAVE | Viable |
| HU-12 | Obtener estadísticas y el rendimiento de los lanzamientos. | 7 | SHOULD HAVE | Viable |
| HU-15 | Personalizar el perfil de artista. | 6 | COULD HAVE | Viable |
| HU-20 | Visualizar el perfil de un usuario. | 3 | COULD HAVE | Viable |
| HU-21 | Personalizar el perfil de usuario. | 3 | COULD HAVE | Viable |
| HU-24 | Buscar usuarios por diferentes filtros. | 3 | COULD HAVE | Viable |
Los requisitos que hemos decidido que no implementaremos en el proyecto son los últimos cuatro mostrados en product backlog(HU-26, HU-27, HU-28, HU-29). A continuación, se explicarán los motivos de por qué se han dejado fuera del alcance del proyecto.
-
La implementación del requisito HU-26 supondría añadir estándares de accesibilidad (como WCAG), estos requieren un esfuerzo significativo y revisión en todo el sistema.
-
El requisito HU-27, aunque es un requisito estructural, no se implementará en esta etapa debido a que queremos centrarnos en la gestión de venta de productos fisicos, no en la gestión de reseñas y valoraciones de los mismos.
-
Con respecto al requisito HU-28, el implementar un historial de versiones supondría una gran inversión de tiempo y conocimientos complejos para poder guardar, acceder y cambiar las distintas versiones que se hicieron.
-
Para finalizar, el requisito HU-29 no se implementará debido a que se necesita un conocimiento que ninguno de los integrantes del grupo tiene actualmente. Ponerse a aprender el funcionamiento de un chatbot añadiría horas extras, posibles retrasos y la calidad del mismo sería muy baja.
Planificación de tareas
Hemos definido un plan de trabajo basado en tres ciclos de desarrollo (Sprints). Durante la planificación de cada Sprint, se distribuirán los requisitos entre los integrantes del equipo. Las tareas se abordarán de forma individual o en pares, según sea necesario para equilibrar la dificultad y la carga de trabajo. Como regla estricta de planificación, nos aseguraremos de que la suma de las estimaciones en Horas-Hombre de las tareas asignadas a cualquier desarrollador no supere su capacidad de trabajo semanal disponible, evitando la sobrecarga. Cuando empiece el desarrollo, los sprints se harán de miércoles a miércoles.
La división de los requisitos por sprint es la siguiente:
| Identificador | Definición | Sprint | Asignados |
|---|---|---|---|
| HU-01 | Registrarse mediante OAuth. | 1 | Alejandro Paniagua-Iván |
| HU-02 | Iniciar sesión mediante OAuth. | 1 | Alejandro Paniagua-Iván |
| HU-04 | Subir canciones y/o álbumes. | 1 | Miguel Alejandro |
| HU-06 | Modificar datos personales. | 1 | Pablo |
| HU-07 | Visualizar la información de un producto. | 1 | Daniel |
| HU-08 | Modificar un lanzamiento (canción o álbum). | 1 | Daniel |
| HU-13 | Darse de baja (eliminar cuenta). | 1 | Iván |
| HU-14 | Buscar productos por diferentes filtros. | 1 | Pablo |
| HU-03 | Comprar un producto. | 2 | Miguel Alejandro |
| HU-09 | Poner a la venta merchandising. | 2 | Pablo |
| HU-11 | Reproducir lanzamientos en soporte digital. | 2 | Daniel |
| HU-16 | Eliminar un producto. | 2 | Miguel Alejandro |
| HU-17 | Consultar el centro de ayuda para resolver dudas. | 2 | Alejandro Paniagua |
| HU-18 | Recibir notificaciones sobre lanzamientos o eventos. | 2 | Alejandro Paniagua |
| HU-19 | Crear una lista de productos deseados. | 2 | Pablo |
| HU-22 | Crear una lista de reproducción. | 2 | Iván |
| HU-23 | Calificar o reseñar un lanzamiento. | 2 | Daniel |
| HU-25 | Gestionar el envío de un producto. | 2 | Iván |
| HU-05 | Visualizar el perfil de un artista. | 3 | Daniel |
| HU-10 | Buscar a artistas por diferentes filtros. | 3 | Pablo-Iván |
| HU-12 | Obtener estadísticas y el rendimiento de los lanzamientos. | 3 | Iván-Alejandro Paniagua |
| HU-15 | Personalizar el perfil de artista. | 3 | Daniel |
| HU-20 | Visualizar el perfil de un usuario. | 3 | Miguel Alejandro |
| HU-21 | Personalizar el perfil de usuario. | 3 | Miguel Alejandro |
| HU-24 | Buscar usuarios por diferentes filtros. | 3 | Pablo-Alejandro Paniagua |
Estudio de viabilidad
Viabilidad general
La estimación de la capacidad del equipo nos ha arrojado una cifra de 8,4 horas/hombre x día, lo que significa que para cada sprint de 5 días, el equipo tiene una capacidad de 42 horas.
Si comparamos esta cifra, con las horas que se estimaron que supondría completar cada uno de los requisitos de cada sprint, podemos obtener la siguiente gráfica:
Pudiéndose apreciar que las horas estimadas para cada sprint son siempre inferiores a 42 horas, por lo que en términos generales, el proyecto parece viable.
Viabilidad por rol
Para apreciar la viabilidad de cada rol, se hace uso de la herramienta de vista de “Histogramas” por recurso que provee el software ProjectLibre.
Las líneas negras enmarcan la disponibilidad del recurso y el relleno verde indica el esfuerzo estimado que se espera tenga el rol durante las fechas indicadas, por lo que si está por debajo de la línea negra significa que es viable el trabajo que se le ha asignado.
-
Alejandro Paniagua García — Product Owner (PO).
-
Miguel Alejandro García Sevilla — Scrum Master.
-
Iván Ruiz López — Tech Lead (TL).
-
Pablo Rebanales Álvarez — DevOps/QA.
-
Daniel Barrantes Pulido — Developer.
Comprobándose que el proyecto también es viable para cada uno de los roles del equipo.
Coste del proyecto
Tras la información recopilada en el software ProjectLibre, se esperar que cada rol del equipo suponga el siguiente coste para el proyecto:
- Alejandro Paniagua García — Product Owner (PO): 1250.00€.
- Miguel Alejandro García Sevilla — Scrum Master: 1080,00€.
- Iván Ruiz López — Tech Lead (TL): 840,00€.
- Pablo Rebanales Álvarez — DevOps/QA: 725,00€.
- Daniel Barrantes Pulido — Developer: 580,00€.
Por lo tanto, se espera que el coste del proyecto en conjunto sea de unos 4475,00€.