6 min lectura • Guide 806 of 877
Planificación de Capacidad para el Crecimiento
El crecimiento requiere planificación. GitScrum ayuda a los equipos a entender su capacidad y planificar la escalabilidad a medida que la organización crece.
Entendiendo la Capacidad
Capacidad Actual
EVALUANDO CAPACIDAD DEL EQUIPO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FACTORES DE CAPACIDAD: │
│ │
│ TIEMPO DISPONIBLE: │
│ Total días laborables - feriados - PTO - reuniones │
│ │
│ TIEMPO EFECTIVO: │
│ Tiempo disponible × factor de enfoque (típicamente 60-80%)│
│ Considera: interrupciones, admin, soporte │
│ │
│ HABILIDADES DEL EQUIPO: │
│ No todo el trabajo puede ser hecho por todas las personas │
│ Cuellos de botella en habilidades especializadas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CÁLCULO DE CAPACIDAD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CAPACIDAD EQUIPO - SPRINT 15 ││
│ │ ││
│ │ MIEMBRO DÍAS FACTOR EFECTIVO ││
│ │ ────── ──── ────── ───────── ││
│ │ @alex 10 80% 8 días ││
│ │ @jordan 8 80% 6.4 días (2 días PTO) ││
│ │ @pat 10 70% 7 días (turno soporte) ││
│ │ @sam 10 80% 8 días ││
│ │ @taylor 10 50% 5 días (capacitación) ││
│ │ ──────────────────────────────────────────────────────││
│ │ TOTAL: 48 34.4 días efectivos ││
│ │ ││
│ │ RENDIMIENTO HISTÓRICO: ││
│ │ Sprint 14: 35 story points ││
│ │ Sprint 13: 38 story points ││
│ │ Sprint 12: 32 story points ││
│ │ PROMEDIO: ~35 puntos/sprint ││
│ │ ││
│ │ CAPACIDAD SPRINT 15: ~32 puntos ││
│ │ (Menor debido a PTO y capacitación) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Planificando para el Crecimiento
Cuándo Crecer
SEÑALES QUE NECESITAS MÁS CAPACIDAD:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SOBRECARGA CONSISTENTE: │
│ ──────────────────── │
│ • Backlog crece más rápido de lo que entregas │
│ • Compromisos de sprint regularmente incumplidos │
│ • Equipo trabajando horas insostenibles │
│ • Calidad sufriendo debido a prisas │
│ │
│ CUELLOS DE BOTELLA: │
│ ──────────────── │
│ • Una persona bloquea múltiples historias │
│ • Habilidades especializadas en escasez │
│ • Revisiones/aprobaciones creando retrasos │
│ • Punto único de falla │
│ │
│ NECESIDAD ESTRATÉGICA: │
│ ─────────────── │
│ • Nueva área de producto planificada │
│ • Escalando para servir más clientes │
│ • Inversión en plataforma técnica │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ⚠️ ADVERTENCIA: LEY DE BROOKS │
│ ───────────────────────── │
│ "Agregar personas a un proyecto atrasado lo atrasa más" │
│ │
│ POR QUÉ: │
│ • Nuevas personas necesitan onboarding │
│ • Personas existentes entrenan en vez de entregar │
│ • Sobrecarga de comunicación aumenta │
│ │
│ PLANIFICA CON ANTICIPACIÓN, no en crisis │
└─────────────────────────────────────────────────────────────┘
División de Equipos
ESCALANDO EQUIPOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CRECIENDO UN EQUIPO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ TAMAÑO: 5 → 6 → 7 → 8 → 9 → ¡DIVIDIR! ││
│ │ ▲ ││
│ │ │ ││
│ │ Óptimo ││
│ │ ││
│ │ 5-9 personas: Punto ideal ││
│ │ 10+: Sobrecarga de comunicación muy alta ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CUÁNDO DIVIDIR: │
│ ─────────────── │
│ • Cuando la comunicación se vuelve difícil │
│ • Cuando hay dos flujos de trabajo claros │
│ • Cuando puedes formar dos equipos viables │
│ │
│ CÓMO DIVIDIR: │
│ ───────────── │
│ • Divide por dominio/característica, no por rol │
│ • Mantén cada equipo cross-funcional │
│ • Evita dependencias entre equipos nuevos │
│ • Considera afinidad de miembros │
└─────────────────────────────────────────────────────────────┘
Estrategias de Contratación
Planificación de Onboarding
INCORPORACIÓN EFECTIVA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEMANA 1: Orientación │
│ ─────────────────────── │
│ • Configuración de herramientas y accesos │
│ • Introducción al equipo y cultura │
│ • Revisión de arquitectura y procesos │
│ • Primera tarea pequeña y guiada │
│ │
│ SEMANA 2-4: Rampa │
│ ───────────────── │
│ • Tareas progresivamente más complejas │
│ • Pair programming con diferentes miembros │
│ • Participación en ceremonias │
│ • Feedback regular con mentor │
│ │
│ MES 2-3: Productividad │
│ ───────────────────── │
│ • Historias independientes │
│ • Contribución a code reviews │
│ • Entendimiento del dominio profundo │
│ • Integración completa al equipo │
│ │
│ EXPECTATIVA DE PRODUCTIVIDAD: │
│ Mes 1: 25% │ Mes 2: 50% │ Mes 3: 75% │ Mes 4: 100% │
└─────────────────────────────────────────────────────────────┘
Métricas de Capacidad con GitScrum
Dashboard de Capacidad
MÉTRICAS A MONITOREAR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ UTILIZACIÓN: │
│ • % de tiempo en trabajo planificado │
│ • % de tiempo en trabajo no planificado │
│ • Tiempo en reuniones vs. trabajo profundo │
│ │
│ RENDIMIENTO: │
│ • Velocidad promedio por sprint │
│ • Tendencia de velocidad (subiendo/bajando) │
│ • Variación de velocidad │
│ │
│ PREDICCIÓN: │
│ • Fecha estimada de completar backlog │
│ • Capacidad necesaria vs. disponible │
│ • Gaps de habilidades identificados │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DASHBOARD EN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CAPACIDAD DEL EQUIPO ││
│ │ ││
│ │ Velocidad: 35 pts/sprint │ Tendencia: ▲ +5% ││
│ │ Capacidad: 90% │ Backlog: 280 pts ││
│ │ ││
│ │ PROYECCIÓN: Backlog completado en ~8 sprints ││
│ │ ││
│ │ RECOMENDACIÓN: Considerar escalar si backlog ││
│ │ crece >10% por sprint ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘