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 y describiendo las historias de usuario, o qué es lo que cada cliente espera alcanzar con el proyecto. 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.
Como en el objetivo anterior, se aconseja vivamente la asistencia a clase hasta la superación del mismo, para poder resolver sobre la marcha las dudas que se planteen, recibir explicaciones genéricas que puedan ayudar a la comprensión del mismo, así como sus diferentes subobjetivos. También se podrá explicar conceptos anteriores a la asignatura que no estén del todo claros.
Se tendrá que haber fusionado por parte del profesor 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 los hitos (milestones) iniciales en el desarrollo, y habrá que asignar alguna HU al milestone 0 para poder comenzar a trabajar en el objetivo siguiente.
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.En programación no se empieza a hacer lo primero que se le ocurre a uno; como se ha dicho más arriba, se tiene que aplicar una metodología que nos ayude en cada momento a decidir qué se va a hacer a continuación. Pero se comienza por algún lugar específico, que permita al equipo ir avanzando y cubriendo etapas de desarrollo; cada una de esas etapas avanza en la comprensión del problema y se acerca más a la solución que se entrega al usuario.
En general, estos hitos los elaborará un product manager o gestor de producto en una empresa de mediana complejidad; sin embargo, es conveniente que se entienda en qué consisten y cómo se pueden llevar a cabo.
Los milestones son herramientas para comenzar a trabajar y organizar el trabajo con un objetivo claro en cada fase, lo que ocurrirá ya en el siguiente objetivo; por eso habrá que plantear los suficientes para poder hacerlo, pero nunca más de los que se puedan abordar en la asignatura.
En general, en desarrollo ágil se van decidiendo cuales son los siguientes productos mínimamente viables durante el desarrollo del anterior, así que programas más allá de los dos milestones siguientes no merece la pena.
Como todo el resto de los objetivos de aprendizaje, no se trata de un ejercicio académico, se trata de que mostréis que sois capaces de planificar un proyecto, dividiéndolo en diferentes etapas, y que estas sean realistas y alcanzables dentro del marco temporal de la asignatura.
En la mayor parte de los casos, no se podrá resolver los problemas que se expresan en las historias de usuario, porque no se hará ningún interfaz de cara al mismo. Sin embargo, con los milestones diseñados se tratará de probar que efectivamente se sabe avanzar hacia eso.
Los productos son siempre entregables. No son conceptos, hay que explicar qué es lo que se va entregar, cómo se sabe que es válido y el soporte concreto que va a tener. Lo esencial, en todo caso, es leer atentamente los milestones que se han entregado y verse uno mismo llevando a cabo el desarrollo del producto, sin ningún (o muy poco) material adicional.
Los milestones generalmente se van a numerar desde el cero, donde el cero será uno “interno”, el primero que se va a llevar a cabo.
Y en este milestone lo fundamental será entender el problema, porque sin una modelización del mismo será imposible comenzar a programarlo. Este milestone incluirá todo lo necesario para poder comenzar a trabajar con el siguiente, en el que se implementa la lógica de negocio; por eso lo esencial es incluir como entregable en el mismo todo lo que necesitemos en ese paso siguiente.
Como si hubiera alguno que no lo fuera…
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-23-24] 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
READMEno 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.
Igual que en el objetivo anterior, hay un tiempo limitado para hacer la entrega; por eso se aconseja que se asista a clase y se utilice el tiempo de la misma para trabajar en el objetivo, de forma que el profesor pueda guiar hacia su consecución, corregirlo sobre la marcha tras la entrega y admisión del PR, o dar consejos o sugerencias de material adicional. No es buena idea abandonar la clase cuando terminen “las explicaciones”, porque se harán explicaciones en clase en cualquier momento según lo solicite uno o varios estudiantes.
En el siguiente objetivo hay que trabajar en equipo, por lo que es esencial que se llege a él de forma más o menos simultánea.
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.
A partir de 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 qué
lo hace válido, 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.
El plazo aconsejado para hacer la primera entrega termina 4 semanas después del comienzo de las clases. En años anteriores,
Ningún estudiante que aprobó en la convocatoria ordinaria en cursos anteriores 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. No es obligatorio hacer la revisión para quien se elija, pero sí se considerará positivamente en la nota final en el apartado de aprendizaje autónomo.
Que hagáis estas revisiones es fundamental para que entendáis bien el concepto de historia de usuario, así como para poder elegir para el próximo objetivo algún proyecto con el que tengáis ya cierta familiaridad.
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 al menos dos estudiantes lo revisen y aprueben antes de que sea revisado y aprobado por el profesor.
Si has terminado, comienza con el siguiente.