Método
Cómo trabajar en equipo sin pisaros
La forma de trabajar se define al final de la incepción y se revisa en cada retrospectiva. Se valora tanto lo que hacéis como la forma de hacerlo: un 40 % de la ambición del proyecto son aspectos metodológicos.
Roles: cada uno tiene una responsabilidad
El product owner son los profesores. Además del desarrollo, cada miembro del equipo se encarga de que una parte concreta se haga bien y se entregue a tiempo y en el formato correcto.
Incepción
Las dos fases de la incepción (en equipos de 8, se reparte entre dos personas).
Un sprint cada uno
Sprint master de su sprint: planning, report, burndown y que todo esté en el Drive a tiempo.
Servicios
Gestiona el servicio que ofrecéis a otro equipo y el que consumís.
Demo final
Prepara la demo: juego de datos, guion y ensayo.
Cierre
Coordina la documentación final: informe de gestión e información de la release.
Con los profesores
Asunto con el prefijo [PES] n-grup nom-projecte y una descripción. Cualquier problema de equipo, cuanto antes mejor.
El project record track (PRT)
Una hoja de cálculo compartida donde se registra toda la actividad del equipo: clases, reuniones, formación, desarrollo, documentación. Es algo redundante con Git y Taiga, pero sirve para gestionar el equipo y se usa para evaluarlo.
- Columnas: fecha, duración, miembro, actividad, número de historia y comentarios.
- Una persona por fila: si una reunión es de tres personas, tres filas.
- Una hoja aparte con el resumen y estadísticas por miembro e iteración.
- Se actualiza desde el primer día, y el sprint master lo comprueba.
- Descripciones coherentes: siempre los mismos nombres de actividad.
| Actividad | Qué incluye |
|---|---|
| Reunió d'equip | Reunión de (casi) todo el equipo, incluidas las reuniones con el profesor. |
| Reunió focal | Un grupo pequeño del equipo trabajando un tema concreto. |
| Classe passiva | Horas de clase magistral. |
| Formació | Aprender una tecnología nueva para aplicarla al proyecto. |
| Desenvolupament | Programar, probar, controlar la calidad, desplegar. |
| Gestió de projecte | Actualizar Taiga o herramientas similares. |
| Documentació | Escribir los documentos que se entregan en cada iteración. |
| Presentació | Preparar las presentaciones orales. |
Ejemplo de fila: 2026-10-14 · 1,5 h · Laia · Desenvolupament · US-12 · Endpoint GET /estaciones y pruebas de integración
Taiga: el backlog vivo
- Las épicas agrupan historias; cada historia tiene descripción, criterios de aceptación, puntos, prioridad y estado.
- Las historias del sprint se descomponen en tareas con responsable, horas estimadas y horas reales.
- Las tareas se asignan dinámicamente, no al principio de todo.
- Los RNF tienen que tener un lugar claro (una historia propia o criterios de aceptación) y ser medibles.
- Los bugs se registran y, si hace falta, se reabre la historia afectada.
Un buen truco: escribid en la memoria qué pasa en cada evento (empezar proyecto, empezar sprint, empezar una historia, empezar y acabar una tarea, encontrar un bug) y cómo afecta a cada herramienta.
Git y GitHub
Definid una metodología de ramas (por ejemplo Gitflow) y seguidla:
mainsolo con versiones que funcionan;developpara integrar.- Una rama por historia o tarea:
feature/42-mapa-estaciones. - Pull requests revisadas por otra persona antes de integrar.
- Cada commit referencia la tarea de Taiga:
task #42: Añade el filtro de bicis libres.
Los aspectos metodológicos que se valoran
Estos criterios pesan el 40 % de la ambición del proyecto. Usad la lista para revisar vuestra forma de trabajar antes de cada entrega.
Checklist metodológica
Servicios entre equipos
Los tres equipos de un grupo forman un círculo: A produce un servicio para B y consume uno de C; B produce para C y consume de A; C produce para A y consume de B. Quién es cada letra se decide en la incepción.
- Sprint 1: definir. Negociadlo: una funcionalidad bien definida e independiente, lo bastante general para interesar a los dos equipos (a menudo transversal). Acordad también dónde se desplegará.
- Sprint 2: ofrecer. Código y pruebas, un endpoint disponible y documentación para el equipo que lo usará.
- Sprint 3: consumir. Integrad el servicio del equipo compañero.
Acordad el contrato pronto y trabajad contra un mock hasta que el servicio real esté en marcha. Generad el contrato y el mock →
Servidores, bases de datos y despliegue
- Documentad toda la configuración de los servidores: creación de las máquinas y características, servicios instalados, usuarios y contraseñas (en un lugar seguro), puertos abiertos, certificados, versiones y cómo arrancar y parar el servicio.
- Nube: Virtech (nube docente de la FIB; puertos y despliegue paso a paso), Heroku (horas limitadas al mes y se duerme) o AWS (se apaga automáticamente), entre otras.
- Evolución del esquema de la BD: ficheros SQL de create y alter, o un framework de migraciones.
- Aspectos tecnológicos que se valoran (20 % de la ambición): número y configuración de servidores y BD justificados, versionado de la BD, lenguajes, API propia, APIs externas integradas, servicio consumido y suministrado, datos abiertos, frameworks, integración continua y despliegue, siempre explicados y justificados.