Skip to main content

report

Imagen 1Imagen 2

Ingeniería del Software y Práctica Profesional - Universidad de Sevilla
#

BERMEJO SORIA, CARLOS

CASAL FERRERO, RUBÉN

DOMÍNGUEZ RUIZ. ANDRÉS

DOMÍNGUEZ-ADAME RUIZ. ALBERTO

FERNÁNDEZ CASTILLO, JAVIER

GALLARDO MARTOS, DANIEL

HERRERA RAMIREZ, ISMAEL

IZQUIERDO LAVADO, MARIO

MATEOS GÓMEZ, FERNANDO JOSÉ

MERINO PALMA, ALEJANDRO JOSÉ

MONTERO MARTÍNEZ, FRANCISCO JESÚS

LÓPEZ MOYANO, ROCÍO

OTERO BARBASÁN, MANUEL

VILAPLANA DE TRÍAS, FRANCISCO DAVID

ZARZUELA REINA, CARLOS

Entregable: S3#

Grupo 01 (Mañana) - IT Talent#

Control de Versiones

VersiónFechaAutorCambios
v1.018/02/24Paco, Fernando, IsmaelDocumento inicial
v2.026/02/24PacoCambio en el formato y adición del contenido de la 3a semana
v2.103/03/24PacoAdición de contenido de la 4a semana
v2.622/04/24PacoAdición de contenido de la 8a y 9a semana

Resumen del documento#

En este documento se especifican las contribuciones a la base de conocimientos de la asignatura disponible en este enlace. También se recogen las acciones que se han tomado teniendo en cuenta el feedback proporcionado de una semana a otra.

Índice

1. Contribuciones 4

Feedback del grupo 1 4

Feedback general 7

2. Acciones de consolidación 12

Semana 1

Semana 2

Semana 3

Semana 4

Semana 5

Semana 6

Semana 7

Semana 8

Semana 9

1. Contribuciones

Para las contribuciones se llega a un acuerdo de que cada semana será un grupo el encargado de recoger todo el feedback general de esa sesión y desplegarlo en la página https://bgcc.vercel.app/. Pero cada grupo tendrá como encargo semanalmente subir el feedback de su propio grupo, además de revisar el general en busca de posibles carencias en este.

Feedback del grupo 1#

  • Semana 1
  1. Las diferencias con el resto de competidores deben quedar suficientemente claras. Distinguir la “puesta en marcha” del resto de costes, ¿Cuál es el TCO?.
  2. Tener en cuenta los costes de la plataforma (p.e: operaciones), añadir planes sobre qué hacer en caso del aumento o disminución de usuarios.
  3. Se deben identificar las responsabilidades (están bien hechos los grupos) para cada grupo.
  4. Explicar cuál ha sido el proceso y criterio de búsqueda con los competidores.
  5. Evitar que sobre demasiado tiempo sobre todo si se puede profundizar en otros temas como la búsqueda de competidores.
  6. Evitar permanecer demasiado tiempo en una diapositiva o dejar explicación sin soporte visual, hace complicado seguir la presentación.
  7. Relacionar entre sí las matrices DAFO p.e: Amenazas vs Fortalezas… concretamente: 1ºA, 2ºF, 3º D, 4º O
  8. No son preferibles las estructuras jerárquicas con jefes y planificaciones. Son preferibles roles claros.
  9. Hay que hablar la base de conocimientos común.
  10. Tratar de homogeneizar las fotos de los participantes, que no tengan fondos muy diferentes.
  11. En los costes no poner los céntimos en la presentación, no es necesario ese nivel de detalle, en vez de 61.120,60€ poner 60k.
  12. Tratar de mantener un volumen de voz alto.
  13. No hacer preguntas al público.
  • Semana 2
  1. Hay que comenzar las presentaciones de manera clara con un “Impacto” inicial. Importancia de los “Killer openers”. (Hay una píldora que lo trata)
  2. Dar gran protagonismo a los casos de uso core, la idea de negocio y los mockups.
  3. Si se comparan competidores o herramientas similares se debe hacer hincapié en el elemento diferenciador.
  4. Si existen alternativas gratuitas al comparar competidores se debe justificar qué provocaría el cambio/paso a nuestra herramienta.
  5. Si es un elemento el que nos diferencia de la competencia, el pricing debería ir enfocado a este.
  6. Las promesas no deben ir al final, si no al inicio para usarlas como enganche para el público. Los mockups al final
  7. Cuando se dicen riesgos debe estar claramente identificado de qué manera podría pasar y cómo se solucionaría con detalle. (Por ejemplo, si uno es falta de conocimiento y se propone una formación, especificar la duración de la misma).
  8. Al comentar el commitment agreement, se deben exponer posibles problemas de equipo que ejemplifiquen. (Por ejemplo, si alguién no tiene una tarea tiempo, ¿Qué va a pasar?)
  9. Promover y mostrar la evolución del commitment agreement además de medir cómo se cumple.
  10. El TCO debe estar expresado de manera mensual no anual.
  11. Al exponer un riesgo es importante describirlo como un evento que puede ocurrir y describir los daños o pérdidas que causaría.
  12. Si se expone un riesgo, se presenta la solución por delante.
  13. Los análisis de costes son más inteligibles en forma de tabla.
  14. Los costes de herramientas y/o licencias de pago (por ejemplo github) deben ser tenidos en cuenta. Si es un servicio gratuito se debe exponer la existencia de un plan si este deja de serlo.
  15. Dejar claro que TODOS los integrantes han firmado el commitment agreement.
  16. No sentarse en la mesa para exponer.
  17. Un fondo negro dificulta la lectura.
  18. Uso de fuentes anchas y grandes.
  19. Al proponer precios debe quedar claro los beneficios que se están sacando (TCO).
  20. Siempre tener en cuenta el feedback de semanas anteriores al exponer. Marcar con una “F” las diapositivas que hacen referencia a este feedback.
  21. Evitar el uso de iconografías sin descripción en la comparación con otras empresas.
  22. Dejar claro que el uso de RRSS para el registro es opcional, nunca se pretende ser intrusivo en la vida personal del candidato, lo último que buscamos es perturbarlo con estos análisis.
  23. Dar mayor protagonismo a los mockups, casos de uso core y la idea de negocio.
  24. Hay que asumir los costes de github y tenerlos en cuenta. Si asumimos que es gratuita la licencia, ¿Qué pasaría si no? ¿Cuántas github action usaremos al mes?
  25. Se debe dejar claro de dónde sale el cálculo de precios y cuál es el beneficio que se saca de estos.
  • Semana 3
  1. Si se realiza un Killer Opener, este debe ser corto. Si se demora demasiado deja de ser efectivo.
  2. Situar la marca de feedback en la parte superior de la presentación.
  3. Al presentar los mockups realizar zoom cuando se haga referencia a partes concretas que no sean legibles al fondo de la clase.
  4. Es importante “afilar” los argumentos, sintetizar de manera que quede solo lo esencial.
  5. Al comparar con los competidores hacer énfasis en los puntos que mejora nuestra aplicación.
  6. Dejar claro el estado de la comunicación con los usuarios pilotos.
  7. Dejar claro el versionado que se usará en la gestión del código.
  8. Tener una gestión de la documentación similar a la del código con github. Por ejemplo, la presentación debería subirse como una pull request con todo el grupo como revisor.
  9. Se debe dejar claro que la presentación ha sido revisada y escuchada por todos los miembros del equipo y que estos han aportado su feedback.
  10. Si se han aplicado medidas para solucionar un problema hay que plasmar, evaluar y medir cómo de buenas han sido estas.
  11. Tener claros y plasmar las metas y objetivos de cada sprint.
  12. No quejarse NUNCA en medio de la presentación.
  • Semana 4
  1. No suspirar a lo largo de la presentación, da sensación de agotamiento de lo que se está contando. Aclarar y enlazar el Killer Opener con el inicio y el resto de la presentación.
  2. Falta claridad en el TCO. Se necesita definir un marco de tiempo (time frame) y una capacidad de demanda nominal para comprender mejor cómo se comportará el sistema en diferentes condiciones de uso, en resumen, cómo escalará. No solo se trata de cuántos usuarios pueden usarlo al mismo tiempo, sino también de cuándo y con qué nivel de demanda.
  3. Hablar en profundidad de nuestra gestión de la documentación, mostrar el versionado de documentos que se lleva internamente.
  4. En la presentación deben quedar claros los análisis del rendimiento y los límites operativos de github (github actions) para justificar el plan que necesitamos. Por ejemplo, cuánto tarda en evaluar a X usuarios para formar un grupo.
  5. La tabla de TEAM PERFORMANCE está bien, no cambiarla demasiado, pero le ha faltado la performance individual.
  6. Faltan gráficas y métricas del rendimiento por cada integrante del equipo (anónimo).
  7. Las métricas del rendimiento debe ser capaz de comparar cada miembro del equipo y los datos obtenidos deben ser cotejados para evaluar al final de cada sprint. Para los que programan es sencillo; nº de commits… Pero ¿Cómo se está midiendo el rendimiento de la persona que coordina?
  8. El DAFO ya no merece la pena incluirlo en la presentación.
  9. Diferencias entre gitflow y goldenflow y decir cual nos merece la pena usar.
  10. El número de usuarios que necesitamos para mantener la aplicación debe tener porcentajes con respecto al número de personas en el sector en Sevilla por ejemplo.
  11. Pensar en si es mejor una DEMO grabada o en directo.
  12. Marcar más el reconocimiento que se dice que se tiene sobre el CA. Poner un pódium con los nombres.
  • Semana 5
  1. Eliminar la captura del formulario, no es legible.
  2. Falta un Elevator pitch claro.
  3. Cambiar MPV por MVP.
  4. Tener una demo grabada.
  5. Para en la demo empezar por lo más importante, no el login.
  6. Demasiados datos en el TCO, hacen complejo entender y seguir la presentación.
  7. Las estimaciones a futuro (BUDGET) NO pueden ser lineales, datos como el número de usuarios deben hacer fluctuar los datos.
  8. Evitar colores claros sobre blanco en los gráficos y poner etiquetas en cada eje.
  9. Hacer poner la clave de github (API) al cliente es arriesgado si la empresa es la que tiene que hacer los análisis. Sobre todo si el cliente ya usa su api para otras cosas, el requisito de uso es demasiado alto, no es profesional.
  10. Estimar el número de peticiones que se deberían hacer en total y decir cuánto nos costaría con la responsabilidad de usar la API nosotros.
  11. Deberíamos haber hecho el análisis de la capacidad de peticiones, para estimar el nº de peticiones óptimo para los clientes en los diferentes planes de subscripción.
  12. Tendríamos que hacer el análisis económico de las peticiones que harán los clientes.
  13. Estimaciones de usuarios (optimistas, pesimistas, realistas) más simple, realizar análisis PERT.
  14. Realizar un pseudo gantt en la retrospectiva del sprint con las tareas que se han realizado en este.
  15. Incluir documentación en el repositorio o en un docusaurus.
  • Semana 7
  1. Evitar uso de fuentes oscuras sobre fondos oscuros.
  2. En la DEMO hay letras muy pequeñas, por lo que es necesario hacer uso de zoom en el video.
  3. Pensar en usar colores más claros para la DEMO únicamente, manteniendo los colores en la aplicación original.
  4. Storyboards en blanco y negro poniendo en color lo que queramos destacar.
  5. Los presupuestos expuestos están demasiado centrados en el desarrollo.
  6. La grafica del Budget sobra con la otra grafica de costes y beneficios.
  7. Revisitar el tema de las métricas que se está usando para medir el rendimiento. Separar el número de horas en el rendimiento, no confundir con el esfuerzo.
  8. Revisar los usuarios pilotos que no responden y acotar los que sean menos probables.
  9. El elevator pitch debe estar más presente. No solamente como una frase introductoria. (como musclemate, qué ofrecemos nosotros que otros no)
  10. En el storyboard del empresario buscar destacar la característica que nos diferencia (le hagan falta 5 personas para YA con unas especificaciones CONCRETAS).
  11. Dar coherencia a la presentación de manera que si mostramos a unos actores en el storyboard, usarlo como recurso a lo largo de la presentación, en por ejemplo en la demo…
  12. Validar los correos electrónicos mediante alguna API y añadir los costes de esta al Opex (No estoy seguro de que correos se refería, si a los de las empresas o a los usuarios de la aplicación en general).
  13. Hacer gráfica de puntos de historia vs tiempo consumido.
  14. Para medir la eficiencia de los tests, contar en base a los fallos que saltan con estos. También es buena practica poner los fallos a posta para que estos salten.
  15. Capex, costes de desarrollo, mostrar multiplicador por cada rol (sobre la hora de servicio mínima) (Para este parto sobre los comentarios de Müller de Ocial, destacó especialmente esta diapositiva).
  • Semana 8
  1. En diapositivas que contenga gráficas se debe parar un mínimo para explicarlas.
  2. Uso de datos y descripciones realistas en las demos.
  3. Cuidar formatos en las diapositivas que hagan las letras más pequeñas, pueden hacerlas ilegibles.
  4. Siempre hacer algún comentario o explicar brevemente los análisis del ALN.
  5. Si se da un problema siempre se debe especificar el estado del mismo.
  6. Evitar empezar la retrospectiva de un sprint con los problemas que ha habido durante este.
  7. Si falla algo en un sprint, al final del siguiente hacer especial interés en que se ha tenido en cuenta y se ha realizado alguna medida con métricas.
  8. Añadir el numero de refinamientos en las IAs.
  9. No usar encabezados de “BIENVENIDO A…” con una descripción de los servicios en la aplicación, eso sería contenido de la Landing Page.
  10. Evitar moverse demasiado a la hora de realizar la presentación, hay que buscar un punto medio entre energía y serenidad, también en ritmos de presentación.
  11. Mostrar los análisis del código en vivo es una buena práctica.
  12. A mayor número de clientes los costes de mantenimiento deben subir.
  13. Añadir una matriz con el esfuerzo en horas y el rendimiento con nuestra fórmulas y los integrantes en ella.
  14. Se debe tener cuidado de no fomentar trabajar menos con la gamificación en el desarrollo.
  15. Las funciones listadas con botones queda poco profesional se debe buscar meter gráficas y otras disposiciones.
  16. Siempre se deben exponer los problemas que ha habido y se han solucionado, los que están por solucionar y las soluciones propuestas.
  17. Si se muestran gráficas se debe como mínimo hacer alguna conclusión de esta.
  18. La recepción del feedback de los usuarios pilotos debe ser lo antes posible para poder ejercer los cambios necesarios antes del entregable.
  • Semana 9
  1. Cuidar la iluminación del anuncio así como la vocalización y velocidad del diálogo.
  2. ¿SON LOS CORRECTOS USUARIOS POTENCIALES? Hay que cambiar el enfoque, la búsqueda de trabajo es constante
  3. Añadir diapositivas de apoyo para el Customer Agreement (Diapositiva: SLA + TOS).
  4. Especificar los datos de la diapositiva Capex vs Opex. Y añadir datos de usuarios empleados que se registrarían en la aplicación.
  5. Pararse brevemente a explicar qué es cada cláusulas del Commitment Agreement.
  6. En la DEMO pararse en las funcionalidades core y no mencionar la edición/eliminación de perfiles.
  7. Al subir el ritmo del diálogo se deja de seguir el ritmo de la presentación y se pierden conceptos.
  8. Para cada gráfico (a partir de la 37) o dato que se enseñe, prepararse una frase que resuma el gráfico (p.ej: ha habido un aumento del rendimiento del 4%) o plasmarlo en la misma diapositiva.
  9. La gráfica de rendimiento individual no refleja bien la diferencia con respecto de una semana a otra, si se quiere plasmar eso habría que cambiar la forma de enseñarlo.
  10. La DEMO debe estar más orientada al anuncio, que Javi salga en el anuncio como jefe y luego salga igual en la foto de perfil de la DEMO.
  11. Se debe plasmar si los tests están siendo efectivos o no (inventarse fallos o realizar test que se sabe que van a fallar).
  12. Añadir el numero de refinamientos necesarios en el report de las IAs.
  13. Meter acciones de consolidación en la Base de Conocimientos
  14. Tener un apartado de la DEMO en el Docusaurio (link a Youtube…).
  15. Añadir apoyo para los SLA y ToS (Customer Agreement)
  16. Incluir los ToS en el registro.
  17. Añadir el feedback específico nos han dado los Usuarios Pilotos. A cada feedback que se mencione que han aportado los usuarios piloto añadir la prioridad que se le ha asignado.
  18. A Muller le gustó que: Para cada problema: OPEN, NOT SOLVED, IN PROGRESS, SOLVED
  19. Muller mencionó que es buena practica realizar pruebas de carga que muestren cuantás peticiones son necesarias para agotar los créditos de Google.
  20. A Muller le gustó: Segmentación de mercado de cara al proyect launch (píldora teórica).
**Feedback general**

Presentadores

“Segmentar las ideas” de tal manera que queden claros los mensajes clave.

Evitar permanecer demasiado tiempo en una diapositiva o dejar explicación sin soporte visual.

Dar énfasis a ciertos puntos críticos de la presentación para mantener la atención del público, cambiando la entonación para que no sea demasiado monótona.

Aunque se realice un Killer Opener, los presentadores deben recordar decir sus nombres.

Recordar que como presentador no recae en uno las responsabilidades del grupo al completo, disfrutar de la presentación.

Aclarar y enlazar el Killer Opener con el inicio y el resto de la presentación.

No olvidar que es el moderador (no nuestro grupo) quien lleva el conteo del tiempo (fuera de evaluación) de las presentaciones.

Cuidar y evitar las muletillas.

No suspirar a lo largo de la presentación, da sensación de agotamiento de lo que se está contando.

Siempre cuidar y tener claro el hilo de la presentación. Debe de haber coherencia entre los puntos y no dejar conceptos sueltos.

Presentación

Tratar de homogeneizar las fotos de los participantes, que no tengan fondos muy diferentes.

Las demos de los prototipos se deben ver bien, hacer zoom si es necesario.

Evitar letras blancas sobre colores claros.

Si hay datos en el tiempo (días) poner como apoyo visual un calendario.

Se debe ser coherente lo que se refleja en la diapositiva con lo que pone en el título.

Evitar sobrecarga en las presentaciones, buscar la simplicidad y la correlación entre diapositivas.

Marcar más el reconocimiento que se dice que se tiene sobre el Commitment Agreement. Poner un pódium con los nombres.

Usar recursos en la presentación como líneas o subrayados para corresponder con lo que se dice.

El DAFO ya no merece la pena incluirlo en la presentación.

Pensar en si es mejor una DEMO grabada o en directo.

Indicar con triángulos hacia arriba o abajo cuando haya habido rendimiento positivo o negativo en la retrospectiva.

Siempre debe haber una transparencia con la productividad por miembro del equipo (horas).

Si se dicen las tareas que ha hecho cada subgrupo deben ir acompañadas de un diagrama de gantt simplificado o similar en el que se vean para cuando estaba planificada cada una.

No meter una imagen de un QR si no es funcional o al menos aclarar que no lo es.

No basta con mostrar los problemas que ha habido durante la semana de trabajo, se debe mostrar siempre el análisis de riesgos inicial.

No mezclar la retrospectiva con la autoevaluación.

Debe quedar reflejado en la presentación que cuando no se llega el trabajo planificado se ha incumplido alguna cláusula del Commitment Agreement.

Deben quedar claro los responsables de una tarea.

En la presentación deben quedar claros los análisis del rendimiento y los límites operativos de github (github actions) para justificar el plan que necesitamos. Por ejemplo, cuánto tarda en evaluar a X usuarios para formar un grupo.

En la autoevaluación debe haber un análisis con métricas y números claros.

Siempre que se muestren problemas en el trabajo en equipo en la presentación, se mostrarán las medidas que se tomarán para solventarlos con las métricas con las que se medirá la eficacia de las respuestas.

A cada sprint siempre se debe mostrar la planificación o re-planificación de los próximos sprints.

Se busca una mejora de la síntesis cada semana, no se deben eliminar conceptos de una a otra.

Mantener siempre una diapositiva con la Landing Page con QR aunque sea en la última diapositiva.

Siempre incluir los estados de la comunicación en la gestión de usuarios pilotos.

Análisis de competidores

En vez de situar competidores o elementos en lista (de ventajas y desventajas), realizar un mapa y agruparlos por similaridad para evaluarlos de esta manera.

Pese a estar en la fase de desarrollo el análisis de competidores siempre debe estar presente en las presentaciones.

Para un análisis de competidores más sintetizado es suficiente con pararse en los tres más similares a nuestra plataforma focalizando en la característica más “killer”.

Análisis de costes

Cuanto mayores son los números en cuanto a ROI mayor debe ser el Elevator Pitch, orientado a estos números. Si son poco realistas deben ser repensados.

No confundir coste de mantenimiento con coste de operación, el mantenimiento puede ser por ejemplo el correctivo (para posibles fallos) o aumentativo (hay suficiente dinero como para hacer añadidos).

Para el TCO es pertinente definir un marco de tiempo (time frame) y una capacidad de demanda nominal para comprender mejor cómo se comportará el sistema en diferentes condiciones de uso, en resumen, cómo escalará. No solo se trata de cuántos usuarios pueden usarlo al mismo tiempo, sino también de cuándo y con qué nivel de demanda.

Hablar de porcentajes del número de usuarios que tienen que usar nuestra aplicación (TCO) con respecto al número de usuarios potenciales.

El número de usuarios que necesitamos para mantener la aplicación debe tener porcentajes con respecto al número de personas en el sector en Sevilla por ejemplo.

Documentación

Reflejar en el Commitment Agreement cuando personas tiene penalizaciones o “ya no van a por el 10”.

Proyecto en general

Se debe dejar claro la planificación de cada sprint, sobre todo si ha habido problemas de rendimiento en una semana, ¿Cómo afectan las carencias en este sprint a los próximos sprints?

Si no se llega al 100% del trabajo que se pedía, se debe justificar con un motivo de peso o penalizaciones sobre el Commitment Agreement o la evaluación grupal de la persona implicada.

El rendimiento no es la inversión del tiempo si no el uso efectivo del mismo.

El rendimiento se debe medir individualmente y no en grupo.

Si hay una propuesta de mejora se debe decir cómo se va a medir de antemano, antes de tomar la medida.

Las métricas del rendimiento debe ser capaz de comparar cada miembro del equipo y los datos obtenidos deben ser cotejados para evaluar al final de cada sprint. Para los que programan es sencillo; nº de commits… Pero ¿Cómo se está midiendo el rendimiento de la persona que coordina?

Durante el desarrollo dar preferencia a las funcionalidades core o del MVP, por ejemplo, si el login es secundario no debería estar siendo desarrollado en el primer sprint cuando el objetivo es acabar el MVP.

El testing no puede estar presente solamente en el sprint 3, deben ser FAST, se deben hacer a lo largo de todos los sprints.

En caso de tener problemas en el desarrollo, siempre valorar la posibilidad de mover tareas de un sprint a otro.

**

2. Acciones de consolidación

Tras recoger el feedback semanal han de ser evaluados y realizar los cambios pertinentes sobre el proyecto, aquí se recogen estos cambios.

Semana 1#

Costes

Se realizó el análisis de costes orientado a distinguir los costes de puesta en marcha, costes de desarrollo, costes de mantenimiento y coste total de propiedad. Además, se han añadido planes de acción en cuanto a la variación del volumen de usuarios. Se ha explicado el proceso que se ha seguido(teniendo en cuenta las píldoras teóricas) para identificar a los competidores.

Commitment Agreement

Se deja claro en el commitment agreement en quién recae la responsabilidad de una tarea en el grupo. Es el coordinador el que la piensa y asigna, pero la responsabilidad de la no realización de la misma recae sobre el asignado, a no ser que se avisara con tiempo suficiente como para poder encargársela a otro en día laboral.

Presentación

Se redujo la carga de las diapositivas, aumentando su cantidad y usando un mayor número de referencias simbólicas. Se tuvo en cuenta y se explica ahora la matriz DAFO empezando por Debilidades y Fortalezas, y luego Amenazas y Oportunidades. Nos hicimos fotos con el mismo fondo y pose. Pusimos los costos con un número sin decimales. Se dejó de lanzar preguntas al público sin que estuviera acordado entre ellos.

Semana 2#

Presentador

Se ha preparado un Killer opener más impactante unido a un Elevator Pitch, además de evitar sentarse durante la exposición.

Presentación

Se le dedica más tiempo en la exposición a desarrollar la idea de negocio y el core. No se usaba fondo negro, pero se aumenta el tamaño de la letra y fuente.

Se ha incluido promesas en la parte de la idea de negocio, y de definición del producto. Los mockups se han movido al final. Se ha cambiado la expresión del TCO a meses, y se expresa con más detalles los gastos y costes. Se indica con una “F” las partes donde se ha tenido en cuenta el feedback. Se ha aclarado que el uso de RRSS es opcional y siempre por parte del candidato. Se usan iconos con breve descripción, no sólo símbolos sueltos.

Comparaciones

Hemos analizado y remarcado cuales son nuestras diferencias más importantes del resto de competidores. No existen competidores que ofrezcan el servicio de forma gratuita. Además, el pricing ha sido actualizado para orientarlo a nuestro producto y hacerlo más llamativo(palabras claves y letras más grandes).

Commitment agreement

Se han realizado cambios en el commitment agreement sobre en quién recae la responsabilidad de una tarea y las recompensas del trabajo semanal individual, dando a un total de 15 cláusulas que volvieron a firmar los integrantes del equipo.

Riesgos

Se indica de manera explícita como solventar los riesgos y se ha aumentado el número de estos. Se describe el riesgo como evento, no como “problema”.

Costes

Se han añadido las licencias necesarias(Github) al análisis de costes. Además se ha calculado cuáles serán las ganancias.

Semana 3#

Presentador

Se trabaja sobre el Killer Opener y se elabora una historia como introducción más corta y directa. Para lidiar con problemas durante la exposición el presentador del grupo se ha grabado realizándola y la ha mandado a todo el grupo dándole este último apuntes y consejos sobre que puede ser obviado o qué no puede faltar, de esta manera es capaz de practicar la presentación y además afilar más los argumentos quitando lo innecesario.

Presentación

Para la presentación se toman en cuenta los comentarios que realizó el público y; se cambia la posición de la marca del feedback a la parte superior de las transparencias y se procura que en todo momento las letras estén lo suficientemente grandes o destacadas.

También se remarcan aún más nuestras diferencias con los competidores en la transparencia correspondiente.

Comunicación

Se mantiene el contacto con nuestros usuarios pilotos y dejamos claro que iremos avisando de cuando tengamos demos que puedan testear. Por su parte nos dan ya una fecha, el 28 de febrero, en la que tendríamos su demo.

Con respecto a las empresas contactadas, el estado de comunicación con estos es el mismo, una ha confirmado y el resto pendientes de respuesta.

Retrospectiva

Se han tomado medidas para nuestro uso del tiempo y las respuestas a estas han sido notables esta semana, por ello de momento las metas para el resto del proyecto se mantienen iguales.

Documentación

Tener una gestión de la documentación similar a la del código con github. Por ejemplo, la presentación debería subirse como una pull request con todo el grupo como revisor.

Seguimos con la misma metodología de gestión que habíamos tomado desde el inicio, con Drive, pero con tableros de github para controlarlos como un repositorio en el que un responsable se encarga de revisar cada documento y cada encargado de realizarlo es notificado mediante issues y si hubiera algún problema es notificado mediante comentarios en estos.

Semana 4#

Costes

Para el TCO se nos pedía y hemos realizado nuevos análisis en lo referente al número de usuarios que podría llegar a almacenar nuestra aplicación, si éste subiera aumentaría el coste de operación ya que sería necesario ampliar servicios de github, servidores…

También volvemos a calcular los usuarios por rol estimados para que la aplicación sea rentable en tres tipos: optimista, realista y pesimista.

Por último se cambia la manera de desplegar el TCO en capex y opex.

Consideraciones de la aplicación

Para solucionar la velocidad de chequeos el cliente el que tiene que añadir un token a a la aplicación y realizar las llamadas a la API, recae en este el riesgo y por tanto si un cliente tiene un token inválido o a excedido el límite de llamadas a la api tendrá que crearse uno nuevo o esperarse. Aún así es complicado que se llegue a dar este límite.

Para el análisis del rendimiento, el análisis de un usuarios tarda como mucho 5 segundos, dependiendo de la cantidad de datos del usuario, pero por ejemplo, para saber cuánto tarda en evaluar a X usuarios para formar un grupo lo sabremos la semana que viene cuando esto sea implementado.

Hemos realizado un exhaustivo análisis sobre gitflow y goldenflow y nos hemos decantado por una versión de gitflow que se adecúa a nuestras necesidades.

Rendimiento de equipo

Hemos dado una vuelta a la manera de evaluar al equipo en cuanto a rendimiento, se mantienen las tablas que teníamos por subgrupo (debido al feedback positivo del mismo) y añadimos también el análisis individual de cada miembro (anónimo). Para realizar este análisis hemos elaborado unas fórmulas en una tabla de excel que unifican la evaluación del grupo completo, cambiando según el rol.

De momento ningún miembro no ha dejado de optar al 10.

Riesgos

Hemos encontrado nuevos problemas que no suponían riesgos; con los usuarios pilotos del equipo 7 para el que estableceremos un calendario bidireccional y un problema de gestión de equipos que ha sido dividida en backend y frontend como principal subdivisión pese a seguir habiendo roles del apartado. Las medidas tomadas serán evaluadas para el próximo sprint viendo cuál ha sido el rendimiento.

Presentación

Dejamos reflejado a los responsables de distintas tareas de nuestro proyecto para ejemplificar la metodología de encargo de tareas del equipo.

Semana 5#

Código

Se ha realizado un trabajo más superficial del código reformateo y limpiado en su mayoría.

Presentación

Durante esta semana se ha preparado la presentación el coordinador del grupo al no poder nuestro presentador habitual ir a la sesión de retrospectiva. Se habla de las mecánicas, CA, tablas con horas…

Semana 6#

Presentación

Se trabaja sobre las diapositivas con el feedback que se dió en la última semana y se eliminan unas con capturas ilegibles al fondo de la clase además de algunas faltas ortográficas.

Costes

Se eliminan datos que se catalogaron como redundantes, y se buscan estimaciones de costes menos lineares. Se reajustan los costes teniendo en cuenta que seríamos nosotros los encargados de realizar las peticiones a la API.

Documentación

Se pasa toda la documentación a Markdown y se despliega un Docusaurus con esta en https://it-talent-wiki.vercel.app/ . Se redacta también el Contribute.md y los aspectos legales de nuestra aplicación.

Gestión del Tiempo

Durante el transcurso de las últimas dos semanas se toma en cuenta el tiempo de visualización de las píldoras teóricas como “Formación”.

Semana 7#

Presentación

Se repasa la presentación para evitar la poca claridad de la fuente con los fondos seleccionados. Se hace uso de zoom para la DEMO ya que la fuente era demasiado pequeña en algunas vistas y hacía que fueran ilegibles. También se pasan los storyboard a blanco y negro siguiendo lo recomendado en la píldora teórica. Se añade una diapositiva de puntos de historia VS tiempo consumido.

Empresas Piloto

Se revisan los usuarios piloto (empresas) que se creen menos probable que vayan a contestar y se eliminan de la presentación (estaban como "Pendiente de respuesta").

Presentador

Se prepara un Elevator Pitch más claro cohesionandolo con el Killer Opener ya existente. También se hará uso de los actores del killer opener y storyboard para el resto de la presentación con el objetivo de dar una "storyline".

Aplicación

Se añade una API al desarrollo para validar los correos electrónicos usados y se añade el coste de esta al Opex.

Semana 8#

Presentación

Se cuida que no haya ninguna diapositiva cuyo formato de imagen no permita reconocer los textos en esta. Se atiende a lo dicho en clas y se incluye una matriz con el esfuerzo en horas y el rendimiento estipulado por nuestro grupo con todos los integrantes.

Demo

Se usan datos realistas para la DEMO para los apartados de Candidatos y Representantes. Se aportan más gráficas para mostrar los datos para que quede más profesional.

Presentador

Cuida el movimiento por el espacio designado a presentar para no marear a la audiencia y procura, al mostrar alguna gráfica, desarrollar, mencionar o explicar algo de esta y no pasar sin comentarla.

Costes

A mayor número de clientes los costes varían; El personal de soporte aumentará si lo requiere la plataforma.

Usuarios Pilotos

Se habla con los usuarios piloto y tratamos de dejar claro cuál es la fecha límite para recibir su feedback, para tener tiempo a tomar acciones de consolidación en función a este.

Semana 9#

Presentación

Creamos un nuevo anuncio con el feedback aportado en la anterior clase sobre el existente. Se realiza una diapositiva que refleje mejor la mejora del rendimiento de un integrante con respecto a la semana anterior.

Usuarios Potenciales

Se repiensan los usuarios potenciales de nuestra aplicación al no tener datos realistas o suficientemente justificados de personas que USEN o puedan llegar a usarla en algún momento.

Demo

Nos cercioramos de que en el video de la demo se vaya directamente a las funcionalidades core sin pasar por otras como la edición de perfiles. Se incluyen los ToS en el registro.

Presentador

El presentador practica un ritmo constante de presentación para no subirlo y que se pierdan conceptos por ello.