Se trata de empezar a planificar el proyecto que se va a ir elaborando durante este curso, creando los hitos para organizar el trabajo en el mismo. Lo esencial en este objetivo es entender qué tipo de proyectos se deben plantear para esta asignatura, describirlo correctamente en el repositorio en GitHub y documentar el proyecto elegido y los pasos que se van a dar en el mismo.
Se tendrá que haber entregado sin errores el objetivo 0 antes de poder avanzar a este.
Hay que desarrollar la idea en una serie de user journeys; estos en una serie de perfiles de usuario o personas, y a continuación crear una serie de historias de usuario (HU). Se crearán también una serie de hitos en el desarrollo o milestones, y habrá que asignar alguna HU al milestone 0 para poder comenzar a trabajar.
El desarrollo ágil está centrado en el cliente, e incluye una serie de metodologías o buenas prácticas para poder llegar de los deseos del cliente a la expresión de los mismos y de ahí, pasando por una serie de pasos intermedios, al código que lo implementa.
En este objetivo se busca que se entienda el sistema de desarrollo ágil en el que se van elaborando, por iteraciones, versiones cada vez más avanzadas de un proyecto/producto.
Este sistema, como todos los sistemas de desarrollo, te ayuda a responder a estas dos preguntas
Vamos a plantearnos en este objetivo, sobre todo, la respuesta a la primera pregunta, es decir, plantear, a partir de la comprensión y la expresión de las necesidades del cliente, la infraestructura del proyecto de forma que, en cada momento, se sepa cómo uno mismo o la persona que se encargue de ello se ponga a trabajar inmediatamente en lo que sea necesario a continuación.
Un user journey se correspondería con la fase de empatizar de design thinking, y es un “viaje del usuario”. Es decir, qué hace el usuario desde que decide que va a usar la aplicación hasta que deja de usarla. En este viaje se tendrían que incluir detalles sobre
No es lo mismo que se use desde un móvil que desde un portátil, o que se tenga que usar con las manos libres. En todos los casos, hay implicaciones de diseño que pueden llegar hasta la parte más profunda de la arquitectura.
La implementación de historias de usuario se hará en una serie de issues, que se agruparán en una serie de hitos o milestones.
Hay que empezar a planificar la aplicación que resolverá el problema planteando:
En esta asignatura se desarrolla un proyecto. Este objetivo pretende cubrir la organización de ese proyecto. Por lo tanto, hay que tratar de preguntarse, tras la elaboración de HUs y milestones, si una persona ajena al mismo sería capaz de comenzar el desarrollo en base a la información proporcionada.
En este objetivo se empiezan a contestar las dos preguntas fundamentales de cualquier metodología de desarrollo:
La metodología de esta asignatura está basada en la realización incremental, a lo largo de los hitos de la misma, de un proyecto personal basado en la nube, que sería (en general, o podría ser) parte de una aplicación más grande. Por ello hay que empezar por el principio: perfilar ese proyecto como solución al problema o como desarrollo de la idea que se ha planteado en el objetivo 0.
El proceso, por tanto, que se suele seguir (y el que se tiene que seguir para alcanzar este objetivo) es el siguiente:
Las historias de usuario son fundamentales, porque si no se sabe lo que el usuario quiere hacer y ver, no se pueden hacer pruebas para comprobar que efectivamente eso se está haciendo correctamente, lo que correspondería a la pregunta dos que se ha hecho anteriormente. Estas especificaciones, en forma de historias de usuario, se tendrán que documentar en un issue de GitHub. Los issues del proyecto que sean historias de usuario tienen que tener dos características:
[HUxxx]
en la descripción del issue para que se
identifique claramente que se trata de ese tipo de issue. No todos
los issues tienen que ser historias de usuario, pero los issues que
sirvan para ir avanzando en la implementación de una historia de
usuario se referirán siempre a la historia de usuario
correspondiente.label
user-stories
. Esta etiqueta no es de las que hay
por defecto en los proyectos de GitHub, así que habrá que
añadirla.Estamos en un proyecto que se irá desarrollando a lo largo de la asignatura, y esta es una parte esencial, la planificación del mismo. Esta planificación tendrá que servir para trabajar ya en el siguiente objetivo, pero también en todos los objetivos siguientes. Los entregables/productos mínimamente viables se repartirán entre varios objetivos, pero tendrán eventualmente que entregarse, y las historias de usuario se tendrán que desarrollar en issues (que expresan problemas) para eventualmente expresarse en código, que será lo que se entregue en los diferentes objetivos.
Por tanto, es esencial que estos milestones e historias de usuario contengan toda la información suficiente para que alguien, que será otra persona, se pueda poner a trabajar.
Se pueden consultar el siguientes tema del curso 0 sobre cómo especificar los requisitos y qué hacer para diseñar los primeros pasos de una aplicación y cómo diseñar las personas que van a usar la aplicación.
En este vídeo se explica el concepto de producto mínimamente viable/milestone.
Los recursos aportados por los estudiantes de la asignatura están en este fichero. Puedes añadir algunos más que te hayan ayudado si lo deseas.
Como se va a empezar a revisar los PRs de los compañeros, conviene que mires este material sobre le mismo.
Como en toda esta asignatura, siempre se incorporará código al repositorio propio usando pull requests. Todo el material necesario para alcanzar a este objetivo estará en un PR, que tendrá que ser aprobado por el profesor (lo que indicará que el objetivo se ha alcanzado). En este objetivo 1 se anima a los estudiantes a que comenten, e incluso aprueben, PRs de otros compañeros, aunque la aprobación definitiva tiene que venir del profesor.
Importante: el título de este pull request *tiene que incluir la cadena
[IV-22-23]
para que pueda filtrar fácilmente los mensajes recibidos. Cuando se
hagan mejoras en el PR, el estudiante deberá pedir explícitamente revisiones
adicionales con un comentario en el mismo que diga “Listo para revisión”.
Subir los fuentes a GitHub y añadir al fichero el nombre del proyecto, el autor y un enlace al pull request mediante el cual se quiere alcanzar el objetivo y hacer un pull request al repositorio en el que se encuentra ese fichero.
Los avances en todos los aspectos de cara al público del proyecto se
reflejarán en el fichero README.md
del mismo, que tendrá que estar
estructurado como una descripción del proyecto, y con enlaces a
información adicional requerida por el profesor para su
corrección. Esta información adicional deberá estar enlazada desde
el README, y en un directorio docs
escrita en Markdown.
El README no debe incluir pantallazos ni nada que no sea estrictamente descripción del proyecto en el hito en el que se encuentre en ese momento.
Como mínimo, y para pasar los tests, esta entrega incluirá
docs
donde se pondrá material adicional (que se
tendrá que enlazar desde el README
en el apartado que se esté
corrigiendo en ese momento).README
tiene que seguir reflejando el estado del proyecto. En este caso,
habrá al menos que enlazar cómo se ha planificado el mismo con algún tipo de
justificación adicional que sea conveniente.Se ruega no hacer push a la rama que ya se haya revisado hasta que no se hayan hecho todas las revisiones solicitadas por el profesor. Adicionalmente, se puede pasar el PR a “borrador” (draft) y no revertir a “listo para revisar” hasta que no se haya hecho.
En general, no será producto si no implica, para alcanzarlo, cambios en el repositorio, y se describe como tal, es decir, como algo físico, que está empaquetado y se va a enregar al resto del equipo o al cliente. En el repositorio hay ficheros de diferente tipo, pero generalmente se tratará de código organizado siguiendo las buenas prácticas.
No es lo único necesario para que sea un producto; tendrá que decirse también ese código (o conjunto de código y otros artefactos) cómo se tiene que entregar y qué lo hace válido.
Que sea lo mínimo que resuelve los issues correspondientes está implícito, pero también hay que tenerlo en cuenta a la hora de describirlo con claridad y precisión, para que quede claro cuál es el ámbito de acción de cada hito.
Nada que no lo sea. Un diseño no es un producto (lo será un fichero en un formato estándar que se pueda usar directamente); un modelo tampoco (lo será una implementación del modelo, presentada como se ha comentado en la pregunta anterior). Una estructura de datos o función no son un producto. Tendrá que describirse claramente cómo se va a entregar ese código para que constituya un producto.
En este objetivo, deberás comprobar que la respuesta a estas preguntas es positiva. Ante la duda o la posible ambigüedad, explica claramente qué has hecho en ese aspecto. Si no lo es, tendrás que pensar que alguno de los conceptos no los entiendes muy bien y tendrás que replantearte la formulación correspondiente. Están puestas aquí para que las copies y pegues en el cuerpo del PR que hagas en tu propio repositorio.
Si te toca revisar el objetivo de un compañero/a, esta lista de comprobación tiene ser la guía para que compruebes si el compañero/a lo ha hecho correctamente.
* [ ] ¿Las historias de usuario y los milestones constituyen una guía
suficiente para poder comenzar el desarrollo de un proyecto?
* [ ] ¿Los milestones están ordenados correctamente, de forma que el 1 o
0 sea lo primero que hay que empezar a publicar?
* [ ] ¿Todos los milestones se construyen sobre el anterior, teniendo un
orden lógico el desarrollo?
* [ ] ¿El milestone 0 tiene asignada alguna historia de usuario?
* [ ] ¿El milestone 0 corresponde con lo mencionado varias veces en
clase, y en concreto con lo que se solicita en el objetivo
siguiente?
* [ ] ¿Todos los milestones describen correctamente un producto, y no un
concepto vago, una funcionalidad o una tarea?
* [ ] ¿Los milestones son graduales, o hay un salto grande entre ellos?
* [ ] ¿Los milestones iniciales son internos, y hay a continuación milestones o
productos externos?
* [ ] ¿Los milestones son mínimos, es decir, incluyen un producto
mínimamente viable para poder avanzar?
* [ ] ¿El milestone 0 es mínimo *y* viable?
* [ ] ¿Se indica claramente cómo comprobar la viabilidad del PMV de cada hito? Es
decir, ¿se dice qué requisitos técnicos tiene que cumplir el producto de
cada hito?
* [ ] ¿Entre dos milestones consecutivos, no hay ningún PMV posible o por el
contrario podrían desarrollarse muchas posibles etapas internas o externas
de un proyecto?
* [ ] ¿He tenido en cuenta en las historias de usuario que se trata de un
proyecto que se desplegará en la nube?
* [ ] ¿Están descritos todos los conceptos mencionados en las HUs con
suficiente claridad, generalmente en documentos aparte?
* [ ] ¿Tienen coherencia suficiente las historias de usuario, y en caso
de que no lo tengan, se ha escrito un *user journey* para
aclararlo?
* [ ] ¿Todas las historias de usuario representan un beneficio para el
mismo y se relacionan con la lógica de negocio? Es decir, ¿los usuarios
*desean* hacerlo o tú deseas que el usuario te lo pida para hacerlo?
En general, la pregunta sería: si entregara estos hitos y milestones a otra persona, ¿sería capaz de ponerse a desarrollar empezando por el primero y creando issues para el desarrollo del mismo?
Se puede consultar la presentación sobre historias de usuario y sobre productos mínimamente viables.
Se habrá alcanzado este objetivo si pasa los tests automáticos, y:
README.md
(y también descritos en el PR).En todo caso, y como en todos los objetivos, se tendrá que esperar a que el profesor apruebe el PR en el repositorio del proyecto para considerarlo alcanzado.
El alcanzar este objetivo avanzará, en principio, 7.5% del apartado correspondiente de la asignatura.
En el curso 2021-22, el 50% de los estudiantes entregó este objetivo en 12 días a partir del comienzo del curso. El 75% necesitó 13 días.
Ningún estudiante que aprobó en la convocatoria ordinaria tardó más de 10 semanas en superar este objetivo. A partir de la 9ª semana del comienzo, sería mejor que planificaras el resto de la asignatura para la convocatoria extraordinaria si todavía no lo has superado.
A partir de este objetivo, se pondrá en práctica la asignación aleatoria de revisores de cada PR entre los que ya lo hayan superado. Cuando se haga el PR en el repositorio de la asignatura, se sacarán hasta cinco nicks aleatoriamente entre las personas que hayan superado ya el objetivo. No es obligatorio hacerlo para quien se elija, pero sí se considerará positivamente en la nota final en el apartado de aprendizaje autónomo; en este objetivo, además, es especialmente necesario que se haga esta revisión, así que se pide que realicéis al menos dos revisiones para considerar totalmente superado este objetivo (aparte de que se apruebe el pull request).
La aprobación final del objetivo es cosa del profesor, pero las revisiones que te hagan los compañeros podrán ayudar a que avances hacia la consecución del mismo en este objetivo y el resto. En este en concreto, como se ha repetido, hace falta que dos estudiantes lo revisen y aprueben antes de que sea revisado y aprobado por el profesor.
Si has terminado, comienza con el siguiente.