Integrante	Rol	Responsabilidad
Mariana Niño	Scrum Master	Dirige las ceremonias del sprint y mantiene el backlog
Gabriel Quiroga	Product Owner	Prioriza las historias y define los criterios de aceptación
Samuel Zeudec	Configuration Manager	Control de versiones, ramas y estándares
Julián Parra	QA Lead	Pruebas y criterios de calidad
Nassin Suz	DevOps	Entornos y despliegue

Trabajamos con Scrum. El backlog son issues de GitHub agrupados por milestone, uno por sprint. Cada historia de usuario tiene sus criterios de aceptación escritos antes de empezar a desarrollarla, y las ceremonias —planeación, seguimiento, revisión y retrospectiva— quedan documentadas.

Rama	Para qué	Quién escribe en ella
main	Versión entregada	Nadie directamente; entra por PR desde develop
develop	Integración del equipo	Nadie directamente; entra por PR
features-<nombre>	Trabajo personal de cada integrante	Su dueño
fix/<tema>	Corrección puntual y acotada	Quien la abre

Nombres en minúscula y sin tildes.

Antes de empezar una historia y antes de abrir el pull request, hay que actualizarse con develop. Si la rama personal no tiene commits propios sin subir, se reinicia desde develop en lugar de hacer un merge: un merge de una rama vieja arrastra archivos antiguos encima de lo que otros ya corrigieron.

Antes de hacer commit, verificar que el correo configurado sea el de la cuenta de GitHub. Si no, el commit no aparece como contribución de nadie.

Todo entra a develop por pull request, y cada uno necesita al menos una aprobación de alguien distinto al autor. Antes de abrirlo: compilar, correr las pruebas, revisar el propio diff y buscar marcadores de conflicto olvidados.

El cuerpo del PR lleva Closes #NN para que el issue se cierre al fusionar.

Las reglas completas están en el CONTRIBUTING.md, que es la versión que manda.

Una historia está terminada cuando cumple sus criterios de aceptación, incluye al menos una prueba automatizada —o explica en el PR por qué no aplica—, está fusionada en develop y su documentación quedó actualizada.