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

Guión preliminar por	Presentador 1	Presentador 2	Tiempo
Antonio Rodriguez	Fran Benítez	Alberto Lopez	15 min

1. Negocio (~ 3 min 20 seg)

1.1 Killer Opener + Elevator pitch (~ 1.5 min)

30 segundos para que se presenten un poco los presentadores contando algo de ellos interesante.

[DIAPOSITIVA INICIAL CON NUESTRO LOGO] Somos Harmony y queremos traer la revolución al día a día a 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.

[DIAPOSITIVA ILUSTRATIVA DE UN CUADERNO Y FRUSTRACIÓN CON EXCEL] 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 a 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.

[DIAPOSITIVA CON LOS LOGOS DE ACAT Y CC] 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 este proyecto para hacer del mundo un lugar mejor.

[DIAPOSITIVA DE GRÁFICA HACIA ARRIBA] 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 que confiar en nosotros?" (pasamos a la siguiente diapo)

Competidores (Herramientas existentes) (~ 40 segundos)

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 entidades empresas que ofrecen gestión de alimentos e inventario para ongs, como 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, cosa que si hace pantrysoft ademas de la gestion de inventario, pero que 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.

y por otra parte existen una serie de herramientas open source que consideramos que podrían ser de utilidad para 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 es por ello que nosotros queremos ofrecer una solución más completa y adaptada a las necesidades de cada ongs.

TCO (Total Cost of Ownership) (~ 1 min)

Para el nuestro servicio hemos calculado un coste total de propiedad de unos 73.400€ en un periodo de 1 año, en el que el CapEx está compuesto por los costes de personal, material y licencias. Y el OpEx por los costes de despliegue, personal externo para el GDPR y el customer support, que se ha calculado teniendo en cuenta la prioridad y tipo de incidencias. También hemos añadido al coste Un fondo del 15% para planes de contingencia.

Con respecto a las licencias cabe destacar que actualmente tienen un coste 0€ debido a la naturaleza Open Source de nuestro proyecto, pero si la política cambiara hemos calculado un incremento de 26€ anuales.

Diapo de ROI

Además, tras un análisis exhaustivo de los costes anuales y del crecimiento esperado, asumiendo una curva de crecimiento lineal y unos gastos anuales fijos de poco más de 29.000€ anuales entre CapEx y OpEx, hemos calculado un retorno de la inversión de 5 años, en los cuales iremos incrementando el número de clientes en 5 cada uno y siendo el coste para las ONG de un servicio personalizado con atención al cliente de 230€ mensuales, parte de los cuales podrían ser subvencionados por ayudas para la digitalización de las ONGs.

El precio de nuestro servicio en contraste con PantrySoft que es el mas parecido es de 100€ más, justificado por una personalización del servicio, una inclusión de seguridad de datos, la falta de limites de usuarios concurrentes y un servicio completo, sin necesidad de pagar extra por lo que PantrySoft llama "complementos", que son mejoras del servicio base.

Tabla con gastos acumulados por años (1er año 73.400€, 2º año 102.586€, 3er año 131.792€, 4º año 161.015€, 5º año 190.239€)

Retorno acumulado por año (1er año 13.750€, 2º año 41.250€, 3er año 82.500€, 4º año 137.500€, 5º año 206.250€)

Commitment Agreement (~ 15 segundos)

Repetir tabla de la semana pasada

Como podéis ver, hasta ahora hemos estado ha cumplido con el acuerdo de compromiso con un buen porcentaje, aunque alguna vez se ha tenido que aplicar nuestra política de avisos, pero en general no encontramos ningún problema en el cumplimiento del mismo.

Prototipo (~ 2 min)

Incompleto todavía hasta el domingo o sabado noche

Ideas

• Demo pregrabada de la aplicación, explicando el estado del prototipo, que es funcional y que es "falso" (e.g. Clicar el botón de login y que te redirija del tirón a la página sin iniciar sesion)

Retrospectiva (~ 5.5 min)

Rendimiento (~ 1 min)

Para medir el rendimiento de los desarrolladores que han hecho estas tareas, y del resto de miembros hemos definido métricas específicas para cada rol Apoyarse en visual, para los coordinadores una nota dada por el equipo en base a una serie de aspectos predefinidos, para QA basada en los errores encontrados en tareas después de ser aprobadas, para los analistas basada en la puntuación interna de sus tareas y para los desarrolladores en base a la calidad y complejidad de las tareas, para lo que también usamos puntos de historia.

Finalmente hacemos una media de los roles desempeñados por una persona para sacar su nota esta semana.

Pasar a diapo con valores anónimos (Excepto miembros con mayor puntaje)

Aquí podemos observar la puntuación de los diferentes miembros del equipo

Pasar diapo a una con gráfico de excel de ronald a completar con las notas

Y con una gráfica así podríamos ver la evolución de los miembros de nuestro equipo, que nos ayuda a juzgar si una persona se esfuerza continuamente, si mejora, o si empieza a fallar. Y esto es importante saberlo porque nos puede ayudar a identificar problemas interpersonales y de motivación dentro del equipo.

Automatización de la calidad (~ 1 min)

Ya solo nos falta medir la calidad de lo que estamos produciendo, y para ello usamos Codacy por una parte, que nos analiza el código de manera automática en las distintas ramas y nos avisa si no seguimos los estándares de calidad del código.

Pasar a diapo con valores de codacy

Con codacy estamos midiendo tanto la cobertura de código como haciendo un análisis estático del código, y nos ayudamos de github actions para bloquear o permitir el merge de una rama si superan o no los estándares de calidad. Más concretamente hemos establecido una cobertura mínima del 80% para cada feature y un límite de code smells adicionales por cada una.

Pasar diapo

Por otro lado también integramos Bluejay, en este caso en los repositorios de backend y frontend de CyC para que nos ayude a medir y analizar el uso de buenas prácticas de manejo de incidencias e integración de características en ambos repositorios.

Pasar a diapo con valores de bluejay

Con bluejay podemos medir que el flujo de las tareas sea de Todo, a en progreso creando una rama, a revisión con un pull request, y a done con un merge. Tambien nos ayuda a ver quienes participan en la revisión de pull requests, si hacen comentarios positivos o negativos, si se aceptan finalmente o se rechazan, o si todo lo anterior sigue los estándares de nomenclatura establecidos.

Diapo con stats

Y de aqui podemos ver que en el caso de CyC se cumplen todos los estándares que se han podido medir hasta el momento, mientras que en backend tenemos que mejorar en relacionar las PR con los issues.

Problemas y soluciones (~ 2 min 50 seg)

Y a pesar de estar midiendo todo esto, aveces se nos escapan cosas y durante este primer Sprint hemos tenido problemas con la comunicación y planificación, que nos han generado los siguientes problemas:

Fotos de Al como apoyo

Herida 1: "Congelado"

• Durante la planificación del Diccionario de la EDT AL no se tuvo bien en cuenta las dependencias entre las tareas de backend y de frontend, lo que llevo al equipo de frontend a congelar el progreso de sus tareas. Tras una reunión extraordinaria se propuso bien replanificar las tareas de frontend, o bien usar MockAPI para simular llamadas a la API de backend. Como la segunda opción suponía menos replanificación y permitía continuar el trabajo inmediatamente, decidimos ir con esta opción.

Herida 2&3: "Pierna rota por falta de coordinacion"

• Por otra parte durante la semana 1 del Sprint 1 AL se reunió con ACAT y CyC para repasar los requisitos que habíamos definido y aclarar dudas. Durante esas reuniones se recogieron cambios en el modelo de datos que backend implementó, pero que no comunicó a frontend de manera correcta, lo que llevó a conflictos entre lo que frontend definía en sus formularios y vistas de detalles y lo que backend estaba haciendo.

• Este problema viene también acompañado de un segundo a causa de fallos en la comunicación nuevamente: Frontend esperaba tener versiones de la API desplegadas para poder conectar backend en entorno de desarrollo, y backend tenía entendido que la API se iba a desplegar localmente para el desarrollo y no hacía falta en staging con urgencia. Esto llevó a que frontend no pudiera probar sus cambios en un entorno real y el trabajo se retrasará sustancialmente.

• Para solucionar estos últimos problemas se hizo una reunión urgente con un representante de frontend, uno de backend y un coordinador a modo de mediador para aclarar malentendidos, establecer nuevas tareas para solucionar los fallos, revisar los procesos de comunicación y establecer un "vigilante", que tendrá como responsabilidad asegurarse de que la comunicación entre ambos equipos sea fluida y que cualquier cambio que conlleve a una dependencia entre ambos equipos sea comunicado de manera inmediata.

Herida 4: "Estrellitas como de confusión, mareado, por ser difícil encontrar lo que se quiere"

• AL también sufrió a principios de semana mareos y confusión al hacerse exponencialmente difícil con cada semana que pasa encontrar la documentación que necesitaba para hacer su trabajo entre la masa de documentos en GDrive, por lo que se ha empezado a transicionar la documentación a docosaurus, donde es mucho más fácil navegar y hacer búsquedas para encontrar la información que necesitamos a veces y no está en un solo documento.

Esto nos viene genial para hablar también del estado de los riesgos, y es que con respecto a la semana pasada hemos mitigado por el momento el riesgo en el cambio de requisitos por parte del cliente gracias a una replanificación de los Sprint 2 y 3, pero con respecto a otros las cosas no han ido tan bien. Por una parte han entrado en advertencia los riesgos de una mala definición de requisitos, por el conflicto que hemos comentado antes del modelo de datos, y el riesgo de retrasos en entrega debido al retraso de tareas durante este Sprint. Por último la semana pasada ya teníamos en advertencia el riesgo de fallos en la comunicación, y durante esta semana ha empeorado, sin entrar en estado grave ya que las medidas que hemos tomado han estado surtiendo efecto en los últimos días.

Reloj de avance del proyecto (~ 40 min)

Cuando este ready ponerlo aqui

Al inicio del Sprint 1 teníamos una diferencia de 170 horas entre el tiempo planificado y el real, principalmente debido a la mala planificación y estimación de la complejidad de las tareas, acompañado con problemas de comunicación interna que nos obligó a rehacer muchas tareas, y al tiempo que se tuvo que dedicar a la comunicación con el cliente.

Actualmente nos encontramos con una diferencia de X horas, Y de las cuales Y durante este Sprint, debido a problemas de comunicación que de nuevo nos han llevado a dedicar más tiempo del esperado a algunas tareas, y por tanto al Z% del reloj del proyecto.

Planificación (~ 2.5 min)

Diapo parecida a la semana pasada con los iconos en color, blanco y negro y porcentaje de completitud

Por otra parte con respecto a lo que teniamos planeado hacer este Sprint y los proximos hemos hecho algunos cambios que corresponden a nuevas necesidades y algunas tareas que si bien no se han completado a tiempo, el esfuerzo requerido para terminarlas es mínimo.

Durante el primer Sprint habiamos planeado desarrollar el:

• Alta de usuarios administradores
• La gestion de beneficiarios de ACAT (listado, creacion, detalles)
• Gestion de familias y personas para CyC.
• Gestion de citas para ACAT y alimentos para CyC
• Y una primera implementacion de los pipelines de despliegue e integracion continua.

Hemos completado la mayoria de estos módulos al 80% o mas, a excepcion de la gestion de beneficiarios de ACAT que muchas cosas han quedado en fase de revision al final del Sprint (Si cambia esto para el lunes cambiarlo en el discurso)

Usar el diagrama de Gant de Kenobi

Para el Sprint 2 inicialmente habiamos planteado la:

• Exportación de datos a una hoja de cálculo.
• Un sistema de sincronización para usar la aplicacion sin conexión.
• Hacer la aplicacion responsive para que se pueda usar en dispositivos móviles.
• Cubrir funcionalidades que no se hubieran podido completar con anterioridad
• Gestión de entrega de alimentos: Creación, listado y consulta de entregas de alimentos.

Y a esto hemos añadido una serie de tareas en base a nuevas necesidades y los problemas que hemos comentado antes:

• Por una parte hemos añadido una tarea de gestión de endpoints y unificación de funcionalidades en backend y frontend, ya que algunas cosas siguen desconectadas.
• Recuperación de contraseña vía email,
• Funcionalidad de paginación junto a busquedas y filtros en listados.
• Registrar nombre completo y alias de los beneficiarios de ACAT
• Y rectificar los fallos identificados en el modelo de datos durante este Sprint.

Por último el plan del Sprint 3 es mas reducido, por una parte por que esperamos que haya nuevas necesidades por parte de las ONGs, y por otra parte por que sabemos que puede ser que descubramos algun problema con los modelos de datos que todavia no conocemos. Esto pasa por que las ONGs no tienen claro que necesidad tienen exactamente, y a veces nos dan el visto bueno y despues descubrimos que faltaban datos por añadir a algun modelo.

• Por un lado contemplamos comenzar con el plan de marketing, que no pondremos en marcha hasta mas adelante pero queremos tenerlo listo para entonces
• Por otro lado queremos añadir un modulo de estadisticas sobre los datos que las ONGs guardan en el sistema, ya sea con una dashboard o de otra forma. Esto nos comunicarion que seria util por que de vez en cuando tienen que sacar datos para entregarlos a ciertas administraciones.
• Despues tambien queremos reforzar la seguridad del sistema restringiendo todas las operaciones a usuarios identificados y encriptando los datos que sean vulnerables.
• Y por ultimo como ya he dicho dejar margen para hacer cambios basados en errores o feedback de nuestros usuarios piloto.

Usuarios Piloto (~ 45 seg)

Matriz de contactados/no contactados, informados/implicados

Ahora bien, conforme vamos avanzando en el proyecto nos es necesario tener personas que prueben nuestra aplicación y nos den feedback, y para ello contamos con usuarios piloto ya establecidos, un miembro de ACAT, un miembro de CyC y un estudiante de último año de ingeniería del software. Los dos primeros probaran la aplicación desde un punto de vista del uso diario, mientras que el estudiante nos podrá ayudar a identificar problemas que quizás los otros no ven a simple vista.

Para manejar estas relaciones tenemos un plan de contacto periódico, a través del cual cada semana se le mandará un formulario junto a unas instrucciones para probar nuevas características o revisitar características mejoradas. Durante este primer Sprint hemos estado en contacto con ellos, y ahora que tenemos desplegada una primera versión del sistema hemos comenzado a enviarle estos primeros formularios, y aún esperamos sus respuestas.

Además de esto tendremos abierto en todo momento un portal de incidencias con iTop, donde podrán reportar cualquier problema que encuentren o solicitar nuevas características.

Diapo con el tema del TTR de alvaro gonzalez

Incidencias manejaremos en distintos plazos segun su importancia y urgencia.

Uso de la IA (~ 30 seg)

Durante este Sprint hemos usado sobre todo herramientas como Copilot o ChatGPT para escribir código, entender librerías mejor y más rápido, testear funcionalidades y arreglar fallos. En total estimamos un ahorro de X horas (Reportadas 5 hasta el momento)