A la hora de determinar el éxito o fracaso de un proyecto, se deben tener en cuenta: los objetivos alcanzados, los requisitos completados cumpliendo sus criterios de aceptación, cuánto se hayan respetado los plazos estipulados y si ha habido o no un aumento con respecto al presupuesto destinado durante la planificación inicial. En este apartado, tras haber completado el desarrollo del producto, vamos a realizar este análisis.

Objetivos y requisitos logrados

Objetivos del proyecto

En la bienvenida a nuestro proyecto, definimos claramente nuestros tres objetivos fundamentales. ¿Se han cumplido dichos objetivos?

En cuanto a los objetivos respecto a la plataforma Streamflix, nuestro producto ofrece la posibilidad de añadir, editar y eliminar tanto películas como series, así como subtítulos y doblajes y otros atributos importantes vinculados al contenido multimedia. Esto permite ofrecer una amplia variedad de contenidos, ya que siempre podrán incluirse nuevos elementos.

Además, las interacciones como dar me gusta, guardar contenidos para verlos más tarde o que se añadan al historial del usuario que haya iniciado sesión permiten generar recomendaciones personalizadas en función del género o los géneros predilectos del mismo, así como las tendencias generales teniendo en cuenta el uso de todos los usuarios registrados.

Finalmente, la posibilidad de dar me gusta mencionada anteriormente permite al usuario tener una lista de contenidos favoritos a la que, desde su perfil, podrá acceder en todo momento.

En segundo lugar, respecto a las buenas prácticas siguiendo SCRUM, y a pesar de que, como veremos más adelante, los plazos y presupuestos no se han cumplido adecuadamente, todo el proceso de desarrollo ha sido seguido lo más fielmente posible. La mejor demostración es toda la documentación incluida en nuestra wiki en sí, donde se ha seguido de principio a fin todo el desarrollo del proyecto, desde el project grooming hasta las conclusiones de esta misma página. Esto último está relacionado con el tercer y último objetivo, que consistía en documentar todo el proceso a lo largo de las iteraciones, que, como se ha mencionado, se ha logrado.

Podríamos concluir que, salvo los detalles que se explicarán más adelante, hemos logrado cumplir con los objetivos establecidos al comienzo de nuestro proyecto.

Requisitos y criterios de satisfacción

Para este apartado, separaremos el contenido por Epics e historias de usuario para que, siguiendo la página del Product Backlog que se definió en su momento, el lector pueda hacer por sí mismo la comparativa y hacer un seguimiento de las conclusiones a las que lleguemos.

Épico 1: Gestionar los contenidos multimedia de la plataforma

El único criterio definido en este Epic que no hemos implementado como tal es, en la historia de usuario 1.5, la búsqueda y el filtrado de contenido por géneros. Sin embargo, en su lugar hemos dispuesto que la pantalla principal, con el historial del usuario, las tendencias y recomendaciones, muestre también directamente todos los contenidos por géneros. Además, en el buscador, seleccionando Contenidos, se puede poner el nombre de un género y, aunque no se busque explícitamente por categorías, mostrará las de ese género. Así, cumplimos con este aspecto de una forma más directa, visible e intuitiva.

Por tanto, podríamos concluir que todas las condiciones de satisfacción de este Epic han sido cumplimentados.

Épico 2: Gestionar los usuarios y sus perfiles

Se tuvieron algunas dificultades para completar todas las condiciones de satisfacción. No obstante, durante el periodo de revisión del proyecto se pudieron afinar y terminar de manera que se cumplen todos los criterios descritos al inicio de la planificación.

Épico 3: Gestionar recomendaciones y otras interacciones de los usuarios con el contenido

El microservicio funcionaba correctamente, pero aunque la lista personalizada se recuperaba correctamente en el microservicio, no se mostraba en la página principal de la interfaz, por lo que hubo que añadir la parte correspondiente a la carga de datos. Ahora se cumplen todas las condiciones de aceptación y se muestran correctamente en su totalidad.

Épico 4: Desarrollar una interfaz accesible

Dentro de este Epic se ha podido satisfacer todas las condiciones de aceptación iniciales propuestas, incluso incorporando propidades que enriquecen la experiencia de uso. Cabe destacar que la implementación de la interfaz como tal, descrita en la HU4.1 ha sido una constante a lo largo de este Epic, dado que implica aglutinar muchos componentes clave como accesibilidad, búsqueda y responsividad; al hacer uso de los servicios ofrecidos por otros microservicios que hasta entonces no se habían necesitado, e inlcuso no se habían contemplado por su especificidad, ha supuesto una revisión de elementos dispuestos previamente e incorporación de otros nuevos, permitiendonos optimizar las relaciones entre los microservicios. Existen muchas de estas relaciones, y por ende muchas dependencias y complejidad para desarrollar lo previsto en este Epic, pero se ha cumplido con creces en todos los aspectos propuestos previamente. Ha tomado muchas revisiones, sin embargo hemos logrado una interfaz consistente, adaptable, clara e intuitiva, que refleja todo lo que fue propuesto.

Cumplimiento de plazos

Como hemos estudiado a lo largo de la asignatura de GPS, el cumplimiento de los plazos de entrega y la correcta planificación son aspectos clave que determinan el éxito o fracaso de un proyecto. Esto ha sido algo que hemos podido comprobar de primera mano.

En nuestro proyecto, no se han podido cumplir los plazos establecidos en numerosas ocasiones y, a riesgo de dejar patente esta falta de organización y de cumplimiento de las planificaciones que, ciertamente, sí se hicieron, hemos querido extraer un aprendizaje.

Una planificación, aun siendo perfecta y realista, no hace nada si no se sigue como es debido. En nuestro caso, los fallos en este aspecto han resultado en revisiones innecesarias que han alargado aún más la finalización de diferentes tareas y, en el último sprint, el hecho de ver cada vez más cerca la fecha de entrega y ver los plazos estipulados por nosotros mismos no cumplidos llevó a trabajar en ocasiones en paralelo y con una comunicación intermitente. A pesar de todo esto, hemos logrado sobreponernos a la situación y hacer un proyecto del que sentirnos lo más orgullosos posibles y los fallos cometidos han servido de lección en este aspecto.

Costes finales del proyecto

La mejor manera de ver el resultado de los problemas en la organización mencionados es hacer un análisis de los costes finales del proyecto.

Como se vio en las conclusiones de viabilidad, el presupuesto estimado para el proyecto según ProjectLibre era de 2.478,13 €.

Sin embargo, si tenemos en cuenta las horas de trabajo reales dedicadas de cada uno de los miembros del equipo, que ha quedado registrado en Jira, y el coste/hora definido en su momento:

• Product Owner. 40 horas * 50 €/hora = 2000 €

• Scrum Master. 27 horas * 40 €/hora = 1080 €

• Desarrollador Senior. 22 horas * 35 €/hora = 770 €

• Desarrollador Junior. 52 horas * 20 €/hora = 1040 €

Estos datos suponen un coste total final del proyecto de 4.890 €.

Como se puede observar, el presupuesto establecido por ProjectLibre ha sido superado enormemente debido a los retrasos y las estimaciones en la duración/complejidad de ciertos requisitos excesivamente optimistas. Sin embargo, no se ha llegado a sobrepasar el presupuesto máximo establecido con los cálculos máximos de la hoja de Excel, por lo que podríamos decir que, a pesar del claro efecto negativo de la inadecuada organización, se ha podido cumplir lo requerido sin exceder los límites impuestos inicialmente.