8 min lectura • Guide 809 of 877
Metodologías Ágiles Híbridas
Ninguna metodología única se ajusta a todos. GitScrum soporta enfoques híbridos, permitiendo que los equipos combinen prácticas de Scrum, Kanban y otros frameworks.
Entendiendo Enfoques Híbridos
Por Qué Híbrido
RAZONES PARA METODOLOGÍAS HÍBRIDAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SCRUM PURO: │
│ ─────────── │
│ ✅ Bueno para: Desarrollo de features, trabajo predecible │
│ ❌ Desafíos: Trabajo de soporte, interrupciones frecuentes│
│ │
│ KANBAN PURO: │
│ ──────────── │
│ ✅ Bueno para: Soporte, mantenimiento, flujo continuo │
│ ❌ Desafíos: Planificar capacidad, compromisos de sprint │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ HÍBRIDO CUANDO: │
│ ──────────── │
│ │
│ TIPOS DE TRABAJO MIXTOS: │
│ Features (planificados) + Soporte (no planificado) │
│ Necesita estructura Y flexibilidad │
│ │
│ RESTRICCIONES ORGANIZACIONALES: │
│ Empresa usa sprints para planificación │
│ Pero equipo necesita flujo Kanban para trabajo │
│ │
│ TRANSICIÓN: │
│ Moviendo de waterfall a ágil │
│ Adopción gradual de prácticas │
│ │
│ PREFERENCIA DEL EQUIPO: │
│ Equipo experimentó y encontró qué funciona │
│ Mix de prácticas entrega mejores resultados │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EL OBJETIVO: │
│ ───────── │
│ Usar prácticas que ayuden a TU equipo a entregar valor │
│ No seguir un framework por el framework en sí │
└─────────────────────────────────────────────────────────────┘
Scrumban
Combinando Scrum y Kanban
OVERVIEW DE SCRUMBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DE SCRUM: DE KANBAN: │
│ ─────────── ──────────── │
│ • Sprints (opcional) • Board visual │
│ • Sprint planning • Límites WIP │
│ • Retrospectivas • Sistema pull │
│ • Daily standup • Métricas de flujo │
│ • Backlog • Mejora continua │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BOARD SCRUMBAN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │BACKLOG │ READY │ DEV (3) │REVIEW(2)│ QA (2) │ DONE ││
│ │ │ │ │ │ │ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ ││
│ │ │A │ │ │D │ │ │G │ │ │J │ │ │L │ │ │N │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ ││
│ │ │B │ │ │E │ │ │H │ │ │K │ │ │M │ │ │O │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ │ │ ││
│ │ │C │ │ │F │ │ │I │ │ │ │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ │ │ ││
│ │ │ │ │ │ │ ││
│ │ │ │ LÍMITE │ LÍMITE │ LÍMITE │ ││
│ │ │ │ WIP │ WIP │ WIP │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRÁCTICAS CLAVE: │
│ ────────────── │
│ • Sprint planning para priorización │
│ • Board Kanban con límites WIP para ejecución │
│ • Pull de trabajo cuando hay capacidad disponible │
│ • Métricas de flujo para mejora │
│ • Retros al final del sprint │
└─────────────────────────────────────────────────────────────┘
Cuándo Usar Scrumban
CASOS DE USO SCRUMBAN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EQUIPOS DE MANTENIMIENTO: │
│ ────────────────── │
│ Mix de mejoras planificadas y fixes reactivos │
│ Sprint planning + flujo continuo │
│ │
│ SOPORTE + DESARROLLO: │
│ ────────────────────── │
│ Trabajo de features dedicado con interrupciones de soporte│
│ Reservar capacidad para trabajo no planificado │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ASIGNACIÓN DE CAPACIDAD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CAPACIDAD SPRINT: 40 puntos ││
│ │ ││
│ │ TRABAJO PLANIFICADO: 30 puntos (75%) ││
│ │ ┌────────────────────────────────────────────────────┐ ││
│ │ │████████████████████████████████████████████████████│ ││
│ │ │ Features, Mejoras, Deuda Técnica │ ││
│ │ └────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ BUFFER NO PLANIFICADO: 10 puntos (25%) ││
│ │ ┌────────────────────┐ ││
│ │ │████████████████████│ ││
│ │ │ Soporte, Bugs, Urgentes │ ││
│ │ └────────────────────┘ ││
│ │ ││
│ │ Si buffer no usado, pull del backlog ││
│ │ Si excedido, diferido al siguiente sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SWIMLANES: │
│ ────────── │
│ Lanes separados para trabajo planificado vs no planificado│
│ Diferentes límites WIP por lane │
│ Trackear separadamente para análisis │
└─────────────────────────────────────────────────────────────┘
Construyendo Tu Metodología
Proceso de Personalización
PERSONALIZANDO TU ENFOQUE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PASO 1: COMENZAR CON UNA BASE │
│ ───────────────────────── │
│ Elegir Scrum o Kanban como punto de partida │
│ No comenzar desde cero │
│ Aprender el framework primero │
│ │
│ PASO 2: IDENTIFICAR PUNTOS DE DOLOR │
│ ──────────────────────────── │
│ ¿Qué no está funcionando? │
│ ¿Qué causa fricción? │
│ ¿Qué no se ajusta a tu contexto? │
│ │
│ PASO 3: EXPERIMENTAR │
│ ────────────────── │
│ Probar un cambio a la vez │
│ Ejecutar por 2-4 sprints │
│ Medir impacto │
│ │
│ PASO 4: EVALUAR │
│ ──────────────── │
│ ¿Ayudó? │
│ ¿Mantener, ajustar o revertir? │
│ Documentar la decisión │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EJEMPLOS DE PERSONALIZACIÓN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PUNTO DE DOLOR EXPERIMENTO RESULTADO ││
│ │ ────────── ────────── ────── ││
│ │ Sprints muy Flujo estilo Mantenido: Mejor ││
│ │ rígidos Kanban continuo para soporte ││
│ │ ││
│ │ Sin visibilidad Agregado review Mantenido: Mejor ││
│ │ de planificación semanal planning predictibilidad ││
│ │ ││
│ │ Standups muy Caminar el board Mantenido: Más ││
│ │ largos derecha-izquierda rápido, enfocado ││
│ │ ││
│ │ Retros aburridas Probado nuevo Revertido: Equipo ││
│ │ formato (4Ls) prefirió viejo ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Documentación
DOCUMENTANDO TU METODOLOGÍA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ACUERDO DE TRABAJO DEL EQUIPO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ EQUIPO: Ingeniería de Plataforma ││
│ │ METODOLOGÍA: Scrumban (Personalizado) ││
│ │ ÚLTIMA ACTUALIZACIÓN: Enero 2025 ││
│ │ ││
│ │ CADENCIA: ││
│ │ • Sprints de 2 semanas para planificación ││
│ │ • Flujo continuo para ejecución ││
│ │ • Sprint planning: Lunes Semana 1 ││
│ │ • Retro: Viernes Semana 2 ││
│ │ • Daily standup: 9:30am (15 min) ││
│ │ ││
│ │ CONFIGURACIÓN BOARD: ││
│ │ • Columnas: Backlog, Ready, Dev, Review, QA, Done ││
│ │ • Límites WIP: Dev(3), Review(2), QA(2) ││
│ │ • Swimlanes: Features, Bugs, Soporte ││
│ │ ││
│ │ CAPACIDAD: ││
│ │ • 70% trabajo planificado ││
│ │ • 30% buffer para soporte/urgente ││
│ │ ││
│ │ CEREMONIAS: ││
│ │ • Planning: 1.5 horas ││
│ │ • Standup: 15 min (caminar el board) ││
│ │ • Retro: 1 hora ││
│ │ • Refinement: Según necesidad (1hr/semana típico) ││
│ │ ││
│ │ MÉTRICAS RASTREADAS: ││
│ │ • Cycle time ││
│ │ • Throughput ││
│ │ • Ratio planificado vs no planificado ││
│ │ ││
│ │ LO QUE NO HACEMOS: ││
│ │ • Story points (contamos ítems) ││
│ │ • Compromiso de sprint (tenemos metas) ││
│ │ • Sprint demos (hacemos demo cuando está listo) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ El documento ayuda: │
│ • Onboardear nuevos miembros del equipo │
│ • Explicar a stakeholders │
│ • Recordar por qué se tomaron decisiones │
│ • Revisar y evolucionar intencionalmente │
└─────────────────────────────────────────────────────────────┘
Evolución
Mejora Continua
EVOLUCIONANDO TU METODOLOGÍA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REVISIÓN REGULAR: │
│ ─────────────── │
│ │
│ CADA RETRO: │
│ "¿Está funcionando nuestro proceso?" │
│ Pequeños ajustes │
│ │
│ TRIMESTRALMENTE: │
│ Revisión de proceso dedicada │
│ Cambios más grandes considerados │
│ │
│ ANUALMENTE: │
│ Evaluación completa de metodología │
│ ¿Todavía cumple su propósito? │
└─────────────────────────────────────────────────────────────┘