Update Objetivo 1 #12
Conversation
docs/issues.md
Outdated
|
|
||
| ## Historias de Usuario | ||
|
|
||
| * [HU1](https://github.com/Xileon310/IV-Project/issues/3) --> Como administrador se pretende poder registrar todos los materiales que se usen en los talleres, así como los proveedores que los proporcionan y su precio. |
There was a problem hiding this comment.
Va a ser imposible que cuentes con datos reales de talleres, con lo que la lógica de negocio tendrá que ser forzosamente muy simple. En todo caso, consulta el concepto de historia de usuario, que debe incluir siempre el beneficio que supone para el mismo realizar la tarea. En esta (y en las demás) no veo ningún beneficio. Si son tareas puramente mecánicas de almacenar y buscar, serán simplemente issues asociados a las historias deusuario.
There was a problem hiding this comment.
Resuelto, he cambiado la lógica de negocio.
El software será gratuito, y su principal objetivo será la administración del inventario de una red de talleres y automatización de tareas tediosas (como realizar pedidos automáticamente a los proveedores). Por otro lado, la lógica de negocio se basará en recopilar información y en base a ella generar un informe de estadísticas que posteriormente se venderá a empresas de automoción u otros talleres.
La duda que se me plantea es: ¿Es mejor centrar el software en un único taller? O por el contrario seguir con la idea de una red de talleres, pero es cierto que administrar un taller de forma individual siempre será más fácil y efectivo que una red de talleres.
El problema que reside el hecho de administrar una red de talleres es: ¿Qué pasa con los talleres pequeños y particulares? Seguramente le interese también este software.
docs/issues.md
Outdated
| ## Historias de Usuario | ||
|
|
||
| * [HU1](https://github.com/Xileon310/IV-Project/issues/3) --> Como administrador se pretende poder registrar todos los materiales que se usen en los talleres, así como los proveedores que los proporcionan y su precio. | ||
| * [HU2](https://github.com/Xileon310/IV-Project/issues/4) --> Como usuario del sistema, bien mecánico o gestor del taller, se deben poder registrar reparaciones de vehículos. |
There was a problem hiding this comment.
Resuelto, el registro de estas reparaciones se usará en futuros informes. ¿Debería asociar esta HU a HU3 (generar informes) y quitar el milestone 2?
docs/issues.md
Outdated
|
|
||
| * [HU1](https://github.com/Xileon310/IV-Project/issues/3) --> Como administrador se pretende poder registrar todos los materiales que se usen en los talleres, así como los proveedores que los proporcionan y su precio. | ||
| * [HU2](https://github.com/Xileon310/IV-Project/issues/4) --> Como usuario del sistema, bien mecánico o gestor del taller, se deben poder registrar reparaciones de vehículos. | ||
| * [HU3](https://github.com/Xileon310/IV-Project/issues/5) --> El administrador debe poder generar un informe en los intervalos de tiempo que desee y consultarlo. |
There was a problem hiding this comment.
¿Generar un informe, de qué? ¿En base a qué? ¿Qué beneficio va a obtener?
There was a problem hiding this comment.
Resuelto, se añade la información que contendrá el informe y el objetivo (pedidos concurrentes automatizados a los proveedores).
docs/issues.md
Outdated
| * [HU1](https://github.com/Xileon310/IV-Project/issues/3) --> Como administrador se pretende poder registrar todos los materiales que se usen en los talleres, así como los proveedores que los proporcionan y su precio. | ||
| * [HU2](https://github.com/Xileon310/IV-Project/issues/4) --> Como usuario del sistema, bien mecánico o gestor del taller, se deben poder registrar reparaciones de vehículos. | ||
| * [HU3](https://github.com/Xileon310/IV-Project/issues/5) --> El administrador debe poder generar un informe en los intervalos de tiempo que desee y consultarlo. | ||
| * [HU4](https://github.com/Xileon310/IV-Project/issues/6) --> En caso de necesitar un material diferente o en mayor cantidad en un determinado taller, el usuario (mecánico o gestor) debe poder generar un pedido que será aprobado por el administrador para posteriormente comunicarlo al proveedor. |
There was a problem hiding this comment.
No veo ninguna relación con la lógica de negocio ni ningún beneficio. Por favor, caracterizad bien el problema, y no pongáis simplemente actividades que os parece que estén relacionadas con el mismo.
There was a problem hiding this comment.
He corregido un poco esta HU, pero realmente no tiene relación con la lógica de negocio (informes de estadísticas para vender a las empresas de automoción). Pero mi duda es que debería ser un objetivo a cumplir para satisfacer al usuario, aunque no afecte a la lógica de negocio (recopilación y procesamiento de datos para estadísticas).
There was a problem hiding this comment.
Puede haber muchos usuarios, cada uno obtener un beneficio diferentes, y la lógica de negocio se puede aplicar a lo que necesiten algunos usuarios, o a todos; así mismo, el beneficio no tiene por qué ser económico; se trata en muchos casos del incentivo para que usen la aplicación eventualmente.
docs/issues.md
Outdated
| * [HU2](https://github.com/Xileon310/IV-Project/issues/4) --> Como usuario del sistema, bien mecánico o gestor del taller, se deben poder registrar reparaciones de vehículos. | ||
| * [HU3](https://github.com/Xileon310/IV-Project/issues/5) --> El administrador debe poder generar un informe en los intervalos de tiempo que desee y consultarlo. | ||
| * [HU4](https://github.com/Xileon310/IV-Project/issues/6) --> En caso de necesitar un material diferente o en mayor cantidad en un determinado taller, el usuario (mecánico o gestor) debe poder generar un pedido que será aprobado por el administrador para posteriormente comunicarlo al proveedor. | ||
| * [HU5](https://github.com/Xileon310/IV-Project/issues/7) --> El administrador debe poder conocer y generar informes de valor, tanto para nuestra empresa como para empresas de automoción, con las reparaciones más comunes y los modelos de coches más propensos a tenerlas. |
There was a problem hiding this comment.
OK, esto parece lógica de negocio, pero falta el "dado que". ¿De dónde obtiene los modelos de coches? ¿Qué beneficio obtiene?
There was a problem hiding this comment.
Resuelto, se ha añadido beneficio.
¿Mi aplicación es usuaria misma de ella? Al cambiar la lógica de negocio, es mi aplicación la que debe generar dichos informes en segundo plano, o por orden de mi empresa.
Si esta HU ya no se hace ni por el administrador de la red de talleres ni por los usuarios (mecánicos), ¿Debería eliminarla?
There was a problem hiding this comment.
Evidentemente, las HUs que no contribuyan a ningún producto es mejor eliminarlas.
|
Listo para revisión |
There was a problem hiding this comment.
El M1 es razonable en ámbito (si no tenemos los datos, no podemos calcular nada) pero no en la descripción del mismo; una base de datos no es esencial para la lógica de negocio, que simplemente necesita los datos para invocar una serie de funciones. Por favor, cambia este hito al menos para que describa un producto que realmente sea el primero mínimamente viable, de acuerdo con lo que hemos visto en el objetivo 2, y el resto también.
Ten en cuenta también que los PMVs se elaboran cada uno sobre el anterior, y cada uno suele tener múltiples HU que además pueden cambiar de hito y pasar al siguiente. Arregla esto y el hito estará superado.
README.md
Outdated
| @@ -5,12 +5,18 @@ Repositorio para la asignatura de IV. | |||
|
|
|||
| Se pretende desarrollar un software que facilite la gestión de inventario de una cadena de talleres de mecánica y vehículos. | |||
|
|
|||
| La lógica de negocio principal se basará en estadísticas que podremos adquirir del uso del software por parte de los talleres. Principalmente las estadísticas serán sobre las marcas y modelos de coches más propensos a reparaciones, así como las piezas que se rompan con mayor frecuencia. Este informe es de gran valor para las empresas de automoción. | |||
docs/issues.md
Outdated
|
|
||
| ## Usuarios | ||
|
|
||
| - **Administrador**: este usuario será el encargado de gestionar la red de talleres, podrá generar los informes de inventario y estadísticas que desee. Además, será el encargado de aprobar los pedidos concretos de los diferentes mecánicos. Por otro lado será el encargado de modificar los pedidos concurrentes para satisfacer la demanda en los diferentes talleres. |
There was a problem hiding this comment.
Por favor, no añadáis más tareas que las estrictamente necesarias para alimentar la lógica de negocio y los productos mínimamente viables que la incluyan. Aunque lo que comentas sería necesario quizás para una aplicación completa, no es tan necesario en este contexto. Resumen: quédate en las estadísticas.
docs/issues.md
Outdated
| ## Historias de Usuario | ||
|
|
||
| * [HU1](https://github.com/Xileon310/IV-Project/issues/3) --> Como administrador se pretende poder registrar todos los materiales de los que se dispongan en los diferentes talleres y su precio. Esta función permitirá al administrador saber de qué material dispone y podrá automatizar tareas como pedir piezas concretas periódicamente. Por otro lado, el precio ayudará en un futuro a generar informes de costes/beneficios para la empresa. | ||
| * [HU2](https://github.com/Xileon310/IV-Project/issues/4) --> Como usuario del sistema, bien mecánico o gestor del taller, se deben poder registrar reparaciones de vehículos, que posteriormente se podrán usar para generar informes en base al material gastado y a las reparaciones más comunes. |
There was a problem hiding this comment.
Especifica lo más posible qué es lo que necesita registrar para alimentar la lógica de negocio.
docs/issues.md
Outdated
|
|
||
| * [HU1](https://github.com/Xileon310/IV-Project/issues/3) --> Como administrador se pretende poder registrar todos los materiales de los que se dispongan en los diferentes talleres y su precio. Esta función permitirá al administrador saber de qué material dispone y podrá automatizar tareas como pedir piezas concretas periódicamente. Por otro lado, el precio ayudará en un futuro a generar informes de costes/beneficios para la empresa. | ||
| * [HU2](https://github.com/Xileon310/IV-Project/issues/4) --> Como usuario del sistema, bien mecánico o gestor del taller, se deben poder registrar reparaciones de vehículos, que posteriormente se podrán usar para generar informes en base al material gastado y a las reparaciones más comunes. | ||
| * [HU3](https://github.com/Xileon310/IV-Project/issues/5) --> El administrador debe poder generar un informe en los intervalos de tiempo que desee y consultarlo, sabiendo qué materiales se han gastado (junto con su cantidad) y los modelos de coches reparados, con su respectiva reparación. Servirá para ir perfilando la cantidad de material que se debe pedir periódicamente para ahorrar tiempo y comunicaciones con los proveedores. |
There was a problem hiding this comment.
No creo que haga falta esta HU, lo que implica que si la asignas a un PMV, quizás no debería ser de los primeros.
docs/issues.md
Outdated
| * [HU1](https://github.com/Xileon310/IV-Project/issues/3) --> Como administrador se pretende poder registrar todos los materiales de los que se dispongan en los diferentes talleres y su precio. Esta función permitirá al administrador saber de qué material dispone y podrá automatizar tareas como pedir piezas concretas periódicamente. Por otro lado, el precio ayudará en un futuro a generar informes de costes/beneficios para la empresa. | ||
| * [HU2](https://github.com/Xileon310/IV-Project/issues/4) --> Como usuario del sistema, bien mecánico o gestor del taller, se deben poder registrar reparaciones de vehículos, que posteriormente se podrán usar para generar informes en base al material gastado y a las reparaciones más comunes. | ||
| * [HU3](https://github.com/Xileon310/IV-Project/issues/5) --> El administrador debe poder generar un informe en los intervalos de tiempo que desee y consultarlo, sabiendo qué materiales se han gastado (junto con su cantidad) y los modelos de coches reparados, con su respectiva reparación. Servirá para ir perfilando la cantidad de material que se debe pedir periódicamente para ahorrar tiempo y comunicaciones con los proveedores. | ||
| * [HU4](https://github.com/Xileon310/IV-Project/issues/6) --> En caso de necesitar un material diferente en un determinado taller, el usuario (mecánico o gestor) debe poder generar un pedido que será aprobado por el administrador para posteriormente comunicarlo al proveedor. Habrá pedidos genéricos según los informes generados y pedidos que se hagan en situaciones concretas. Un ejemplo de ello sería que no es tan común arreglar un BMW X6 como un peugeout 306. |
There was a problem hiding this comment.
Como digo, no hace falta a la lógica de negocio → a los últimos hitos/MV. En todo caso, no entiendo muy bien esta HU (y al equipo de desarrollo le va a ser difícil entenderla)
docs/issues.md
Outdated
| * [HU2](https://github.com/Xileon310/IV-Project/issues/4) --> Como usuario del sistema, bien mecánico o gestor del taller, se deben poder registrar reparaciones de vehículos, que posteriormente se podrán usar para generar informes en base al material gastado y a las reparaciones más comunes. | ||
| * [HU3](https://github.com/Xileon310/IV-Project/issues/5) --> El administrador debe poder generar un informe en los intervalos de tiempo que desee y consultarlo, sabiendo qué materiales se han gastado (junto con su cantidad) y los modelos de coches reparados, con su respectiva reparación. Servirá para ir perfilando la cantidad de material que se debe pedir periódicamente para ahorrar tiempo y comunicaciones con los proveedores. | ||
| * [HU4](https://github.com/Xileon310/IV-Project/issues/6) --> En caso de necesitar un material diferente en un determinado taller, el usuario (mecánico o gestor) debe poder generar un pedido que será aprobado por el administrador para posteriormente comunicarlo al proveedor. Habrá pedidos genéricos según los informes generados y pedidos que se hagan en situaciones concretas. Un ejemplo de ello sería que no es tan común arreglar un BMW X6 como un peugeout 306. | ||
| * [HU5](https://github.com/Xileon310/IV-Project/issues/7) --> La aplicación debe poder conocer y generar informes de valor, tanto para nuestra empresa como para empresas de automoción, con las reparaciones más comunes y los modelos de coches más propensos a tenerlas que hayan pasado por nuestra red de talleres, puesto que es un software dedicado a grandes empresas. Estos informes pueden ser vendidos a las empresas de automoción por un gran valor, pues les interesará saber cuales son las reparaciones más comunes en sus vehículos. |
There was a problem hiding this comment.
Como esta es la lógica de negocio principal, debería estarse pensando en ella y trabajando en ella desde el primer hito. Voy a comprobar a ver cómo lo tienes organizado.
|
Listo para revisión |
|
Se ha cambiado la idea y por lo tanto la lógica de negocio. Aunque parece una idea de almacenar y buscar, considero que tiene algo más, pues a la hora de generar la información valiosa para la lógica, se aplicarán filtros y cálculos en el algoritmo encargado de ello. Por otro lado, había pensado en dividir el milestone 1 en 3 milestones (uno por cada clase), pero el problema es que una de las clases (Restaurante) depende de otra (MejorPlato), y crear esta otra (MejorPlato) sin haber creado aún el propio restaurante dueño de este plato me parece un poco absurdo desde el punto de vista semántico (que haya una entidad MejorPlato que represente un plato sin que el propio restaurante que lo elabora esté creado). He estructurado los milestones en el orden que creo que se debería desarrollar el proyecto. |
Si es así, tienes que especificar claramente qué cálculos se van a hacer y comprobar que no sean triviales.
Por favor, consulta el concepto de milestone. Son productos mínimamente viables. "Una clase" no es viable, ni es un producto. Lo es si eso avanza el desarrollo. Cada milestone/PMV se construye sobre el anterior, así que si hay "uno por clase" no se está haciendo tal cosa. O se construyen los tres juntos porque no hay forma de hacerlo de otra forma porque son interdependientes, o se construye primero la más simple (normalmente un objeto valor) y a continuación otras más complejas que las incluyan (en hitos sucesivos). Como las incluyen, el PMV incluirá una + las otras. |
There was a problem hiding this comment.
Lo siento, pero tras el cambio
- No hay una lógica de negocio
- No queda claro ni siquiera qué es lo que hace la aplicación. Para esto tienes que describir un serie de "user journeys" qué explica cómo usa cada usuario la aplicación y qué beneficio extrae de ella.
- Ni siquiera tienes un problema a resolver. Sin un problema a resolver, es imposible pensar en una lógica de negocio, y las HUs se limitan a "hacer cosas" sin ninguna relación entre ellas, ni con nada más.
docs/issues.md
Outdated
|
|
||
| ## Usuarios | ||
|
|
||
| - **Restaurante** --> Representa un restaurante, podrá registrar su mejor plato, cambiarlo y actualizarlo. |
docs/issues.md
Outdated
|
|
||
| ## Historias de Usuario | ||
|
|
||
| * [HU1](https://github.com/Xileon310/IV-Project/issues/13) --> El usuario se registrará, bien como Usuario o como Restaurante. |
There was a problem hiding this comment.
Eso no es una historia de usuario. Por favor, consulta el concepto de historia de usuario. En particular, incluye que el usuario debe obtener un beneficio de la lógica de negocio.
|
Listo para revisión. |
|
He vuelto a cambiar la idea, gracias a la conversación que tuvimos en Telegram he llegado a la conclusión de que debo basar la idea en "por qué el usuario va a querer utilizarla" y he dejado a un lado el tema económico (que pensaba que era la lógica de negocio). En este intento de alcanzar el objetivo 1 he pensado en una idea simple pero bastante útil para cualquier usuario. Una aplicación que permita a las personas organizar actividades y unirse a ellas, a su vez, facilitará la comunicación con un propio chat en la app. Por otro lado, en segundo plano, la aplicación puede generar informes de valor que posteriormente se podrán vender a orgnaizaciones que organicen eventos (de publicidad, por ejemplo) o ayuntamientos que quieran organizar actividades para su pueblo/ciudad. Por último, me gustaría preguntarle: ¿M4 sería un PMV? Es decir, me parece importante que la aplicación sea intuitiva y fácil de usar, yo pienso que es un hito que hay que alcanzar para su correcto desarrollo, pero no sé si es algo que ya se supone en una aplicación, o debe mencionarse como tal. |
¿El chat sirve a la lógica de negocio? Entonces no lo pongas.
OK, documéntalo bien en historias de usuario y también ese "generar" cualifícalo un poco para que sea no trivial.
Eso tengo que verlo en el contexto. Los PMVs tienen que describirse explícitamente como tales, incluir código y seguir una secuencia lógica. A partir de ahí, que sean PMV o no es sólo una de las cualidades. |
|
Listo para revisión |
He eliminado la función del chat, es cierto que no alimenta la lógica de negocio, solo otorga facilidades una vez implementada la lógica. Realmente es lo mismo que si el propio organizador de la actividad pone en la descripción un link a un grupo de WhatsApp.
He cualificado el "generar" con el cálculo de estadísticas de las actividades más populares en función de la zona dada. Se ha establecido una periodicidad (normalmente una vez al mes, para dar tiempo a la aplicación a la recolección de información útil) de generación de estos informes en un formato legible para el usuario (.pdf). ¿Cree que está suficientemente cualificado? Otra opción sería la de explicar un poco más el algoritmo que se pretende implementar, en el que debe buscar en la base de datos las diferentes zonas, a continuación, buscar las actividades involucradas por zona y de ahí generar estadísticas como el porcentaje de representación de cada actividad, el número de asistentes, etc.
De momento he dejado este hito, una vez que avance el desarrollo volveremos a debatir si debe estar o no. |
There was a problem hiding this comment.
Por favor, mira la lista de comprobación del objetivo correspondiente (y el anterior).
- Las HUs deben representar algún beneficio para el usuario y estar relacionadas con la lógica de negocio. Si le pones "Ojalá pudiera" delante y no tienen sentido, es que no son HUs. [HU3] - Usuario - Inscripción en una actividad #15 no sería una HU, por ejemplo. No puedes convertir en HU cualquier cosa que tú creas que tienes que hacer para solucionar el problema.
- Los hitos son productos mínimamente viables, descritos como tal. Un "sistema" inespecífico ni siquiera está descrito como un producto.
- Los hitos deben ser diferentes etapas en el desarrollo de un producto, no partes diferentes que ni siquiera dependen una de la otra.
En resumen, repasa los conceptos de lógica de negocio, de HU y de PMV/milestone y trata de mejorar en general tu proyecto.
|
Listo para revisión |
Revisado, he dejado 3 HUs:
Revisado, he eliminado el hito de la interfaz gráfica porque no se retroalimenta de ninguno, se podría implementar tanto al final como al principio de la aplicación. Por otro lado he eliminado la referencia a "sistema", lo he cambiado por "función" que realiza cada actividad. ¿Debería describir exactamente qué hace la función para que lo entienda el desarrollador? Es decir, comentar una especie de pseudocódigo.
Revisado, he dejado los hitos que creo indispensables y los cuales representan diferentes etapas del desarrollo:
|
|
Una función no es un producto, ni es viable. Que los usuarios hagan algo en el hito 0 tampoco es mínimo de ninguna forma. Por favor, consulta el concepto de milestone y la lista de comprobación del hito correspondiente. http://jj.github.io/IV/documentos/proyecto/1.Infraestructura |
Si he entendido bien, el PMV debe ser el producto mínimo viable que puedo entregar a un usuario. De ser así, debería fusionar mi M1 y M2, puesto que no serviría de nada que un usuario registrase actividades si estas no pueden ser ni buscadas ni usadas por los propios usuarios. Por otro lado, no entiendo qué es lo que tengo que dejar claro en la descripción del hito, ¿Una explicación de lo que se pretende conseguir o una descripción de cómo conseguirlo por parte del desarrollador (especificar clases y métodos)?
Esto no lo entiendo bien, entiendo que todo hito debería llevar asociada una historia de usuario. |
|
Listo para revisión |
|
He cambiado el hito 0 para que sea mínimo y las historias de usuario para que sean más precisas y "naturales" |
|
El lun, 25 oct 2021 a las 20:08, José Luis París Reyes (<
***@***.***>) escribió:
Una función no es un producto, ni es viable. Por favor, consulta el
concepto de milestone y la lista de comprobación del hito correspondiente.
http://jj.github.io/IV/documentos/proyecto/1.Infraestructura
Si he entendido bien, el PMV debe ser el producto mínimo viable que puedo
entregar a un usuario. De ser así, debería fusionar mi M1 y M2, puesto que
no serviría de nada que un usuario registrase actividades si estas no
pueden ser ni buscadas ni usadas por los propios usuarios.
No, no es eso. Lo hemos repetido en clase muchas veces. Consulta en el
grupo de Telegram o simplemente mira lo que han hecho tus compañeros.
|
|
@JJ Al final lo he cambiado y lo he dejado listo para revisión. |
There was a problem hiding this comment.
- Los milestones deben ser productos mínimamente viables, no tareas, y mucho menos "un método".
- "Creación de" no describe un producto mínimamente viable. Se debe describir con precisión qué producto es y qué espera que haga.
- Antes de crear la clase habrá que decidir qué incluye esa clase y qué estructuras de datos necesita. También es posible que antes que "actividad" haya que crear otras clases. Por ejemplo ¿una actividad incluye un sitio?
|
Listo para revisión, he concretado más los hitos y vuelto a cambiar las HUs |
|
Listo para revisión, he actualizado las HUs de forma que el usuario resuelva su problema en cada ocasión y obtenga un beneficio de la lógica de negocio. |
There was a problem hiding this comment.
Voy a aprobar tentativamente, pero realmente tendrás que mejorar esto para que se pueda programar el objetivo siguiente por parte de @albertotc99. La #14 no es una historia de usuario, sino simplemente un issue. Los milestones tienen que ser productos mínimamente viables.
Por favor, pon explícitamente las 10 preguntas del objetivo 1 y respóndelas explícitametne si quieres que se haga el objetivo 2 correctamente. @albertotc99 controlará que lo hayas hecho correctamente.
Se corrige error sintáctico. Closes #12
Listo para revisión