Flujo de Trabajo de Planificación de Sprint con GitHub

GitHub es donde vive el código, pero la planificación de sprints necesita más estructura de lo que GitHub Projects proporciona. Conectar una herramienta dedicada de planificación de sprints a GitHub da a los equipos lo mejor de ambos mundos—planificación ágil con seguimiento automático de desarrollo cuando se hace push del código.

GitHub + Planificación de Sprint

Por Qué GitHub Solo No Es Suficiente

LIMITACIONES DE GITHUB PROJECTS
═══════════════════════════════

LO QUE GITHUB PROJECTS TIENE:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  ✅ Tableros Kanban                                         │
│  ✅ Seguimiento de issues                                   │
│  ✅ Automatización básica                                   │
│  ✅ Integración estrecha con código                         │
│  ✅ Gratis para repos públicos                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

LO QUE GITHUB PROJECTS NO TIENE:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  ❌ Seguimiento de velocidad de sprint                      │
│  ❌ Burndown/burnup charts                                  │
│  ❌ Estimación con story points (nativo)                    │
│  ❌ Límites y metas de sprint                               │
│  ❌ Planificación de capacidad                              │
│  ❌ Visibilidad cross-repo                                  │
│  ❌ Seguimiento de tiempo                                   │
│  ❌ Dashboards para clientes                                │
│  ❌ Reportes avanzados                                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

EL ENFOQUE HÍBRIDO:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  GitScrum (Planificación)          GitHub (Desarrollo)      │
│  ────────────────────────          ──────────────────       │
│  • Grooming de backlog             • Repositorio de código  │
│  • Planificación de sprint         • Pull requests          │
│  • Seguimiento de velocidad        • Revisiones de código   │
│  • Story points                    • Pipelines CI/CD        │
│  • Burndown charts                 • Gestión de ramas       │
│  • Seguimiento de tiempo           • Discusiones de issues  │
│                                                             │
│           │                           │                     │
│           └───────────┬───────────────┘                     │
│                       │                                     │
│                       ▼                                     │
│              VINCULACIÓN AUTOMÁTICA                         │
│              ──────────────────────                         │
│              Commits → Tareas                               │
│              PRs → Tareas                                   │
│              Actualizaciones de estado                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Configurar Integración GitHub

CONFIGURACIÓN GITSCRUM + GITHUB
═══════════════════════════════

PASO 1: CONECTAR GITHUB
─────────────────────────────────────
Configuración de Proyecto → Integraciones → GitHub

┌─────────────────────────────────────────────────────────────┐
│ Integración GitHub                                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ Estado: ✅ Conectado                                        │
│ Cuenta: tu-organizacion                                     │
│                                                             │
│ Repositorios:                                               │
│ ☑ frontend-app                                             │
│ ☑ backend-api                                              │
│ ☑ mobile-app                                               │
│ ☐ infrastructure (no vinculado)                            │
│                                                             │
│ [Añadir Repositorio] [Actualizar]                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

PASO 2: CONFIGURAR PARSEO DE COMMITS
─────────────────────────────────────
Configuración → Integración Git → Parseo de Commits

Patrones reconocidos:
├── [TASK-123] o [#123] en mensaje de commit
├── Closes #123 o Fixes #123
├── Nombre de rama: feature/TASK-123-descripcion
└── Título de PR: [TASK-123] Descripción de feature

PASO 3: CONFIGURAR AUTOMATIZACIONES
─────────────────────────────────────
Configuración → Automatizaciones

Reglas:
├── PR abierto → Mover tarea a "En Revisión"
├── PR mergeado → Mover tarea a "Hecho"
├── CI fallido → Añadir etiqueta "necesita-fix"
└── Rama creada → Mover tarea a "En Progreso"

Mejores Prácticas para Mensajes de Commit

FORMATO DE MENSAJE DE COMMIT
════════════════════════════

FORMATO ESTÁNDAR:
─────────────────────────────────────
[TASK-ID] Descripción corta (50 chars máx)

Explicación más larga si es necesaria. Ajusta a 72 caracteres.
Explica qué y por qué, no cómo.

- Los bullets están bien
- Sé conciso

EJEMPLOS:
─────────────────────────────────────
Bueno:
├── [TASK-456] Añadir autenticación JWT a endpoints API
├── [TASK-789] Fix null pointer en servicio de usuario
├── [TASK-123] Refactorizar módulo de pagos para testabilidad
└── Closes #234: Actualizar dependencias por parche de seguridad

Malo:
├── Arreglé cosas
├── WIP
├── Actualizaciones
└── asdfasdf

NOMBRADO DE RAMAS:
─────────────────────────────────────
Patrón: tipo/TASK-ID-descripcion-corta

Ejemplos:
├── feature/TASK-456-user-auth
├── bugfix/TASK-789-null-pointer
├── hotfix/TASK-999-security-patch
└── refactor/TASK-123-payment-module

Mejores Prácticas

1. Siempre referencia tareas - Incluye ID de tarea en commits y PRs
2. Usa nomenclatura consistente - Patrones de ramas y commits
3. Automatiza actualizaciones de estado - Eventos de PR mueven tareas automáticamente
4. Revisa datos Git en retros - Commits por punto, tiempo de revisión de PR
5. Mantén tareas atómicas - Una feature = una tarea = un PR
6. Vincula PRs a tareas - Incluso para trabajo no en commits
7. Usa límites de sprint - No mergees a main aleatoriamente mid-sprint
8. Rastrea estado de CI - Builds fallidos deben alertar a owners de tarea

Soluciones Relacionadas

• Integración GitHub
• Conectar Commits de GitHub a Tareas
• Vincular Tareas a GitHub GitLab Bitbucket
• Mejores Prácticas de Planificación de Sprint