Requisitos de Equipo - IA-P1-BCN/g2-python-crud-api GitHub Wiki

🤝 Normas de equipo

Este documento recoge los acuerdos de trabajo del equipo durante el proyecto. Todas las personas del equipo se comprometen a respetarlos.

👥 Equipo y roles

Todas las integrantes del equipo son desarrolladoras. Además, algunas tienen un rol SCRUM:

Persona Rol SCRUM Rol técnico
Pedro — Developer
Elena Product Owner Developer
Ivanna — Developer
Eva — Developer
Nayeli Scrum Master Developer

Responsabilidades

Product Owner (Elena)

  • Representa las necesidades del cliente.
  • Prioriza el backlog y define los criterios de aceptación de las user stories.
  • Resuelve dudas sobre el alcance y valida que lo entregado cumple lo esperado.

Scrum Master (Nayeli)

  • Facilita las ceremonias SCRUM (planning, daily, review, retrospective).
  • Vela por que se cumplan estas normas.
  • Detecta y ayuda a eliminar impedimentos.
  • Mantiene el tablero Kanban actualizado junto al equipo.

Developers (todas)

  • Diseñan, implementan, testean y documentan el producto.
  • Revisan el código de sus compañeras.
  • Se comprometen con los objetivos del sprint y los actualizan en el tablero.

STACK

Backend: FastAPI· DB: WorkBench · Auth: JWT · Tests: Pytest · Docs: Swagger · Probar endpoints: Postman

Frontend: Streamlit

🌐 Idioma

Elemento Idioma
Código (variables, funciones, métodos, clases, módulos) 🇬🇧 Inglés
Nombres de ramas 🇬🇧 Inglés
Commits 🇬🇧 Inglés
Pull Requests (título y descripción) 🇬🇧 Inglés
Tareas y user stories 🇬🇧 Inglés
Comentarios en el código 🇪🇸 Español
Textos mostrados al cliente (mensajes de la API, errores, respuestas) 🇪🇸 Español
Documentación (README, dailies, retrospectiva) 🇪🇸 Español

🐍 Convenciones de código (Python, PEP 8)

Elemento Convención Ejemplo
Variables snake_case member_name
Funciones y métodos snake_case get_active_members()
Clases PascalCase MembershipService
Constantes UPPER_SNAKE_CASE MAX_PAGE_SIZE
Módulos y archivos snake_case member_router.py
Atributos/métodos privados prefijo _ _validate_email()

Otras pautas:

  • Nombres descriptivos: evitar abreviaturas poco claras (x, tmp, data2).
  • Funciones pequeñas con una única responsabilidad.
  • Indentación de 4 espacios y líneas de máximo 79-88 caracteres.
  • Imports ordenados: librería estándar, terceros y propios.
  • Comentarios en español que expliquen el porqué, no el qué.

Ejemplo:

​python: Calcula el precio final aplicando el descuento de la membresía def calculate_final_price(base_price: float, discount_rate: float) -> float: return base_price * (1 - discount_rate)

🌿 Flujo de trabajo con Git

Ramas

  • main: código estable, siempre funcional.
  • develop: integración del trabajo del sprint.
  • feature/..., fix/..., docs/..., test/...: una rama por tarea, en inglés.

Ejemplos:

​ feature/create-member-endpoint fix/pagination-offset-error docs/update-readme test/add-member-crud-tests ​

Commits

En inglés, en modo imperativo y con prefijo (Conventional Commits):

​ feat: add endpoint to create members fix: correct pagination offset calculation docs: update API usage section in README test: add unit tests for member deletion refactor: simplify membership validation ​

Pull Requests

  • Título y descripción en inglés.
  • Descripción breve: qué cambia, por qué y cómo probarlo.
  • Enlazar la tarea o user story (Closes #12).
  • Nadie hace merge directo a main ni a develop.

🔍 Revisión de código

  • Todo PR necesita la aprobación de al menos 1 persona del equipo antes de hacer merge.
  • La autora del PR no puede aprobar el suyo propio.
  • Los comentarios de revisión deben ser constructivos y concretos.
  • Antes de pedir revisión: los tests pasan y el código sigue las convenciones.
  • Los cambios solicitados se resuelven antes del merge.

🆘 Ante dificultades

Si alguien se bloquea o una tarea se complica:

  1. Se avisa cuanto antes (en la daily o por el canal del equipo), sin esperar al final del sprint.
  2. Se resuelve mediante pair programming (2 personas) o mob programming (todo el equipo o varias personas ante un mismo problema).
  3. Si el impedimento persiste, se comunica a la Scrum Master para gestionarlo.

Pedir ayuda es parte del proceso, no un fallo.

📋 Gestión del proyecto

  • Todas las tareas y user stories están en el tablero Kanban, redactadas en inglés.
  • Cada persona actualiza el estado de sus tareas a diario.
  • Daily Scrum registrada en docs/dailies.md.
  • Al final del sprint: Sprint Review y Retrospectiva.

✅ Definition of Done

Una tarea se considera terminada cuando:

  • Cumple los criterios de aceptación de la user story
  • El código sigue las convenciones del equipo
  • Tiene tests y estos pasan
  • El PR ha sido revisado y aprobado por al menos 1 persona
  • Está documentada (si aplica)
  • Se ha hecho merge y la tarea está en Done