No una lista de tareas. Los milestones ayudan a

Saber qué hay que hacer ahora. Se avanza por todos los issues del milestone, hasta que se llega al último.
Saber si lo que se ha hecho es válido o no: la parte "viable" del PMV debe describir cómo se va a considerar que el producto es viable.

El cero no describe ni un producto, ni un criterio de viabilidad. Agrupa ciertas características, que no constituyen un producto (ni se describen como tales). Mezcla infraestructura y metodología con detalles de implementación (que tampoco son parte del milestone).

El uno habla de "un sistema de reseñas", sin describirlo como un producto. Agrupa muchas funcionalidades, sin que quede claro qué precendencia ni relación hay entre ellas.

He editado cero aunque como #8 abarca mucho, no estará terminada hasta que se termine el proyecto, por lo que el milestone no quedará de momento al 100%. ¿Es mejor que saque esa HU del milestone ya que este milestone no se va a ocupar de cerrarla?

He editado también uno para que quede más claro el objetivo del milestone.

8 no tiene por qué solucionarse en un milestone. Los HUs se van moviendo de un milestone a otro, según se van resolviendo issues creados a partir de cada uno de ellos. De hecho, pueden perfectamente estar fuera de cualquier milestone, aunque puede ser conveniente que los mantentas temporalmente en uno si hay issues específicos que se refieran a él.

El problema con el siguiente milestone es que sigue sin describir un producto mínimamente viable. ¿El servicio tiene que estar desplegado? ¿Devuelve a quién? ¿Al front-end?

Entre cero y uno hay muchos intermedios: las estructuras de datos que vas a usar para almacenar, la lógica de negocio como algo totalmente separado de la implementación específica. Eso serían, al menos, un milestone cada uno, que auto-describe el PM (estructuras de datos, lógica de negocio). Tanto el API como el almacenamiento como el frontend no pueden avanzar hasta que resuelvas todos esos problemas (que son problemas que tienes que plantear en sus issues correspondientes)

Este issue, por cierto, también tienes que asignarlo a un milestone, claro.

8 no tiene por qué solucionarse en un milestone. Los HUs se van moviendo de un milestone a otro, según se van resolviendo issues creados a partir de cada uno de ellos. De hecho, pueden perfectamente estar fuera de cualquier milestone, aunque puede ser conveniente que los mantentas temporalmente en uno si hay issues específicos que se refieran a él.

El problema con el siguiente milestone es que sigue sin describir un producto mínimamente viable. ¿El servicio tiene que estar desplegado? ¿Devuelve a quién? ¿Al front-end?

Entre cero y uno hay muchos intermedios: las estructuras de datos que vas a usar para almacenar, la lógica de negocio como algo totalmente separado de la implementación específica. Eso serían, al menos, un milestone cada uno, que auto-describe el PM (estructuras de datos, lógica de negocio). Tanto el API como el almacenamiento como el frontend no pueden avanzar hasta que resuelvas todos esos problemas (que son problemas que tienes que plantear en sus issues correspondientes)

Sigo sin entender esto del todo. Pensé que la última vez que hablamos del milestone ya estaba correcto y que crear un milestone para crear estructuras de datos solamente no era lo suyo, pero ahora estoy entendiendo que sí.

Creo que no hablamos el mismo idioma (posiblemente por mi culpa), pero para mi un producto (ya sea minimamente viable o no) es algo con valor para el cliente. Simplemente crear estructuras de datos no tiene ningún valor para el cliente, ya que este será ajeno a cómo se organicen internamente los datos en la aplicación. Por eso mismo, el objetivo del primer milestone es crear un servicio (en este caso, una API) con el que el cliente pueda probar un conjunto de funcionalidades de la aplicación sobre las que se van a crear las demás (primero se necesita un sistema de reseñas y luego se creará la parte de seguir a otros usuarios, etc).

Si los milestones deberían ser: hacer la estrucutra de datos, hacer la api y hacer el front-end, estaría bien saberlo y así cambio el enfoque.

8 no tiene por qué solucionarse en un milestone. Los HUs se van moviendo de un milestone a otro, según se van resolviendo issues creados a partir de cada uno de ellos. De hecho, pueden perfectamente estar fuera de cualquier milestone, aunque puede ser conveniente que los mantentas temporalmente en uno si hay issues específicos que se refieran a él.

El problema con el siguiente milestone es que sigue sin describir un producto mínimamente viable. ¿El servicio tiene que estar desplegado? ¿Devuelve a quién? ¿Al front-end? Entre cero y uno hay muchos intermedios: las estructuras de datos que vas a usar para almacenar, la lógica de negocio como algo totalmente separado de la implementación específica. Eso serían, al menos, un milestone cada uno, que auto-describe el PM (estructuras de datos, lógica de negocio). Tanto el API como el almacenamiento como el frontend no pueden avanzar hasta que resuelvas todos esos problemas (que son problemas que tienes que plantear en sus issues correspondientes)

Sigo sin entender esto del todo. Pensé que la última vez que hablamos del milestone ya estaba correcto y que crear un milestone para crear estructuras de datos solamente no era lo suyo, pero ahora estoy entendiendo que sí.

Un milestone es un producto mínimamente viable, una parada en el camino para ver que todo está bien, se está avanzando en la dirección correcta, y se tiene todo lo necesario para pasar al siguiente milestone. Sin las estructuras de datos, ¿puedes avanzar en la lógica de negocio? ¿Puedes siquiera plantearte la lógica de negocio y las diferentes capas de abstracción del proyecto?

Creo que no hablamos el mismo idioma (posiblemente por mi culpa), pero para mi un producto (ya sea minimamente viable o no) es algo con valor para el cliente. Simplemente crear estructuras de datos no tiene ningún valor para el cliente, ya que este

En ese sentido, lo único que tendría valor para el cliente sería el producto final. ¿Le puedes presentar al cliente un API REST? ¿Le puedes presentar la infraestructura necesaria para testearlo todo? Todos los milestones intermedios se presentan al product manager (que en este caso sería yo, supongo). Lo importante es que esos productos intermedios aporten valor para el cliente, lo que está garantizado por la metodología y que sigas las historias de usuario siempre.

Volvemos al principio: una metodología te tiene que decir dos cosas. Qué hago ahora y si lo que hago está bien. Si la metodología incluyera sólo PMVs que el cliente puede "ver" y evaluar, no haría lo primero. Dejaría toda la organización del proyecto en el aire, porque como lo que "hay que hacer ahora" es presentar una web funcionando, los pasos intermedios pueden ser totalmetne un caos.

Los milestones, sin embargo, te permiten organizar claramente un desarrollo en capas, que parta de una modelización del problema, pase por las estructuras de datos que puedan funcionar de forma correcta con el mismo, añada la lógica de negocio, y finalmente vaya construyendo las siguientes capas para finalmente tener un producto para el cliente: arquitectura de la aplicación, UX, etcétera.

Esta organización te permite también parar en un momento determinado, sabiendo que tienes un producto mínimamente viable. Que es un producto que ha avanzado hacia el objetivo que te habías planteado, aunque no necesariamente un producto con un UX desplegado usando kubernetes en la nube. Esta idea de que una aplicación cliente servidor es un producto está mucho más alejada de la realidad que el que simplemente programes un backend con un API diseñado correctamente y testeado. Eso sí es un producto (una aplicación cliente servidor no lo es si no está testeada en todos los aspectos de las especificaciones, y con un script de despliegue que permita que funcione en cualquier circunstancia)

será ajeno a cómo se organicen internamente los datos en la aplicación. Por eso mismo, el objetivo del primer milestone es crear un servicio (en este caso, una API) con el que el cliente pueda probar un conjunto de funcionalidades de la aplicación sobre las que se van a crear las demás (primero se necesita un sistema de reseñas y luego se creará la parte de seguir a otros usuarios, etc).

Eso no te ayuda en absoluto a organizar la aplicación en una serie de pasos de complejidad creciente. No te ayuda a tomar una serie de decisiones informadas sobre la arquitectura (¿por qué API y no serverless usando un framework de aplicaciones en la nube como FireStore?) ni te ayuda a desacoplar las diferentes partes de la misma ni a abstraer en capas la lógica de negocio, las estructuras de datos, el almacenamiento, y demás.

Un TFG no es un producto. Es el conjunto de decisiones técnicas que tienes que tomar a la hora de desarrollar un producto, y que te permite adquirir madurez como ingeniero software. Y una parte muy importante de esas decisiones técnicas es organizar el desarrollo en una serie de hitos (milestones == productos mínimamente viables) que te permita tomarte el tiempo suficiente para decidir qué es lo mejor en cada etapa y qué le añade más valor al cliente.

Si los milestones deberían ser: hacer la estrucutra de datos, hacer la api y hacer el front-end, estaría bien saberlo y así cambio el enfoque.

No, los milestones es algo que tienes tú que decidir en función de tu problema, y esas decisiones constituyen tu TFG. En el caso más general (y así lo vimos en IV) esos son los pasos a seguir, porque no tendrás API hasta que no tengas las estructuras de datos, y no tendrás front-end hasta que no tengas back-end. Pero ni el back-end ni el front-end son cosas obligatorias. Puedes decidir una aplicación usando UI de consola. O una biblioteca que codifique la lógica de negocio. En cualquiera de los casos, tienes que trazar un camino con productos mínimamente viables, con énfasis en mínimamente. ¿Un API es mínimo? ¿Si no construyes el API no puedes saber si las estructuras de datos son las correctas? ¿Sin el API no puedes saber si la lógica de negocio es la correcta? Si es así, oye, pues el API es mínimo. Pero si tienes unos criterios de viabilidad que te digan si unas estructuras de datos son correctas, eso es el producto mínimamente viable. Es enteramente posible que sin la lógica de negocio no puedas saber si las estructuras de datos son viables. En ese caso, estructuras de datos + lógica de negocio será el PMV. Y eso es lo que tienes que decidir tú, y mostrar madurez en entender qué es un producto mínimamente viable.

¿Queda más claro ahora?

8 no tiene por qué solucionarse en un milestone. Los HUs se van moviendo de un milestone a otro, según se van resolviendo issues creados a partir de cada uno de ellos. De hecho, pueden perfectamente estar fuera de cualquier milestone, aunque puede ser conveniente que los mantentas temporalmente en uno si hay issues específicos que se refieran a él.

El problema con el siguiente milestone es que sigue sin describir un producto mínimamente viable. ¿El servicio tiene que estar desplegado? ¿Devuelve a quién? ¿Al front-end? Entre cero y uno hay muchos intermedios: las estructuras de datos que vas a usar para almacenar, la lógica de negocio como algo totalmente separado de la implementación específica. Eso serían, al menos, un milestone cada uno, que auto-describe el PM (estructuras de datos, lógica de negocio). Tanto el API como el almacenamiento como el frontend no pueden avanzar hasta que resuelvas todos esos problemas (que son problemas que tienes que plantear en sus issues correspondientes)

Sigo sin entender esto del todo. Pensé que la última vez que hablamos del milestone ya estaba correcto y que crear un milestone para crear estructuras de datos solamente no era lo suyo, pero ahora estoy entendiendo que sí.

Un milestone es un producto mínimamente viable, una parada en el camino para ver que todo está bien, se está avanzando en la dirección correcta, y se tiene todo lo necesario para pasar al siguiente milestone. Sin las estructuras de datos, ¿puedes avanzar en la lógica de negocio? ¿Puedes siquiera plantearte la lógica de negocio y las diferentes capas de abstracción del proyecto?

Creo que no hablamos el mismo idioma (posiblemente por mi culpa), pero para mi un producto (ya sea minimamente viable o no) es algo con valor para el cliente. Simplemente crear estructuras de datos no tiene ningún valor para el cliente, ya que este

En ese sentido, lo único que tendría valor para el cliente sería el producto final. ¿Le puedes presentar al cliente un API REST? ¿Le puedes presentar la infraestructura necesaria para testearlo todo? Todos los milestones intermedios se presentan al product manager (que en este caso sería yo, supongo). Lo importante es que esos productos intermedios aporten valor para el cliente, lo que está garantizado por la metodología y que sigas las historias de usuario siempre.

Volvemos al principio: una metodología te tiene que decir dos cosas. Qué hago ahora y si lo que hago está bien. Si la metodología incluyera sólo PMVs que el cliente puede "ver" y evaluar, no haría lo primero. Dejaría toda la organización del proyecto en el aire, porque como lo que "hay que hacer ahora" es presentar una web funcionando, los pasos intermedios pueden ser totalmetne un caos.

Los milestones, sin embargo, te permiten organizar claramente un desarrollo en capas, que parta de una modelización del problema, pase por las estructuras de datos que puedan funcionar de forma correcta con el mismo, añada la lógica de negocio, y finalmente vaya construyendo las siguientes capas para finalmente tener un producto para el cliente: arquitectura de la aplicación, UX, etcétera.

Esta organización te permite también parar en un momento determinado, sabiendo que tienes un producto mínimamente viable. Que es un producto que ha avanzado hacia el objetivo que te habías planteado, aunque no necesariamente un producto con un UX desplegado usando kubernetes en la nube. Esta idea de que una aplicación cliente servidor es un producto está mucho más alejada de la realidad que el que simplemente programes un backend con un API diseñado correctamente y testeado. Eso sí es un producto (una aplicación cliente servidor no lo es si no está testeada en todos los aspectos de las especificaciones, y con un script de despliegue que permita que funcione en cualquier circunstancia)

será ajeno a cómo se organicen internamente los datos en la aplicación. Por eso mismo, el objetivo del primer milestone es crear un servicio (en este caso, una API) con el que el cliente pueda probar un conjunto de funcionalidades de la aplicación sobre las que se van a crear las demás (primero se necesita un sistema de reseñas y luego se creará la parte de seguir a otros usuarios, etc).

Eso no te ayuda en absoluto a organizar la aplicación en una serie de pasos de complejidad creciente. No te ayuda a tomar una serie de decisiones informadas sobre la arquitectura (¿por qué API y no serverless usando un framework de aplicaciones en la nube como FireStore?) ni te ayuda a desacoplar las diferentes partes de la misma ni a abstraer en capas la lógica de negocio, las estructuras de datos, el almacenamiento, y demás.

Un TFG no es un producto. Es el conjunto de decisiones técnicas que tienes que tomar a la hora de desarrollar un producto, y que te permite adquirir madurez como ingeniero software. Y una parte muy importante de esas decisiones técnicas es organizar el desarrollo en una serie de hitos (milestones == productos mínimamente viables) que te permita tomarte el tiempo suficiente para decidir qué es lo mejor en cada etapa y qué le añade más valor al cliente.

Si los milestones deberían ser: hacer la estrucutra de datos, hacer la api y hacer el front-end, estaría bien saberlo y así cambio el enfoque.

No, los milestones es algo que tienes tú que decidir en función de tu problema, y esas decisiones constituyen tu TFG. En el caso más general (y así lo vimos en IV) esos son los pasos a seguir, porque no tendrás API hasta que no tengas las estructuras de datos, y no tendrás front-end hasta que no tengas back-end. Pero ni el back-end ni el front-end son cosas obligatorias. Puedes decidir una aplicación usando UI de consola. O una biblioteca que codifique la lógica de negocio. En cualquiera de los casos, tienes que trazar un camino con productos mínimamente viables, con énfasis en mínimamente. ¿Un API es mínimo? ¿Si no construyes el API no puedes saber si las estructuras de datos son las correctas? ¿Sin el API no puedes saber si la lógica de negocio es la correcta? Si es así, oye, pues el API es mínimo. Pero si tienes unos criterios de viabilidad que te digan si unas estructuras de datos son correctas, eso es el producto mínimamente viable. Es enteramente posible que sin la lógica de negocio no puedas saber si las estructuras de datos son viables. En ese caso, estructuras de datos + lógica de negocio será el PMV. Y eso es lo que tienes que decidir tú, y mostrar madurez en entender qué es un producto mínimamente viable.

¿Queda más claro ahora?

Vale. Lo he entendido. Ahora el caso es qué hacer con #44 ya que añade lógica de la API. ¿Qué tal dejarla como draft para no perder el trabajo realizado, pero añadir los cambios que tengan que ven con la estructura de datos en una nueva rama?

He editado el milestone para hacerlo más mínimo y le he añadido más historias de usuario, ya que los cambios que se hagan avanzarán en ellas.

8 no tiene por qué solucionarse en un milestone. Los HUs se van moviendo de un milestone a otro, según se van resolviendo issues creados a partir de cada uno de ellos. De hecho, pueden perfectamente estar fuera de cualquier milestone, aunque puede ser conveniente que los mantentas temporalmente en uno si hay issues específicos que se refieran a él.

El problema con el siguiente milestone es que sigue sin describir un producto mínimamente viable. ¿El servicio tiene que estar desplegado? ¿Devuelve a quién? ¿Al front-end? Entre cero y uno hay muchos intermedios: las estructuras de datos que vas a usar para almacenar, la lógica de negocio como algo totalmente separado de la implementación específica. Eso serían, al menos, un milestone cada uno, que auto-describe el PM (estructuras de datos, lógica de negocio). Tanto el API como el almacenamiento como el frontend no pueden avanzar hasta que resuelvas todos esos problemas (que son problemas que tienes que plantear en sus issues correspondientes)

Sigo sin entender esto del todo. Pensé que la última vez que hablamos del milestone ya estaba correcto y que crear un milestone para crear estructuras de datos solamente no era lo suyo, pero ahora estoy entendiendo que sí.

¿Entiendes que no se puede avanzar en un milestone hasta haber terminado el anterior? El 0 no está completo, y el 0 incluye la estructura de milestones del resto, al menos la inicial. Los milestones incluyen PMVs de complejidad creciente por lo que, por definición, no puedes iniciar el primero hasta que no hayas terminado el cero.

Vale. Lo he entendido. Ahora el caso es qué hacer con #44 ya que añade lógica de la API. ¿Qué tal dejarla como draft para no perder el trabajo realizado, pero añadir los cambios que tengan que ven con la estructura de datos en una nueva rama?

Lo primero, entender que no existe "la lógica de la API". El API es una simple fachada que publica, para un cliente determinado, una serie de capacidades que hay que decidir de antemano y permite acceder a la lógica de negocio. Pero la lógica de negocio (cualquier que sea, en este caso posiblemente recomendaciones) tiene que estar totalmente desacoplada de cualquier forma en la que se vaya a exponer, porque puede ser un API, una biblioteca, o una herramienta de línea de órdenes.

Lo de dejarla como draft va de suyo; en programación se aprovecha todo. Pero lo que no quiero es que te sientas atado a lo que ya hay hecho para encaminar el desarrollo en esa dirección. Tienes que dejar que la propia dinámica de la resolución de problemas del desarrollo te dicte qué hacer.

He editado el milestone para hacerlo más mínimo y le he añadido más historias de usuario, ya que los cambios que se hagan avanzarán en ellas.

Me parece correcto. Quizás afinar un poco más con qué quieres decir con el modelo de datos, si es completo o parcial, y especificar un poco más cuál es el criterio para considerarla válida, aparte del hecho de que esté eso, hecha.

Recuerda también que las HUs se irán moviendo de milestone y que lo que realmente se desarrolla son issues ligados a las historias de usuario, donde plantees los problemas a resolver.

He editado el milestone para hacerlo más mínimo y le he añadido más historias de usuario, ya que los cambios que se hagan avanzarán en ellas.

Me parece correcto. Quizás afinar un poco más con qué quieres decir con el modelo de datos, si es completo o parcial, y especificar un poco más cuál es el criterio para considerarla válida, aparte del hecho de que esté eso, hecha.

Recuerda también que las HUs se irán moviendo de milestone y que lo que realmente se desarrolla son issues ligados a las historias de usuario, donde plantees los problemas a resolver.

Okay. Pues lo doy por cerrado ya este issue y me pongo con el milestone.

Er. Siempre se cierran mediante cambios en el repo. En este caso, tendría que ser cambios en la descripción de los hitos en la memoria, por ejemplo. De esa forma, al pasar siempre por una revisión, te aseguras que el problema realmente se ha resuelto. Esto no es específico de este issue, sino parte del desarrollo ágil. Si no te importa, reabre y haz lo indicado.

Torchu / flixbuff

Los milestones tienen que describir productos mínimamente viables #45