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 ete curso, creando los hitos para organizar el trabajo en el mismo. Lo esencial en este hito 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 alcanzado el objetivo 0 antes de poder avanzar a este.

TL;DR

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 cada una asignada a un milestone.

Explicación

La metodología de esta asignatura está basada en la realización incremental, a lo largo de los objetivos de la misma, de un proyecto personal 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 que se ha planteado en el objetivo 0.

En este objetivo se busca es 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. El proceso 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 quieren resolver ese problema. Habrá que perfilar estos tipos de usuario (Por favor, evitar usuarios tipo “administrador” que tendrá que haber (casi) siempre. Por ejemplo, en un sitio de ventas, habrá perfiles tipo “comprador” y perfil tipo “vendedor”. Estos usuarios tendrán que documentarse para alcanzar este objetivo).
  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.
  4. Finalmente, los diferentes productos que se van a entregar a estos usuarios se tendrán que describir en una serie de hitos o milestones. 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. 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:

Usar un repositorio de forma correcta no solo permite organizar el trabajo de desarrollo de forma más eficiente, sino que también contribuye a que sea más fácil colaborar con él y a la creación de buenos hábitos de trabajo colaborativo. Hay una serie de buenas prácticas, que incluyen las comentadas en el hito anterior, pero que además, en este hito, deberán de tener en cuenta lo siguiente.

Avanza la tarea #1 porque se ha hecho x

Estas buenas prácticas se tendrán que seguir en todos los hitos subsiguientes del proyecto, empezando por este, y no hacerlo se penalizará. También se testearán a la hora de hacer el envío. Es decir, el hito actual será ya un hito del proyecto y dentro del hito tendrán que incluirse los issues que corresponda.

Información adicional

Se pueden consultar los siguientes temas del curso 0:

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.

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.

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 hitos 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á

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 que estén marcados como se ha indicado más arriba; por supuesto, enlazadas desde el README.

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.