Team Charter - UniExtremadura/GA01GPS GitHub Wiki

Acuerdos de trabajo

Comunicación

  1. Canal síncrono: llamada o videollamada. Canal asíncrono: WhatsApp para lo cotidiano y GitHub para lo técnico.

  2. Cada miembro se conecta al canal del equipo a diario y, como máximo, cada 2 días.

  3. Los mensajes se responden en menos de 24 horas laborables. Los urgentes (marcados con @) en menos de 4 horas.

Reuniones

  1. Daily de máximo 10 minutos, 2 veces por semana: qué hice, qué haré y qué me bloquea.

  2. Planning al inicio de cada iteración (máximo 60 minutos). Review y retrospectiva al final (máximo 45 minutos cada una).

  3. Toda reunión tiene agenda previa y objetivo claro. Alfonso vigila que se respete el tiempo establecido.

Las reuniones de Scrum, las revisiones y las demás actividades de coordinación se realizan fuera de las 6,25 horas semanales que cada integrante tiene disponibles para desarrollar los requisitos.

Horarios y ausencias

  1. Al inicio de cada iteración, cada miembro registra su disponibilidad en la Wiki, que se utiliza como referencia para calcular la capacidad del equipo.

  2. Toda ausencia de más de 2 días se comunica en el canal del equipo con al menos 48 horas de antelación, salvo imprevistos, que se avisan en cuanto sea posible.

La capacidad acordada para el desarrollo de requisitos es de 6,25 horas semanales por integrante durante las seis iteraciones.

Decisiones

  1. Las decisiones se toman por consenso. Si no lo hay tras 15 minutos, decide el rol competente: Product Owner en alcance y prioridad, Tech Lead en cuestiones técnicas.

  2. Toda decisión relevante se registra en la Wiki con fecha, decisión, motivo y documentos afectados.

Conflictos y feedback

  1. Los desacuerdos técnicos se resuelven con un ADR breve: opciones, ventajas, inconvenientes y decisión.

  2. Los conflictos entre personas se hablan primero entre los implicados, después con el Scrum Master y, si persisten, con el profesor.

  3. El feedback se da en la retrospectiva o en privado, sobre el trabajo y no sobre la persona, y se acompaña de una propuesta de mejora.

Calidad

  1. Ninguna pull request se fusiona sin la aprobación de al menos un revisor distinto del autor. Los revisores rotan entre todos los miembros.

  2. Una historia solo entra en un sprint si cumple el DoR y solo se cierra si cumple el DoD.

Flujo y herramientas

  1. Límite de trabajo en curso (WIP): máximo 2 tareas por persona en "En progreso".

  2. Cada historia se desarrolla en su propia rama (feature/US-XXX) y los commits referencian el ID correspondiente.

  3. Fuentes de verdad: Jira para tareas, Wiki para decisiones y Git para especificaciones. No se suben credenciales, claves ni archivos .env reales al repositorio.

Versión: 02
Fecha: 16/10/2026