5oMA R3 - audio G12

The project involves allowing citizens to manage the deterioration of urban infrastructure in public spaces, which often takes time to detect and resolve. To achieve this, a stack of user stories was created, ensuring they met certain requirements and quality criteria. The user stories were also designed to allow for cohesion and integration between different functions. In the second part of the project, four relevant user stories were selected, including reporting issues, managing incidents, and receiving notifications for maintenance teams. These stories aim to develop the base application and fulfill the initial requirements within a short timeframe. Se nos pide realizar una pila de producto y el mínimo producto viable para un proyecto. El proyecto se trata de que los ciudadanos puedan gestionar el deterioro del inmobiliario urbano en vías y espacios públicos en las ciudades, que tardan un tiempo en ser detectados, identificados y resueltos. En este proyecto lo que hicimos fue seleccionar 20 historias de usuario y estas 20 historias de usuario las construimos de la siguiente manera. Las construimos de modo que cumplieran con unos requisitos como son los siguientes, que tuvieran un tipo de usuario, que tuvieran unas características y que tuvieran las necesidades o el beneficio. Los tipos de usuario son esos colectivos, esos grupos de partes interesadas. Las características son las prestaciones que se van a implementar y las necesidades es lo que se está satisfaciendo con esa creación. Estas historias de usuario también cumplieron con un criterio que se llama INVES, que asegura la calidad en la escritura de las historias de usuario. ¿Qué quiere decir esto? Que son historias independientes, negociables, valiosas, estimables, pequeñas y comprobables. De esta manera construimos un producto mínimo viable para una necesidad que debía ser construida en un mes, asegurando la calidad de las historias de usuario. Estas historias de usuario también tienen la característica de que se pueden trabajar entre sí, que permiten que el grupo tenga una cohesión y que haya una integración entre las funciones. En esta segunda entrega hemos adicionado historias de usuario más relevantes para empezar el primer sprint de la aplicación. Las historias más relevantes para nosotros han sido que cualquier ciudadano quiera reportar esos despectos en la vía pública a través de un sistema de incidencia, donde las administraciones públicas lo conozcan, que el equipo de mantenimiento tenga su propio portal de gestión de incidencias y también una red de notificaciones, y asimismo que el equipo de gestión de incidencias también tenga su propio portal, donde ellos asignen esas incidencias a los equipos de mantenimiento, según disponibilidad y ubicación. Con esta selección de historias lo que pretendemos es desarrollar la aplicación base para que los ciudadanos, el equipo de mantenimiento, el equipo de gestión, realicen los primeros pasos, los primeros requerimientos mínimos, como puede ser que entre estas tres partes interesadas interactúen con la base de datos de las incidencias. Por tanto, centrándonos en las funcionalidades principales, prevemos que esta entrega va a ser posible a corto plazo y que nos permite asumir un riesgo factible para que estas funcionalidades sean implementadas en torno a quince días. En base al segundo ejercicio propuesto, que es en una historia que realmente se puede dividir por muchas más historias, lo hemos hecho de la siguiente manera, centrándonos en la historia número 7, que es que el equipo de mantenimiento quiere conocer la gravedad de las incidencias para organizar estas periodas de trabajo. En ese sentido, la hemos desglosado en cinco historias adicionales. Consideramos que esta primera historia es interesante, ya que la hemos considerado como importante dentro de nuestro primer conjunto de historias. El desglose de estas historias adicionales a la historia 7 creemos que son factibles y que cumplen con los requerimientos, ya que cada historia es independiente, es decir, se pueden entregar de maneras separadas. A su vez, son pequeñas, lo cual hace que el plazo de entrega no se vea afectado. También es importante, de cara al impacto de los ciudadanos, ya que el equipo de gestión de mantenimiento tenga perfeccionada y cada vez más avanzada sus funcionalidades, impacta en las personas, que al final es lo que se usa de la aplicación, que las personas se sienten satisfechas con el mobiliario de la ciudad. En el día de hoy les hablaremos de un caso práctico de un proyecto SCRUM. Se nos pide realizar una pila de producto y el mínimo producto viable para un proyecto. El proyecto se trata de que los ciudadanos puedan gestionar el deterioro del mobiliario urbano en vías y espacios públicos en las ciudades, que tardan un tiempo, es decir, deben ser detectados, identificados y resueltos. En este proyecto lo que hicimos fue seleccionar 20 historias de usuario, y estas 20 historias de usuario las construimos de la siguiente manera. Las construimos de modo que cumplieran con unos requisitos como son los siguientes, que tuvieran un tipo de usuario, que tuvieran unas características y que tuvieran las necesidades o el beneficio. Los tipos de usuario son esos colectivos, esos grupos de partes interesadas. Las características son las prestaciones que se van a implementar y las necesidades es lo que se está satisfaciendo con esa creación. Estas historias de usuario también cumplieron con un criterio que se llama INVES, que asegura la calidad en la escritura de las historias de usuario. ¿Qué quiere decir esto? Que son historias independientes, negociables, valiosas, estimables, pequeñas y comprobables. De esta manera construimos un producto mínimo viable para una necesidad que debía ser construida en un mes, asegurando la calidad de las historias de usuario. Estas historias de usuario también tienen la característica de que se pueden trabajar entre sí, que permiten que el grupo tenga una cohesión y que haya una integración entre las funciones. En esta segunda parte del trabajo hemos desarrollado el script inicial para el desarrollo de la aplicación. En este caso hemos seleccionado cuatro historias relevantes que nos permiten la aprobación del producto. En este caso, la primera es cómo un ciudadano reporta los desperfectos de la vía pública a través del sistema de incidencia dentro de la aplicación para que las aplicaciones públicas sean conocidas y actúen. Luego también tenemos la historia seis, que como equipo de mantenimiento tiene un sistema que permite gestionar las incidencias y la mejora de ésta. Y, asimismo, también tenemos la historia diez relacionada con el equipo de mantenimiento para que reciba notificaciones sobre las incidencias cerca de ésta en la zona de trabajo.