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 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 alcanzado el objetivo 0 antes de poder avanzar a este.
Hay que desarrollar la idea en una serie de user journeys, estas en una serie de perfiles de usuario o personas, y a continuación crear una serie de historias de usuario. La implementación de historias de usuario tendrá que agruparse en una serie de hitos o milestones.
Hay que empezar a planificar la aplicación que resolverá el problema planteando:
- Historias de usuario.
- Productos mínimamente viables, cada uno en su milestone.
- Las HUs estarán cada una asignada a un milestone.
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.
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.
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. El proceso que se tiene que seguir para alcanzar este objetivo es el siguiente:
- Partir del problema que se quiere resolver, objetivo que se tiene que haber alcanzado previamente.
- 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).
- 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.
- 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:
- Incluir
[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. - Usar un
labeluser-stories. Esta etiqueta no es de las que hay por defecto en los proyectos de GitHub, así que habrá que añadirla.
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 objetivo anterior, pero que además, en este objetivo, deberán de tener en cuenta lo siguiente.
-
Trabajar siempre con hitos (milestones) y órdenes de trabajo (issues) en el repositorio. En este caso, el hito será la entrega de la práctica y las órdenes de trabajo las diferentes tareas necesarias para terminar el hito. Cada milestone contendrá, al menos, una historia de usuario (y los issues relacionados con la misma).
-
Todo commit debe corresponder a una tarea que se haya establecido en el repositorio, es decir, una historia de usuario o tarea que forme parte de ella. Toda tarea se cierra con un commit (simplemente incluyendo closes #[tarea], por ejemplo
closes #1si es el primer issue o tarea. Para referenciar una tarea, simplemente se pone el número de la tarea, por ejemplo
Avanza la tarea #1 porque se ha hecho x
-
No incluir en el repositorio ningún fichero que pueda ser generado a partir del mismo: incluir un procedimiento para generar tales ficheros. Por ejemplo, ningún fichero compilado a partir de otros, o un PDF generado a partir de los ficheros LaTeX, o los ficheros generados por los entornos virtuales de ciertos lenguajes. Esos ficheros, además, se tendrán que incluir en
.gitignorepara que no aparezcan como "no seguidos" cuando se hagagit status. -
No incluir en el repositorio ningún código que no sea propio; si se va a hacer, se incluirá en el mismo el procedimiento para incluir ese código en la compilación, generalmente en forma de fichero de requisitos. Si el código sobre el que se va a trabajar es directamente de otro repositorio, hacer un fork del mismo, no copiar los ficheros. La estructura de un repositorio siempre tiene que respetarse, y la mejor forma de atribuir correctamente los cambios es trabajar sobre el repositorio original modificado.
-
No incluir ficheros binarios en el repositorio, aunque se necesiten en el proyecto. Para ello están los releases. En general los ficheros binarios son generados, así que esto es una simple consecuencia de lo de arriba.
-
Si se va a usar algún proyecto anterior, hacer un fork del mismo, no copiar los ficheros y subirlos como contribución propia. Las contribuciones, siempre que sea posible, deben estar firmadas por la persona que las haya creado. Esto incluye si usas el mismo proyecto que usaste en esta asignatura en años anteriores. En el directorio donde se encuentren esas contribuciones tendrá que ponerse claramente la licencia del código (y tendrá que ser compatible con la licencia que se elija para nuestro proyecto). Esto es irrelevante en este objetivo, ya que no hay código, tendrá relevancia en los siguientes.
Estas buenas prácticas se tendrán que seguir en todos los objetivos subsiguientes del proyecto, empezando por este, y no hacerlo se indicará al estudiante para su mejora. También se testearán a la hora de hacer el envío.
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.
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 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-21-22] 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á
- Un subdirectorio
docsdonde se pondrá material adicional (que se tendrá que enlazar desde el README en el apartado que se esté corrigiendo en ese momento). - Al menos una "historia de usuario" en un issue de la forma descrita más arriba, es decir, con la cadena HU en la descripción y la etiqueta user-stories.
- Uso de issues para añadir siempre código al repositorio. Los issues se cerrarán, cuando se hayan cumplido, siempre con un commit. En este objetivo no hay que añadir todavía ningún código, queda fuera del ámbito del mismo, pero es una práctica que hay que respetar a partir de ahora.
- Varios milestones, los que se considere suficientes. Para pasar los tests tiene que haber al menos dos.
- El
READMEtiene 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 este objetivo, deberás comprobar que la respuesta a estas preguntas es positiva. 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.
- ¿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 en las mismas?
- ¿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 habrá alcanzado este objetivo si pasa los tests automáticos, y:
- Se siguen usando las buenas prácticas.
- 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.
- 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. - Las historias de usuario están agrupadas en (al menos) un par de hitos o milestones.
- Si los milestones describen productos mínimamente viables y están ordenados correctamente.
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.
Si has terminado, comienza con el siguiente.