|
|
|
### Lecciones aprendidas
|
|
|
|
A lo largo del desarrollose han identificado distintas lecciones que se consideran de utilidad para futuros proyectos en los que trabajar:
|
|
|
|
|
|
|
|
#### Uso de historias de usuario para evaluación de alternativas y estimación
|
|
|
|
|
|
|
|
La estimación de los proyectos es compleja y relativamente fiable, siempre teniendo en cuenta que esa fiabilidad depende de la experiencia previa. Sin embargo, las estimaciones aportan al cliente una información crucial a la hora de decidir si realizar, continuar o desechar ciertos proyectos. Estas estimaciones no solo afectan al tiempo de desarrollo, también afectan al coste y a los recursos necesarios, por lo que cuanto más acertadas, mejor se ajustará el proyecto.
|
|
|
|
|
|
|
|
Para poder hacer estas estimaciones se optó por los puntos historia, estrategia de estimación para desarrollos ágiles. Esto obligó, por consiguiente, a definir las historias de usuario que necesitaba el cliente poder completar. Siguiendo el proceso que se ha realizado en el anterior proyecto durante el curso, puede considerarse que la definición de historias de usuario puede haber sido previa a lo adecuado, pero esta definición previa ha tenido resultados positivos en la evaluación de las alternativas y no solo en la estimación del proyecto.
|
|
|
|
|
|
|
|
En referencia a esos resultados positivos, se ha visto que a la hora de comparar alternativas, para establecer aquellas que cumplen o no los impactos o que complementan a los mismos, se puede realizar dicha comparativa en base a estos puntos historia, aportando un punto de vista más sólido en cuanto a valoración de cumplimiento de funcionalidades entre distintas soluciones.
|
|
|
|
|
|
|
|
Por todo ello, esta decisión, fruto de la arbitrariedad a la hora de la estimación, se considera que ha resultado positiva y se recomienda como aproximación durante el **Estudio de Viabilidad del Sistema** por la consistencia que aporta no solo a la estimación, si no a la valoración de las distintas alternativas.
|
|
|
|
|
|
|
|
#### Contemplar opciones alternativas de almacenamiento de datos
|
|
|
|
|
|
|
|
A la hora de valorar la tecnología adecuada para el almacenamiento de los datos, es importante contemplar las opciones no tradicionales. Durante el proyecto, la primera de las opciones que se contempló fue una base de datos SQL. Se realizaron una serie de pruebas para comprobar usar una base de datos de este estilo y no se tenía claro que, con los conocimientos disponibles por el desarrollador, se pudiera alcanzar el objetivo. Las múltiples y variadas relaciones muchos a muchos y la existencia de objetos que no son necesarios almacenar como tal fueron las principales pegas que se encontraron en el sistema.
|
|
|
|
|
|
|
|
Buscando soluciones sobre la implementación de la base de datos y la API, surge la posibilidad de utilizar una base de datos NoSQL, adaptándose MongoDB justo a las necesidades que se tenían. A la larga, se ha visto que el uso de MongoDB ha facilitado mucho el desarrollo, sin complicar excesivamente el *backend*, pero ofreciendo también posibilidades de configuración interesantes.
|
|
|
|
|
|
|
|
Por lo tanto, se considera adecuado que a la hora de valorar las tecnologías, lo primero se hagan pruebas con las mismas, y lo segundo se tengan en cuenta varias opciones, entre ellas aquellas que no sean las tradicionales.
|
|
|
|
|
|
|
|
#### Rendimiento no constante
|
|
|
|
|
|
|
|
Se ha observado que el rendimiento del trabajo y la calidad del mismo varía en función del día de la semana. Puede parecer vanal, pero el trabajo realizado los lunes y los viernes solía ser de menor calidad y más lento que el del resto de la semana. Por ello, la decisión de empezar los sprint en un jueves, aunque a consecuencia de la disponibilidad del cliente para la reunión de aprobación de la *propuesta de desarrollo*, se ha visto efectivo.
|
|
|
|
|
|
|
|
También es recomendable, aunque ya esto depende de cada desarrollador, dejar las tareas más sencillas o con menos carga para estos días, pero en el caso de este proyecto, mirando con perspectiva, hubiese permitido probablemente que el tiempo de desarrollo de las tareas que se realizaron hubiese sido menor.
|
|
|
|
|
|
|
|
#### Comentarios en componentes comunes de Vue
|
|
|
|
|
|
|
|
A raiz del proyecto han surgido ciertos componentes que se estima que tienen una funcionalidad estándar para los proyectos en este framework. Para poder aprovecharlos, se ha establecido un formato tipo de documentación que permite conocer lo básico acerca del componente sin mirar el código.
|
|
|
|
|
|
|
|
Se ha encontrado bastante útil este tipo de comentarios puesto que, a la hora de utilizar componentes que se desarrollaron a finales del curso con motivo de las distintas asignaturas, se han podido reutilizar sin más necesidad que hacer uso de ese comentario. Incluir la **funcionalidad principal**, las **props** y los **emits** se ha visto suficiente para poder dar a conocer la interfaz de funcionamiento de los componentes.
|
|
|
|
|
|
|
|
#### Autenticación
|
|
|
|
|
|
|
|
Aunque mal planteada, la idea inicial era utilizar una base de datos externa (que se simula en la API), para la autenticación. Posteriormente, tras la investigación sobre este aspecto, se hace patente que la autenticación externa no se realiza de la forma prevista inicialmente, si no que se ejecuta siguiendo otro tipo de protocolo. Sin embargo, la estructura en la base de datos de aquellos datos más relevantes para los usuarios quedó aisalda de los datos a los que se accede. Es decir, las contraseñas y los correos de los usuarios se encontraban en una tabla y el resto de datos necesarios para la aplicación en otra.
|
|
|
|
|
|
|
|
De cara a la protección de los datos de los usuarios, esto se estima apropiado ya que el acceso a esa otra tabla se puede limitar mucho mejor en la API al estar separada, y sobre todo de una forma más sencilla y estructurada.
|
|
|
|
|
|
|
|
#### Testing
|
|
|
|
|
|
|
|
Durante las distintas *Sprint Retrospective* se ha observado que la definición de los test que se deben pasar a la aplicación es crucial para evitar que las estimaciones se desvíen en exceso de lo previsto. En concreto, ha habido dos motivos principales:
|
|
|
|
- Los casos de pruebas estaban incompletos: La combinatoria presente a la hora de mostrar distintos elementos hacía que definir cada uno de los casos distintos de test fuese complicado y por ello, se encontraron errores a medida que se avanzaba el desarrollo obligando a abrir nuevos issues o reabrir algunos.
|
|
|
|
- Daños colaterales: A pesar de que en algunas tareas las pruebas puedan estar bien definidas, hay otras tareas que pueden haberse realizado ya que se vean afectadas por el desarrollo. Si no se pasan de nuevo las pruebas a las tareas relacionadas, puede verse afectado el funcionamiento integral de la aplicación.
|
|
|
|
|
