6 min lectura • Guide 520 of 877
Cómo Usar Kanban para Operaciones de TI
Los equipos de operaciones de TI enfrentan interrupciones constantes de incidentes, solicitudes de usuarios y tareas de mantenimiento. Los tableros Kanban de GitScrum con límites WIP, swimlanes para tipos de trabajo y tracking de SLA ayudan a equipos de ops a gestionar flujo, mantener niveles de servicio y evitar el caos de colas de trabajo no gestionadas.
Tipos de Trabajo de Operaciones TI
| Tipo de Trabajo | Prioridad | Tratamiento de Flujo |
|---|---|---|
| Incidentes P1 | Inmediata | Carril expedite |
| Incidentes P2 | Mismo día | Alta prioridad |
| Solicitudes de servicio | Normal | Flujo estándar |
| Mantenimiento | Planificado | Programado |
| Mejoras | Baja | Cuando hay capacidad |
Tablero Kanban de Operaciones TI
ESTRUCTURA DE TABLERO OPERACIONES TI
┌─────────────────────────────────────────────────────────────────────┐
│ EXPEDITE (Incidentes P1) - Sin Límite WIP │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ [INC-234] Base de datos de producción sin respuesta │ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
┌─────────┬──────────┬──────────┬──────────┬──────────┬─────────────┐
│ Backlog │ Listo │ Trabajando│ Review │ Deploy │ Hecho │
│ (sin WIP)│ (WIP: 3) │ (WIP: 4) │ (WIP: 2) │ (WIP: 2) │ (sin WIP) │
├─────────┼──────────┼──────────┼──────────┼──────────┼─────────────┤
│ [REQ] │ [INC] │ [INC] │ [CHG] │ [CHG] │ [INC] ✓ │
│ [REQ] │ [REQ] │ [CHG] │ │ │ [REQ] ✓ │
│ [CHG] │ │ [REQ] │ │ │ [CHG] ✓ │
│ [CHG] │ │ │ │ │ │
│ [IMP] │ │ │ │ │ │
└─────────┴──────────┴──────────┴──────────┴──────────┴─────────────┘
SWIMLANES POR TIPO DE TRABAJO:
┌─────────────────────────────────────────────────────────────────────┐
│ 🔴 Incidentes (P2-P3) │
├─────────────────────────────────────────────────────────────────────┤
│ 📋 Solicitudes de Servicio │
├─────────────────────────────────────────────────────────────────────┤
│ 🔧 Cambios y Mantenimiento │
├─────────────────────────────────────────────────────────────────────┤
│ 📈 Mejoras │
└─────────────────────────────────────────────────────────────────────┘
Tipos de Items de Trabajo
DEFINICIONES DE ITEMS DE TRABAJO
INCIDENTE (INC):
┌─────────────────────────────────────────────────┐
│ Interrupción no planificada del servicio │
│ Objetivo: Restaurar servicio ASAP │
│ │
│ Campos: │
│ ├── Prioridad (P1-P4) │
│ ├── Servicio afectado │
│ ├── Impacto (usuarios afectados) │
│ ├── Hora de inicio │
│ └── Tiempo de resolución │
│ │
│ SLAs: │
│ P1: Respuesta <15 min, Resolver <4 horas │
│ P2: Respuesta <1 hora, Resolver <8 horas │
│ P3: Respuesta <4 horas, Resolver <24 horas │
│ P4: Respuesta <1 día, Resolver <1 semana │
└─────────────────────────────────────────────────┘
SOLICITUD DE SERVICIO (REQ):
┌─────────────────────────────────────────────────┐
│ Solicitud estándar de usuario │
│ Objetivo: Cumplir según SLA │
│ │
│ Campos: │
│ ├── Tipo de solicitud │
│ ├── Solicitante │
│ ├── Fecha límite │
│ └── Estado de aprobación │
│ │
│ Ejemplos: Solicitud de acceso, nueva cuenta, │
│ instalación de software, solicitud de hardware │
└─────────────────────────────────────────────────┘
CAMBIO (CHG):
┌─────────────────────────────────────────────────┐
│ Modificación planificada de infraestructura │
│ Objetivo: Implementar de forma segura │
│ │
│ Campos: │
│ ├── Tipo de cambio (estándar/normal/emergencia)│
│ ├── Nivel de riesgo │
│ ├── Plan de rollback │
│ ├── Ventana de cambio │
│ └── Aprobación CAB │
└─────────────────────────────────────────────────┘
MEJORA (IMP):
┌─────────────────────────────────────────────────┐
│ Mejora proactiva │
│ Objetivo: Mejorar operaciones │
│ │
│ Ejemplos: Automatización, monitoreo, │
│ documentación, mejora de procesos │
└─────────────────────────────────────────────────┘
Planificación de Capacidad
MODELO DE CAPACIDAD EQUIPO OPS
EQUIPO: 5 ingenieros
ASIGNACIÓN DE CAPACIDAD:
┌─────────────────────────────────────────────────┐
│ Respuesta a incidentes: 1-2 ingenieros (20-40%)│
│ (rota diariamente) │
│ │
│ Trabajo planificado: 3-4 ingenieros (60-80%)│
│ ├── Solicitudes de servicio │
│ ├── Cambios │
│ └── Mejoras │
└─────────────────────────────────────────────────┘
JUSTIFICACIÓN DE LÍMITES WIP:
┌─────────────────────────────────────────────────┐
│ Listo: 3 │
│ └── Medio día de trabajo preparado │
│ │
│ Trabajando: 4 │
│ └── Menos que tamaño equipo (5) para enfoque │
│ │
│ Review: 2 │
│ └── Minimizar cuello de botella de aprobación │
│ │
│ Deploy: 2 │
│ └── Controlar velocidad de cambios │
└─────────────────────────────────────────────────┘
Métricas de Flujo
DASHBOARD DE MÉTRICAS OPS TI
MÉTRICAS DE FLUJO:
┌─────────────────────────────────────────────────┐
│ Cycle Time (días promedio): │
│ Incidentes P2: 0.5 días Objetivo: <1 ✓ │
│ Solicitudes: 3.2 días Objetivo: <5 ✓ │
│ Cambios: 5.1 días Objetivo: <7 ✓ │
│ Mejoras: 12 días Objetivo: <14 ✓ │
└─────────────────────────────────────────────────┘
THROUGHPUT:
┌─────────────────────────────────────────────────┐
│ Esta Semana: │
│ Incidentes resueltos: 8 │
│ Solicitudes cumplidas: 15 │
│ Cambios deployados: 6 │
│ Mejoras completadas: 2 │
└─────────────────────────────────────────────────┘
NIVELES DE SERVICIO:
┌─────────────────────────────────────────────────┐
│ Cumplimiento de SLA: │
│ Incidentes P1: 100% (2/2 cumplidos) ✓ │
│ Incidentes P2: 95% (19/20 cumplidos) ✓ │
│ Solicitudes: 92% (46/50 cumplidas) ⚠ │
└─────────────────────────────────────────────────┘
Mejores Prácticas
- Usar carril expedite solo para verdaderas emergencias
- Establecer límites WIP basados en tamaño del equipo
- Trackear cycle time por tipo de trabajo
- Reservar capacidad de incidentes diariamente
- Visualizar todo el trabajo incluyendo mejoras
- Revisar items bloqueados en standups
- Medir cumplimiento SLA continuamente
- Realizar retrospectivas regulares para mejorar flujo
Anti-Patrones
✗ Sin límites WIP (todo en progreso)
✗ Carril expedite para todos los incidentes
✗ Trabajo oculto no en tablero
✗ Sin tiempo para mejoras
✗ Ignorar items bloqueados
✗ Sin métricas de flujo