[IV-24-25] Objetivo0

[juanmaaf]

• [x] ¿Se trata de un problema real del que se tenga conocimiento personal?
• [X] ¿Se trata de un problema que para solucionar requiera el despliegue de una aplicación en la nube?
• [X] ¿La solución requiere una cierta cantidad de lógica de negocio, en vez solucionarse sólo almacenando y buscando?
• [X] ¿Se ha incluído la configuración del repositorio y se ha enlazado desde el README?
• [x] ¿Tienes todos los datos necesarios para poder resolver el problema, o vas a requerir que el usuario los introduzca?
• [X] ¿Has seguido la lista de comprobación o estás marcando al buen tuntún todo?

[JJ]

Por favor, haz la lista de comprobación en el cuerpo, no en el primer comentario.

[juanmaaf]

Revisión @JJ

[juanmaaf]

El problema que defino en mi ficha de juego es el "doble problema" que me indica en la primera versión que describo. Inicialmente indico problemas de tiempo y dinero, y me he acabado decantando por uno de ellos, el que tiene cierta lógica de negocio según mi criterio.

[JJ]

El problema que defino en mi ficha de juego es el "doble problema" que me indica en la primera versión que describo. Inicialmente indico problemas de tiempo y dinero, y me he acabado decantando por uno de ellos, el que tiene cierta lógica de negocio según mi criterio.

OK, pues la cuestión es entonces que lo describas un poco mejor y con más precisión. Piensa que es un documento de trabajo para comenzar el desarrollo de un producto, por tu parte o por la de cualquier otra persona.

[juanmaaf]

Revisión @JJ

[JJ]

Me vas a perdonar, pero estoy revisando este objetivo y me da la impresión de que me precipité a la hora de darlo por superado. Primero, no has incluido la configuración, que es un requisito. Segundo, el problema realmente no está claro. Puede que tuviera en mente algo que habíamos hablado en clase, pero no veo como "organizar" o "prever gastos adicionales" es realmente un problema. Y si lo es, como puede resolverse de forma que no sea simplemente almacenar y buscar. Como ya está superado, tampoco vamos a volver atrás; además, estás ya en el siguiente. El problema es que con esto va a ser imposible que plantees historias de usuario que sean realmente un problema e imposible programar una lógica de negocio, y va a ser complicado por tanto que pases el objetivo 1 siquiera. Como ya está enviado el siguiente, creo que para trabajar a base de mejora incremental como pide el desarrollo ágil lo que tienes que hacer es

1. Definir el problema mejor a base de un buen user journey, que es evidente que en este caso es necesario.
2. Tratar de precisar realmente a partir de esos user journey las historias de usuario, para que se vea claro cuál es el problema (que eso es en realidad lo que te comento aquí)

Por otro lado, en la rama principal sube y enlaza el pantallazo donde muestre que has subido la clave pública. Lo comprobaré cuando pase yo a revisar el objetivo 1

[juanmaaf]

El problema consiste en que el estudiante no consigue llegar a final de mes. Tiene diversos gastos: Fijos (alquiler, gastos de electricidad, agua internet y teléfono), Variables (decide ir al gimnasio ese mes, realizar actividades deportivas de pago semanalmente como, pádel...) y además quiere ahorrar una cantidad fijada mensualmente. La idea es que, cómo no llega a final de mes, que es el problema, no sabe si puede permitirse un gasto extra además del presupuesto anterior, como gastar en ropa o ir a restaurantes. No es simplemente almacenar y buscar, pues la idea es que a través del desarrollo de los hitos, el usuario pueda registrar sus gastos y a través de ellos se calcule, en función de su presupuesto, si dispone de un resto para gastar, pudiendo llegar a final de mes sin estar en negativo.

Ahora mismo incluyo el pantallazo a la rama main. @JJ

[JJ]

Dispondrá de un resto si restando de los ingresos los gastos queda una cantidad mayor que cero, ¿no? A ver, tal como lo hablamos esto no era tan simple. Lo que yo entendí es que ibas a calcular, basándose en comportamiento en meses anteriores, cuando iban a caer gastos determinados o cuanto te ibas a gastar. Por ejemplo, suponte que un mes te has gastado el primer fin de semana 40€, el segundo 70€ y el 3º de chill 5 en una birra y una bolsa de patatas. En base a eso, tendrás que decir a día 3 o 7 si te puedes gastar yo qué sé 30€ en una carcasa súper guay. Lo esencial es esa estadística que te diga por categorías cuanto te sueles y/o puedes gastar, sobre todo teniendo en cuenta los gastos fijos (y no tan fijos) que puedas tener. Por ejemplo, la comunidad de vecinos es fija, pero la electricidad no lo es. Y en este caso puede haber un componente estacional también. Yo creo que era esto lo que tenía en mente, pero no lo has puesto ni aquí ni posiblemente en las HUs. Te rogaría que lo hicieras.

[juanmaaf]

Vale, gracias por las indicaciones.