Guión para la presentación de evaluación del Sprint 2

Guión preliminar por	Presentador	Tiempo

Killer Opener + Elevator Pitch

Buenas tardes, mi nombre es [NOMBRE] Suena el teléfono

• Tenía que ser ahora... Perdón profesor, pero esta llamada la tengo que coger, es de un cliente muy importante. Coge el teléfono
• Hola buenas, Harmony al habla, ¿en qué puedo ayudarle?
• ...
• ¡¿Cómo?! Muestra cara de sorpresa. Bueno, pero ¿estuviste volcando ya los datos en la aplicación?
• ...
• Buff, Menos mal. Perdóname, pero la verdad me pillas en un mal momento, te cuelgo y hablamos después. Adiós.

Bueno, pues me acaba de llamar un cliente que con la que ha caído estos días se les han mojado los datos que tenían escritos en papel. Gracias a Dios estuvieron volcando los datos en nuestra aplicación y no han perdido nada.

Pero bueno, sin más dilación, vamos a empezar con la presentación.

Figura 1. Portada de la presentación.

Somos Harmony y queremos traer la revolución al día a día de las ONG. Nuestra aplicación no es solo una herramienta, es un paso hacia delante en la ayuda social, reduciendo la carga administrativa y permitiendo a las ONG centrarse en lo que realmente importa: ayudar a quienes más lo necesitan.

Y no hacemos esto a pasos de ciego, conocemos el problema. Hemos hablado con ONGs y hemos visto cómo se sienten frustradas por la dificultad de mantener todos sus datos con métodos anticuados como hojas de cálculo de Excel y registros en papel. Y no solo eso, sino que también les consume tiempo que de otra forma podrían dedicar a sus seres queridos y a ellos mismos.

Figura 2. Contexto.

A día de hoy ya proporcionamos nuestros servicios a ACAT (asociación ciudadana de ayuda al toxicómano), que se dedica a ayudar a personas con adicciones, y a Cirio y Costal que reparte alimentos a familias en situación de vulnerabilidad. Ambas hacen de nuestra comunidad un lugar mejor, y queremos que más ONGs se unan a nosotros porque juntos podemos hacer mucho más, y hacedme caso cuando os digo que no conocéis las limitaciones de las formas de almacenar información de una ONG que se aferra a los métodos que antes usaban ACAT y Cirio y Costal hasta que tenéis un sistema en mano que hace cosas que ni siquiera sabíais que necesitabais.

Figura 3. Objetivos de harmony.

Desde Harmony, estamos comprometidos a llevar la gestión de nuestras ONG al siglo XXI, simplificando procesos, mejorando la comunicación interna y optimizando recursos para que puedan concentrarse en lo que realmente importa: ayudar a quienes más lo necesitan.

• Transición con lo siguiente: "Y ¿por qué confiar en nosotros?" (pasamos a la siguiente diapositiva)

Análisis de Competidores

Figura 4. Análisis de competidores.

Para empezar, cada ONG es un mundo, cada una tiene sus necesidades particulares y por eso no creemos que haya una solución única.

Nosotros hemos identificado dos empresas que ofrecen gestión de alimentos e inventario para ONGs, la primera es Stockio, una empresa española que proporciona un software para la gestión de inventarios y almacenes, pero no para la gestión de beneficiarios, (silencio) cosa que sí hace Pantrysoft además de la gestión de inventario, pero al estar basada en los Estados Unidos, no les garantiza a las ONGs españolas el cumplimiento de las leyes de protección de datos europeas.

De igual forma, estas empresas no ofrecen una solución que se pueda adaptar a todas las necesidades de cada ONG.

Figura 5. Herramientas open source.

Y por otra parte, existen una serie de herramientas open source que consideramos que podrían ser de utilidad para la gestión de alimentos y beneficiarios de las ONGs, como Django-CRM o CiviCRM, pero tras algo más de análisis hemos visto que están más orientadas a la gestión de clientes empresariales y que no se adaptan a las necesidades de las ONGs.

Y ¿en qué nos diferenciamos nosotros? Pues en que ofrecemos una solución que se adapta a las necesidades de cada ONG, esto significa que trabajaremos conjuntamente con ellas para lograr cumplir todas sus necesidades y que además es una solución open source, lo que permite a las ONGs tener un mayor control sobre la aplicación y poder adaptarla a sus necesidades en cualquier momento.

Story Board

Figura 6. Storyboard 1.

• Diapo 0 CyC: Nuestro 18º integrante AL nos ha preparado una pequeña historia para entender mejor el valor que ofrecemos.

Figura 7. Storyboard 2.

• Diapo 1 CyC: En frente de la sede de Cirio y Costal se encuentran varias personas dispuestas a recibir alimentos.

Figura 8. Storyboard 3.

• Diapo 2 CyC: Podemos ver a Homer recogiendo los alimentos que solicitó hace un par de días, cuando AL se dispone a buscarlos.

Figura 9. Storyboard 4.

Figura 10. Storyboard 5.

• Diapo 3&4 CyC: Tras 3 horas, AL sigue sin encontrar los datos que tenía escritos en algún papel.

Figura 11. Storyboard 6.

• Diapo 5 CyC: AL se da cuenta de que necesita algún tipo de solución para poder gestionar los datos de los beneficiarios de una forma más eficiente.

Figura 12. Storyboard 7.

• Diapo 6 CyC: Por suerte, un amigo de otra ONG le habla de Harmony.

Figura 13. Storyboard 8.

• Diapo 7 CyC: AL contacta con nosotros y se le hace un servicio a medida.

Figura 14. Storyboard 9.

• Diapo 8 CyC: AL y Homer están felices porque ahora ya no tienen estos problemas.

Figura 15. Storyboard 10.

Aspectos legales del proyecto

Figura 16. Aspectos legales del proyecto.

Tras este paseo con AL, vamos a entrar en temas más serios, en los aspectos legales de nuestro proyecto, y quiero comentar antes de empezar que nos hemos apoyado en la herramienta CLAUDETTE para redactarlo, tomando el feedback que considerábamos que aplicaba en nuestro caso.

Para esto, hemos hecho 2 divisiones de nuestro marco legal, el uso de nuestro servicio, y el uso únicamente de nuestro software.

Uso del servicio

Para esta en concreto se han definido tanto el Customer Agreement, el cual recoge todos los términos y condiciones a los que se somete un cliente al contratar un servicio de la empresa Harmony. Entre estos encontramos pagos y tarifas, acuerdos de nivel de servicio definidos en iTop, política de privacidad etc.

A su vez, también definimos un documento de Protección de Datos, en el que nos comprometemos a proteger la privacidad y los datos de los clientes y usuarios que contraten un servicio. Este reglamento se fundamenta principalmente en la LOPD,s LOPDGDD y el RGPD. (Acortaciones)

En caso de que alguien estuviera más interesado en este tema, podeis encontrar toda la información respecto a estos documentos en la sección “Legal” de nuestro docusaurus.

Without service

Por otro lado, si haces uso únicamente de nuestro software, te atienes a los términos en este caso no de nuestros términos y condiciones, sino de la licencia AGPL.

Análisis del TCO

Figura 17. Análisis del TCO.

Para el nuestro servicio hemos calculado un coste total de propiedad de unos 91.173€ (silencio). en un periodo de 2 año OUCH,

Pero bueno, vamos a analizarlo:

• El CapEx según nuestros cálculos compone un poco menos de la mitad de este coste, 40,000€. De aquí la mayoría del coste se va en el personal que contratamos, que son unos 39,000€, de los cuales 34,000€ durante el periodo de desarrollo, y el resto viene de los costes de material y licencias, que son unos 1,000€.
• El OpEx por otra parte son unos 42,000€, la mayoría se va en el personal que necesitamos para cumplir con las legislaciones de protección de datos como GPDR y el SLA de atención al cliente, que son unos 40,000€, y el resto viene de los costes de despliegue, que son unos 1,000€.
• Además hemos añadido un fondo del 12% para planes de contingencia. Porque esperamos que pueda haber desviaciones y es importante estar preparados para ello.

Quiero destacar que los costes OpEx están sujetos a cambios, ya que dependemos del precio que pongan servicios de terceros como, por ejemplo, pasa con el hosting del código y la integración continua, que aunque actualmente son gratuitas debido a la naturaleza Open Source de nuestro proyecto, si cambiara a tratarse como proyectos closed source, el TCO de estos dos primeros años aumentarían en 57€.

De igual forma estimamos que no necesitaremos durante este tiempo una licencia de sendgrid para más de 100 emails diarios por la naturaleza de nuestro servicio, pero si hiciese falta, el coste añadido sería de 480€.

ROI

Figura 18. Retorno de la inversión.

Y bien, 91.000€ no es poco dinero, nos hace falta estar seguros de que vamos a recuperar esta inversión. Por ello hemos hecho un análisis tratando de predecir el crecimiento de nuestra base de clientes y el retorno de la inversión en situaciones optimistas, pesimistas y más probables.

Como veis en la gráfica, los costes son un poco más grandes al principio, en el periodo de desarrollo, pero conforme entramos en producción bajan, a la vez que aumentan los ingresos. Según hemos calculado nuestro servicio generaría más de lo que cuesta a partir de los 30 meses aproximadamente tanto en el escenario optimista como en el más probable, y en el pesimista, que asume un crecimiento prácticamente nulo de clientes, no parece que vayamos a recuperar la inversión.

Seguimiento de costes + burndown

Y ya que vemos aquí en los primeros cuatro meses el costo del desarrollo, vamos a hacer un poquito de zoom ahi para ver cómo vamos:

Figura 19. Seguimiento de costes.

La línea azul son los costes de los que estamo hablando, aquí representados de forma acumulativa, como vemos en un principio nos encontrábamos por encima de los esperado, pero en esta última semana se ve un descenso ya que estamos empezando a compensar este exceso de costes y así volver a la línea esperada.

Pero bueno, tampoco es una preocupación porque como vemos con la gráfica rosa, hemos completado más puntos de historia de lo que esperábamos, lo que significa que estamos avanzo bien y tenemos margen de maniobra para corregir estas desviaciones.

Figura 20. Burndown.

Mirando un poquito más de cerca el avance de este Sprint vemos en azul el burndown de puntos de historia ideal frente al real. Como vemos íbamos un poco atrasados por la mitad del Sprint pero finalmente nos recuperamos y conseguimos completar casi todas las historias que nos habíamos propuesto. Las que no se han debido a algún bloqueo que comentaremos más adelante. Cabe destacar que este burndown óptimo ha sido actualizado a lo largo del Sprint si se han producido cambios en la planificación o priorización de las actividades.

Equipo y estado del CA

Figura 21. Commitment Agreement Global.

Continuando con la temática del seguimiento veamos como va el equipo y el estado del CA.

OPCIONAL, SOLO SI HAY TIEMPO

Como recordatorio, nosotros medimos en este apartado 5 puntos principales: El cumplimiento mínimo de una dedicación de 10 horas semanales, compensables a través de un sistema de compensación de tiempo si una semana se echa más y otra menos tiempo, el respeto al horario de disponibilidad establecido, la realización de las tareas asignadas dentro de plazos o justificación de su retraso, y por ultimo la correcta aplicación del sistema de avisos.

FINALIZA OPCIONAL

Figura 22. Estado del CA.

Figura 23. Estado del CA.

A lo largo del proyecto este cumpolimiento ha sido excelente tanto a nivel general como individual, quitando alguna semana puntual en la que algún miembro hubiera recibido algún aviso por no cumplir con la cláusula relacionada con el cumplimiento de tareas o justificación de retrasos.

Especialmente este Sprint ha sido excepcional sin ninguna incidencia.

Demo

Figura 24. Demo.

Puesto que la última vez enseñamos solo el sistema de Cirio y Costal esta vez vamos a comenzar con el de ACAT.

Dar al play

Vamos a empezar con el inicio de sesión que es lo que te encuentras al entrar a la aplicación. De aqui nos vamos al listado de beneficarios desde donde podemos crear uno nuevo... o ver los detalles de uno ya existente.

Desde los detalles podemos también actualizarlo, finalizarlo o eliminarlo. Si lo finalizamos lo veremos tambien en el listado de beneficiarios finalizados.

Por otro lado podemos ver todas las intervenciones que se han hecho, crear una nueva y ver sus detalles. Así como, de nuevo, actualizarlas y eliminarlas.

Por otro lado podemos ver un listado de todos los usuarios con acceso al sistema y podemos crear usuarios nuevo. ACAT crea los usuarios ellos mismos y al ser un sistema cerrado habreis observado que no existia un registro.

También hemos añadido la posibilidad de recuperar la contraseña a través de un sistema de 2FA. Podemos escanear un qr con una aplicaicon como google autenticator y este código nos permitirá cambiar la contraseña o recuperarla en caso de olvido.

Vamos a enseñar también un poco de la aplicación de Cirio y Costal. En este caso en lugar de beneficiarios tenemos familias, por lo que al crearlas tambien tenemos que añadir a los miembros.

Igual que con ACAT al crearla se nos redirige a sus detalles y desde ahi podemos actualizarla, eliminarla y más.

Tambien si tuvieran entregas las podriamos ver y actualizar a la derecha.

Aunque nos gustaría enseñar más cosas, me toca cederle la palabra a [NOMBRE] para hacer un poco de retrospectiva de este Sprint.

Rendimiento individual del equipo

Figura 25. Rendimiento individual del equipo

Una vez ya hemos visto cuál ha sido el resultado de este Sprint, pasamos al apartado de retrospectiva. Comencemos con el rendimiento del equipo. Nosotros llevamos a cabo diferentes roles que se miden de forma diferente, para ello, cada fase realizamos encuestas entre personas con el mismo rol para valorarse entre sí (de forma anónima) y con esta puntuación y los puntos de historia realizados obtenemos la puntuación para un rol. Ésta por ejemplo es la fórmula de los desarrolladores, dónde se tiene en cuenta la calificación obtenida (c), los puntos de historia (hu) y el número de miembros (m).

Figura 26. Gráfica de rendimiento del Sprint 2

Con esta gráfica podemos ver cómo el rendimiento individual es bastante positivo en general, exceptuando algunas personas que han llevado a cabo tareas con menor complejidad o menor número de tareas (Aunque en general bastante bien).

Mejora del agendamiento

Figura 27. Calendly

Cómo nos recomendaron los profesores, hemos investigado posibles herramientas para programar de forma sencilla las reuniones. Calendly, es una aplicación que nos permite programar eventos y reuniones introduciendo únicamente nuestro horario de disponibilidad. En la imagen de la derecha podemos ver cómo al crear una reunión con gente con diferentes disponibilidades nos muestra únicamente las ventanas disponibles entre esas personas.

OPCIONAL, SOLO SI HAY TIEMPO (Además, nos permite concertar las reuniones en cualquier herramienta cómo discord y conectar el google calendar)

Análisis de la calidad

Figura 28. Análisis de la calidad

Aparte de mejorar el agendamiento, la mejora de la calidad de código desde el principio ha sido uno de nuestros objetivos. Durante las dos primeras fases de desarrollo hemos obtenido calidad A en todos los repositorios, lo que nos ha permitido mantener un código limpio y de calidad.

Figura 29. Gráfica del Sprint 2

Aun así, me gustaría mencionar algunas cosas, como por ejemplo la gráfica de evolución de problemas en el código, donde vemos que al final del Sprint 1 hubo una etapa en la que el código tenía algunos problemas debido al retraso en las tareas que hizo que no se pudiesen resolver estos problemas antes del sprint 2, aunque podemos ver cómo la semana siguiente se resolvieron, manteniendo la calidad en niveles óptimos.

Figura 30. Cobertura de tests

Sin embargo, la cobertura de los tests cómo podemos ver ha decaído un poco este segundo sprint, debido a que hemos decidido avanzar todo lo posible con la funcionalidad y testear únicamente el código de valor. Aun así, podemos asegurar que toda la funcionalidad realizada en este segundo sprint está cubierta.

Gestión de problemas

Figura 31. Gestión de problemas

Otro aspecto imporante durante el sprint ha sido la gestión de problemas. El único problema que hemos tenido ha sido el despliegue de la base de datos con postgresql, después de estudiar las opciones, se decidió hacer la migración a mongoDB. El objetivo de esta solución era reducir los costes y la complejidad del despliegue de la base de datos y tras haber realizado un análisis hemos conseguido reducir el coste aunque hemos tenido que replanificar algunas tareas debido a la migración. Por último, hemos calificado esta solución con un 3,5 sobre 5. Y os preguntaréis, ¿esta calificación de dónde viene?

Figura 32. Fórmula de calidad de la solución

Pues esa puntuación se obtiene mediante esta fórmula en la que tenemos dos factores:

• El beneficio neto de la solución
• Los recursos utilizados

Ambas son rúbricas del 1 al 5 que están detalladas en el docusaurus.

Changelog

Figura 33. Registro de cambios de ACAT en el sprint 2

Aparte de gestionar problemas, me gustaría comentar algunos de las funcionalidades que hemos implementado, para ello hemos realizado en cada repositorio una release con su changelog autogenerado cómo es el caso de ACAT. Para recoger los cambios significativos en este repositorio le hemos pasado a GPT el changelog y nos ha generado un resumen de los cambios más importantes (Mencionar por encima los de la diapositiva si hay tiempo).

Reloj del proyecto

Figura 34. Reloj del proyecto S2

Este es el reloj del sprint 2 en el que podemos ver que se han superado ligeramente el mínimo esperado, siendo la mayoría horas destinadas al desarrollo.

Figura 35. Reloj del proyecto global

Y este es el reloj global que está 300 horas por encima del esperado, debido a la migración de los documentos a docusaurus y al cambio a mongo, entre otras cosas.

Figura 36. Alberto.

Además, nos gustaría felicitar a alberto por haber resuelto durante este sprint tantos problemas de código de los que dependia la gente de frontend. Muchas gracias Alberto

Usuarios piloto

Figura 37. Usuarios piloto

Bueno, continuamos con los usuarios piloto y nuestra interacción este segundo sprint. Nuestros usuarios piloto son el G1 de mañana y las ONGs, destacando que además de estar contactados, informados e involucrados ya han firmado el CA.

Figura 38. Aspectos de mejora recogidos

En este sprint hemos recogido el feedbackd de nuestros usuarios piloto, lo hemos analizado y recogido en el registro de cambios, si escaneais el QR podréis acceder a ese apartado del docusaurus para consultarlo. La mayoría de cambios relacionados con algunos requisitos que no estaban del todo claros y con correcciones en la interfaz de usuario.

Figura 39. Calendario de Marzo

Este es el calendario de Marzo con la ventana en la que entregamos a los usuarios piloto nuestro servicio y el día de análisis de las solicitudes.

Figura 40. Calendario de Abril

Este es el calendario de abril (le hemos dado esta semana la app a los usuarios piloto).

Figura 41. Calendario de Mayo

Y este es el calendario de mayo.

Figura 42. Aspectos clave del CA G1

Una vez mencionado el calendario de feedback, los usuarios piloto del grupo 1 se han comprometido a cumplir algunas cláusulas, entre ellas: cumplir las deadlines y tener una comunicación fluida son comunes a los dos CA, y se diferencian del de las ONGs en que deben usar iTop, clockify y que en caso de que no nos guste el tipo de feedback que nos dan, se comprometen a cambiar de revisor.

Figura 43. Aspectos clave del CA ONGs

Y aquí los de la ONG que sólo deben probar el prototipo correspondiente a su ONG

Planificación del Sprint 3

Figura 44. Estado de las tareas del sprint 2

Ya sabemos cuál es el estado de los usuarios pilotos, ¿y el del proyecto? Aquí podemos ver el estado de las tareas del sprint 2. Todo hecho expecto:

• El uso offline de la PWA, que se ha pospuesto para priorizar terminar la funcionalidad principal.
• Los patch y delete de entrega de comida

Estas dos tareas se han replanificado al sprint 3

Figura 45. Tareas del sprint 3

Además de lo mencionado en la diapositiva anterior, estas son las tareas que se van a realizar en el sprint 3, priorizando las que más valor aportan al servicio.

Figura 46. Gant del sprint 3

Aquí podemos ver la creación inicial de las tareas del Sprint 3 en el tablero de frontend, si nos fijamos bien están incluidas las tareas de replanificación que hemos comentado anteriormente.

Uso de la IA

Figura 47. Uso de la IA

Y para ir terminando, comentar nuestro uso de la IA durante este Sprint que se mantiene similar al sprint 1, en el que usamos copilot y gpt para tareas de código (sobretodo copilot, aunque usamos menos la IA porque el core ya está desarrollado), gpt para tareas de documentación y removeBG para las imágenes.

Figura 48. Huella de carbono y alucinaciones de la IA

En nuestro caso comentar que no hemos encontrado información pública sobre la huella de carbono generada por la IA y por eso no hemos añadido estimación. Por otro lado, esta una de las alucinaciones de copilot que han sucedido frecuentemente en backend, siendo correcta la de abajo ya que los productos pertenecen a una línea de productos.

Cumplimiento de los apartados de la PPTX

Figura 49. Percepción de cumplimiento

Hemos cumplido todos los apartados requeridos y además nos gustaría añadir un apartado

Autoevaluación del Sprint 2

Figura 50. Autoevaluación de los sprints 1 y 2

Según la recomendación de los profesores, hemos realizado una autoevaluación detallada en el docusaurus para cada sprint en el que revisamos el cumplimiento de todos los criterios de evaluación y además añadimos una valoración de cada uno de estos criterios para poder ver en qué aspectos hemos fallado y en cuáles hemos destacado, generando una puntuación final para cada sprint. Cómo vemos, en este sprint ha habido una mejora general ya que hemos resuelto algunos problemas que teníamos en el sprint 1, cómo la dependencia con mockapi que al llegar al límite de peticiones dejó el despliegue en un estado inestable. La nota que hemos estimado en este sprint es de un 9,89.

Recomendación de Harmony

Figura 51. Recomendación de Harmony

Para terminar nos gustaría recomendaros que utiliceis el sprint 3 para mejorar la seguridad porque nosotros haciendo la revisión al grupo 1 pues conseguimos las credenciales de la api para verificar el email.

Landing Page y docusaurus

Figura 52. Fin

Muchas gracias por todo, aquí teneis nuestro enlace a la landing page.