Objetivo 1: Estructura general y planificación del proyecto

Descripción

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.

Prerrequisitos

Se tendrá que haber entregado sin errores el objetivo 0 antes de poder avanzar a este.

TL;DR

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.

Introducción

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

  1. ¿Qué tengo que hacer ahora?
  2. ¿Es correcta la solución que he planteado al problema que estoy resolviendo?

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.

Explicació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:

  1. Historias de usuario.
  2. Productos mínimamente viables, cada uno en su milestone.
  3. Las HUs estarán asignadas a un milestones, aunque se podrán ir moviendo durante el avance del proyecto.

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:

  1. ¿Qué hago ahora? Habrá que empezar por el milestone 0, seguir por los demás.
  2. ¿Lo que hago está bien? Estará si es viable según lo definido en cada producto mínimamente viable, y en las historias de usuario se dirá qué es lo que quiere el cliente; siempre habrá que avanzar para satisfacer al cliente.

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:

  1. Partir del problema que se quiere resolver, objetivo que se tiene que haber alcanzado previamente.
  2. Seguir un proceso para entender los diferentes tipos de usuario que necesitan una solución a ese problema, que serán siempre usuarios que obtendrán algún tipo de beneficio con la solución del mismo. Por ejemplo, un usuario quiere adquirir complementos que sean adecuados para las prendas ya adquiridas. El beneficio que quiere obtener es ese: los complementos más adecuados. Otra usuaria quiere saber cuales son las tendencias en búsqueda de complementos para diseñar una estrategia de marca. Ese es el beneficio que quiere obtener, y habrá que satisfacerla.
  3. Los deseos de estos usuarios, es decir, qué quieren hacer u obtener con la aplicación, se tienen que resumir en las historias de usuario. Tendrá que crearse alguna historia de usuario, especialmente las que se consideren fundamentales para comenzar el desarrollo. Las historias de usuario siempre expresan deseos y beneficios, están relacionadas con la lógica de negocio y están en el dominio del problema.
  4. Finalmente, los diferentes productos que se van a entregar a estos clientes (o al equipo previo a su entrega al cliente) se tendrán que describir en una serie de hitos o milestones, en cada uno de los cuales se entregará un producto mínimamente viable. El desarrollo ágil se basa en un método iterativo en el que se mejora un producto, siempre con la aprobación del usuario. Por lo tanto, tendrá que haber al menos un par de milestones que refleje los diferentes productos que se van a entregar y que vayan agrupando las historias de usuario y los diferentes issues que se saquen de las historias de usuario.

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:

Este objetivo es fundamental para el resto de la asignatura

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.

Información adicional

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.

Entrega de la práctica

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á

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.

Preguntas frecuentemente preguntadas

¿Qué se considera un producto?

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.

¿Qué no se considera un producto?

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.

Listas de comprobación

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.

Sobre los milestones

* [ ] ¿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?

Sobre las historias de usuario

* [ ] ¿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?

Resumen

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?

Material adicional

Se puede consultar la presentación sobre historias de usuario y sobre productos mínimamente viables.

Objetivo alcanzado

Se habrá alcanzado este objetivo si pasa los tests automáticos, y:

  1. Se siguen usando las buenas prácticas.
  2. Se muestra claramente que se ha comprendido el objetivo de la asignatura y que el proyecto, que aquí se tiene que comenzar a organizar y desglosar, corresponde a este objetivo.
  3. Se han creado historias de usuario escritas para empezar a trabajar a partir de ellas, y están reflejadas en los issues de GitHub que estén marcados como se ha indicado más arriba; por supuesto, enlazadas desde el README.md (y también descritos en el PR).
  4. Las historias de usuario están agrupadas en (al menos) un par de hitos o milestones (y también están descritos en el PR).
  5. Si los milestones describen productos mínimamente viables y están ordenados correctamente.
  6. Al menos dos compañeros/as han aprobado este PR (con excepciones en las primeras entregas).

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.

Valoración

El alcanzar este objetivo avanzará, en principio, 7.5% del apartado correspondiente de la asignatura.

Estimación de tiempo

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.

Límite

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.

Corrección entre pares

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.

A donde ir desde aquí

Si has terminado, comienza con el siguiente.