🧠 Objetivo 1: Estructura general y planificación del proyecto

🎯 DE UN VISTAZO / AT A GLANCE

• Objetivo Principal: Planificar el proyecto del curso: crear historias de usuario (HU) que expresan lo que quiere el cliente, y agruparlas en milestones (hitos) que organizan el trabajo por entregas incrementales.
• Entregable: Un Pull Request con el título que incluya [IV-26-27], que contenga: historias de usuario en issues, milestones en GitHub, un directorio docs, un README.md actualizado con enlaces, y una entrada añadida a este fichero (nombre del proyecto, autor, enlace al PR).
• Carácter: ⚠️ BLOQUEANTE. No superarlo equivale a No Apto en la convocatoria correspondiente.
• Prerrequisitos para la entrega: El objetivo 0 debe haber pasado ya los tests del repositorio de la asignatura.

📋 Lista de Tareas Paso a Paso

Fase 1: Preparación y Comprensión

• Paso 1.1: Confirmar que el objetivo 0 ya ha pasado los tests. Si no es así, no se puede avanzar a este objetivo.
• Paso 1.2: Leer y entender qué es un user journey (viaje del usuario): qué hace el usuario desde que empieza a usar la aplicación hasta que deja de usarla, incluyendo frecuencia de uso, contexto, dispositivo desde el que se usa y pasos necesarios para resolver su problema.
• Paso 1.3: Entender el concepto de personas (perfiles de usuario reales, con nombre) que se van a beneficiar de la aplicación.
• Paso 1.4: Entender qué es una historia de usuario (HU): expresa un deseo y un beneficio del usuario, está relacionada con la lógica de negocio y en el dominio del problema.
• Paso 1.5: Entender qué es un milestone (hito): agrupa issues/HUs y corresponde a un producto mínimamente viable (PMV) entregable, no a un concepto vago ni a una simple tarea.
• Paso 1.6 (opcional pero recomendado): Revisar el material de apoyo:
  • Tema de diseño y requisitos del curso 0
  • Diseño de personas
  • Vídeo: concepto de producto mínimamente viable / milestone
  • Presentación sobre historias de usuario
  • Presentación sobre productos mínimamente viables

Fase 2: Desarrollo y Ejecución

• Paso 2.1: Escribir uno o varios user journeys para entender al usuario y su problema.
• Paso 2.2: Definir las personas (perfiles de usuario) implicadas, pensando en una persona real concreta si ayuda a concretar.
• Paso 2.3: Crear al menos una historia de usuario (HU) como issue de GitHub. Cada issue de tipo HU debe cumplir:
  • Incluir [HUxxx] (numeración empezando en 1) en la descripción del issue.
  • Usar la etiqueta (label) user-stories (hay que crearla, no viene por defecto en GitHub).
• Paso 2.4: Crear los milestones iniciales del proyecto:
  • Se numeran desde el 0 (el milestone 0 es “interno”, el primero que se lleva a cabo).
  • Tiene que haber al menos dos milestones para pasar los tests.
  • El milestone 0 corresponde a entender el problema y modelizarlo (enlaza con el objetivo 2).
  • El siguiente milestone incluye la lógica de negocio y la infraestructura de comprobación automática (enlaza con el objetivo 4).
  • No conviene planificar más de dos milestones por delante (el desarrollo ágil decide los siguientes PMV sobre la marcha).
• Paso 2.5: Asignar al menos una HU al milestone 0, para poder empezar a trabajar en el siguiente objetivo.
• Paso 2.6: Crear un subdirectorio docs en el repositorio para material adicional, enlazado desde el README.
• Paso 2.7: Actualizar el README.md:
  • Debe reflejar el estado actual del proyecto en este hito.
  • Debe enlazar la planificación (HUs y milestones) con la justificación adicional necesaria.
  • No debe incluir capturas de pantalla ni nada que no sea descripción estricta del proyecto en ese momento.
• Paso 2.8: Recordar que, aunque en este objetivo no se añade código todavía, a partir de ahora toda incorporación de código al repositorio debe hacerse mediante issues, y estos se cierran siempre con un commit.
• Paso 2.9: Crear el Pull Request con el título incluyendo la cadena [IV-26-27], usando la cadena de versión en el formato correcto con las versiones major y minor específicas de este objetivo.
• Paso 2.10: Añadir al fichero de proyectos (mediante un PR a ese repositorio) el nombre del proyecto, el autor y el enlace al PR con el que se quiere alcanzar el objetivo.

Fase 3: Verificación y Entrega

• Paso 3.1: Comprobar que el PR y los milestones/HUs en GitHub tienen el mismo contenido (en objetivos sucesivos se trabajará sobre ellos, no sobre el texto del PR).
• Paso 3.2: Pedir revisión a al menos dos compañeros/as (salvo excepciones en las primeras entregas del curso), además de la revisión final del profesor.
• Paso 3.3: Si se recibe una revisión y se hacen cambios, comentar explícitamente en el PR “Listo para revisión” para pedir una nueva revisión.
• Paso 3.4 (recomendado): Mientras se preparan cambios tras una revisión, se puede pasar el PR a modo “borrador” (draft) y no volver a “listo para revisar” hasta terminar los cambios. No hacer push a una rama ya revisada hasta completar todas las revisiones solicitadas por el profesor.
• Paso 3.5: Copiar y pegar en el cuerpo del PR las listas de comprobación (ver sección siguiente) y responder honestamente a cada pregunta.
• Paso 3.6: Esperar la aprobación final del profesor en el repositorio del proyecto — solo entonces se considera alcanzado el objetivo.
• Paso 3.7 (tras la aprobación): Estar atento/a: se asignarán aleatoriamente hasta cinco nicks para que revisen PRs de compañeros/as del mismo objetivo. No es obligatorio revisar, pero cuenta positivamente en la nota de “aprendizaje autónomo”.

⚠️ Requisitos Clave y Reglas de Evaluación

❗ CARÁCTER BLOQUEANTE

Este objetivo es bloqueante. No superarlo lleva automáticamente a un No Apto en la convocatoria correspondiente. La asistencia a las prácticas es obligatoria hasta que se supere.

❗ CRITERIOS DE EVALUACIÓN (Objetivo alcanzado)

El objetivo se habrá alcanzado si pasan 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 organiza y desglosa) corresponde a este objetivo.
3. Se han creado historias de usuario escritas para empezar a trabajar, reflejadas en issues de GitHub marcados correctamente ([HUxxx] + label user-stories), enlazadas desde el README.md y descritas en el PR.
4. La(s) historia(s) de usuario están agrupadas en al menos un par de milestones (también descritos en el PR).
5. Los milestones describen productos mínimamente viables y están ordenados correctamente.
6. Al menos dos compañeros/as han aprobado el PR (con excepciones en las primeras entregas).
7. La aprobación definitiva siempre la da el profesor.

❗ REQUISITOS MÍNIMOS PARA PASAR LOS TESTS

• Subdirectorio docs con material adicional enlazado desde el README.
• Al menos una historia de usuario correctamente marcada (HU en descripción + label user-stories).
• Uso de issues para añadir código al repositorio (a partir de ahora; en este objetivo aún no hay código).
• Al menos dos milestones.
• README actualizado reflejando el estado del proyecto y la justificación de la planificación.
• Revisión por al menos dos personas además del profesor (salvo excepciones iniciales).

⚠️ ADVERTENCIA: Título del PR

El título del PR tiene que incluir la cadena [IV-24-25] para poder filtrarlo fácilmente. Sin esto, el PR puede no ser detectado correctamente.

⚠️ ADVERTENCIA: Revisiones

No hacer push a una rama ya revisada hasta que se hayan completado todas las revisiones solicitadas por el profesor. Se puede usar el modo “borrador” (draft) mientras se trabaja en los cambios.

ℹ️ NOTA: Plazos (convocatoria ordinaria)

• Entrega: 4 semanas.
• Superación: 6 semanas.
• Datos históricos: el 50% entregó en 18 días, el 75% en menos de 25 días, el 90% en la quinta semana; todos los aprobados lo habían entregado ya dos meses después de empezar las clases.
• Si no se supera en plazo: hay que entregarlo igualmente para poder avanzar a los siguientes objetivos, y superarlo para tener garantías de éxito. Pasado el plazo, la superación ya no cuenta para la convocatoria ordinaria sino para la extraordinaria; si se siguen superando los objetivos siguientes, habrá que hacerlo hasta el 7 para conseguir la puntuación equivalente al aprobado en la convocatoria ordinaria.

ℹ️ NOTA: Valoración

Alcanzar este objetivo supone un avance del 7.5% del apartado correspondiente de la asignatura.

ℹ️ NOTA: Corrección entre pares

A partir de este objetivo se asignan revisores aleatoriamente entre quienes ya lo superaron (hasta 5 nicks por PR). No es obligatorio revisar, pero se valora positivamente en “aprendizaje autónomo”. Se necesitan al menos dos revisiones de compañeros/as antes de la revisión y aprobación del profesor.

💡 CONSEJO: Uso del tiempo de clase

Se aconseja asistir a clase y usar ese tiempo para trabajar en el objetivo, ya que el profesor puede guiar hacia la consecución del mismo, corregir sobre la marcha tras la entrega y admisión del PR, o dar consejos y material adicional. No conviene abandonar la clase cuando terminen “las explicaciones”, porque se pueden hacer en cualquier momento según lo soliciten los estudiantes.

🔍 Lista de Auto-comprobación (Antes de Entregar)

Copia y pega estas listas en el cuerpo del PR. Si la respuesta a alguna pregunta es negativa, revisa el concepto correspondiente antes de entregar.

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 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?

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?

Pregunta resumen

• 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?

? Encuesta

Por favor, contesta esta encuesta si has usado esta versión.

📖 Contexto y Teoría Completa

Para consultar las explicaciones teóricas detalladas (qué es un user journey, la metodología ágil, la relación entre milestones y objetivos de la asignatura, las preguntas frecuentes sobre qué es y qué no es un “producto”, etc.), consulta el Documento Original completo.

🚀 A donde ir desde aquí

Si has terminado, comienza con el siguiente objetivo.