Guía PES

Herramientas

Taiga y GitHub, bien configurados desde el primer día

Son las dos herramientas que se miran en cada entrega. Si las configuráis bien al principio, os ahorraréis trabajo (y puntos) durante todo el curso.

Taiga, paso a paso

  1. Cread el proyecto con la plantilla Scrum (en PES no se usa la Kanban) y marcadlo como público.
  2. Añadid a todos los miembros en Settings → Members.
  3. Módulos (Settings → Project → Modules): activad Epics, Scrum, Issues y Wiki. En Scrum, poned 3 sprints esperados y, si lo tenéis, el total de puntos.
  4. Atributos (Settings → Attributes): estados, puntos, prioridades, tipos y tags, como queráis. Los campos personalizados sí son obligatorios.
  5. Épicas: identificad unas cuantas, cada una con su color.
  6. Product backlog: cada historia con la plantilla Como… quiero… de manera que…, enlazada a una épica (obligatorio), con puntos y con los criterios de aceptación numerados (1., 2., 3.). En el product backlog los criterios todavía pueden estar vacíos.
  7. Ordenad el backlog por prioridad.
  8. Sprint: Add sprint con las fechas, arrastrad las historias y abrid el Sprint taskboard.
  9. Tareas: dentro de cada historia, con las horas estimadas (Estimated Effort) y asignadas a medida que se hacen.
  10. Cerrad las tareas arrastrándolas a Closed y rellenad las horas reales (Actual Effort). Cuando todas están cerradas, la historia se cierra sola y el burndown se actualiza.

Campos personalizados obligatorios

Settings → Attributes → Custom fields.

DóndeCampoTipo
User storyPriorityDropdown: Low, Medium, High
User storyAcceptance CriteriaRich text
TaskEstimated EffortNumber (horas)
TaskActual EffortNumber (horas)

Podéis añadir más si os son útiles, pero explicadlos en la documentación.

Recomendaciones

  • Configurad el número de sprints y los puntos esperados: así Taiga dibuja bien el gráfico del backlog.
  • Personalizad los estados de historias y tareas para que encajen con vuestra definición de hecho.
  • Las integraciones (GitHub, webhooks) y los plugins son opcionales: probadlos cuando el proyecto ya funcione.
No olvidéis el Actual Effort. Sin horas reales no hay comparación con la estimación, y es una de las cosas que se revisan.

Cómo se entrega Taiga en cada Fag

Los profesores no corrigen el proyecto en el que trabajáis cada día, sino una copia congelada de cómo estaba al acabar el sprint.

  1. Al acabar el sprint, Settings → Project → Export: se descarga una copia del proyecto.
  2. New project → Import project → Taiga con esa copia, con un nombre que diga qué sprint es (p. ej. BiciVerda sprint 1).
  3. Compartid el proyecto restaurado con los profesores.
  4. No lo toquéis nunca más: los proyectos entregados tienen que quedar inmutables. Seguid trabajando en el original.

Antes de exportar

0/6

GitHub, paso a paso

  1. La organización de vuestro grupo ya existe y sigue el patrón pes2627q1-<grupo>-gei-upc (p. ej. pes2627q1-11-gei-upc). Pedid a vuestro profesor que añada a todos los miembros.
  2. Cread el repositorio dentro de la organización (New repository). Público o privado, como queráis.
  3. Añadid al equipo: Settings → Collaborators → Add people, con el rol Write, Maintain o Admin.
  4. Una persona crea el proyecto en local con el comando del framework (flutter create, npm create vite, django-admin startproject...) y lo sube.
  5. El resto lo clona y ya podéis trabajar en ramas.
¿Uno o varios repositorios? Si usáis tecnologías distintas, mejor más de uno: el caso típico es uno para el frontend y otro para el backend. Cualquier opción vale si la justificáis en la documentación.

Si la herramienta ya ha creado la carpeta .git:

cd bici-verda-app
git remote add origin https://github.com/pes2627q1-11-gei-upc/bici-verda-app.git
git branch -M main
git push -u origin main

Cambiad el grupo y el nombre del repositorio por los vuestros.

Pruébalo

Revisor de mensajes de commit

Cada commit tiene que llevar el identificador de la tarea de Taiga, y todo el mundo tiene que hacer commits a menudo y de forma equilibrada, aunque programéis en pareja. Escribid un mensaje y mirad qué reglas cumple.

0/50

Las reglas

    Lectura recomendada: How to Write a Git Commit Message.

    ¿Gitflow o GitHub Flow?

    Elegid uno, escribidlo en la memoria y seguidlo. Los dos funcionan en PES.

    Más estructura

    Gitflow

    main con las versiones entregadas, develop para integrar, y ramas feature/*, release/* y hotfix/*. Encaja con entregas planificadas como los finales de sprint.

    Ved el diagrama →

    Más simple

    GitHub Flow

    Solo main y ramas cortas: cread la rama, haced commits, abrid una pull request, recibid revisión, probad y fusionad. Ideal si tenéis integración y despliegue continuos.

    mainfeature commitsPRmerge