El Problema del Kanban en el Desarrollo de Software Los tableros kanban genericos fueron disenados para manufactura, no para codigo: El Modelo de Manufactura: - La tarjeta representa un widget - El widget se mueve a traves de estaciones - Cada estacion es una ubicacion fisica - El estado es binario: en la estacion o no La Realidad del Software: - La tarjeta representa una feature/bug - La feature existe en multiples estados simultaneamente - Codigo en branch, PR abierto, revision pendiente, CI corriendo - El estado es complejo: el codigo existe pero el trabajo no esta 'terminado' Donde Falla el Kanban Generico Problema 1: El Estado Miente - La tarjeta dice 'En Progreso' pero no hay commits en 3 dias - La tarjeta dice 'En Revision' pero el PR tiene conflictos de merge - La tarjeta dice 'Hecho' pero el PR no se ha fusionado - Las actualizaciones de estado manuales se retrasan horas o dias de la realidad Problema 2: Contexto Faltante - Que branch tiene este trabajo?
- Cuantos commits hasta ahora? - Quien esta revisando?
- Estan pasando los tests? - Hay conflictos de merge?
El kanban generico no muestra nada de esto. Problema 3: Seguimiento Duplicado - GitHub tiene estado del issue - Kanban tiene estado de la tarjeta - PR tiene estado de revision - El desarrollador actualiza los tres (o no) - Cual es la verdad?
Problema 4: Sin Aplicacion de WIP - Principio kanban: limitar trabajo en progreso - Tableros genericos: tarjetas ilimitadas por columna - Resultado: 15 items 'En Progreso', nada realmente moviendose GitScrum: Kanban Que Entiende Codigo Los tableros kanban de GitScrum se conectan directamente a GitHub: Las Tarjetas Conocen Su Codigo: - Cada tarjeta se vincula a issue/branch de GitHub - Conteo de commits visible en la tarjeta - Estado del PR mostrado (abierto/borrador/fusionado) - Estado de revision (aprobado/cambios solicitados) - Estado de CI (pasando/fallando) Actualizaciones de Estado Automaticas: - Branch creado? La tarjeta se mueve a 'En Progreso' - PR abierto?
La tarjeta muestra indicador de PR - Revision aprobada? La tarjeta lo refleja - PR fusionado?
La tarjeta se mueve a 'Hecho' No se requiere arrastrar manualmente para cambios impulsados por codigo. Como Funciona el Kanban de GitScrum Configuracion del Tablero: 1.
Conectar organizacion de GitHub 2. Crear tablero con columnas personalizadas 3.
Agregar tarjetas (o importar de issues de GitHub) 4. Vincular tarjetas a branches/PRs Uso Diario: - Abrir tablero para ver estado actual - Las tarjetas se actualizan desde actividad de GitHub - Arrastrar para cambiar prioridad (no estado) - Los cambios de estado vienen de la actividad del codigo Indicadores Visuales: - Icono PR: Pull request existe - Icono de check: CI pasando - Icono X: CI fallando - Icono de ojo: En revision - Icono de reloj: Esperando revision - Icono de merge: Listo para fusionar - Badge de numero: Conteo de commits Configuracion de Columnas Columnas de Desarrollo Predeterminadas: 1.
Backlog - No iniciado 2. Por Hacer - Planeado para sprint actual 3.
En Progreso - Branch existe, commits sucediendo 4. En Revision - PR abierto, esperando revision 5.
Listo para Merge - Aprobado, CI pasando 6. Hecho - PR fusionado Columnas Personalizadas: - Agrega cualquier columna que necesites - Configura triggers para movimiento automatico - Establece limites WIP por columna - Columnas de archivo para trabajo completado Limites WIP Que Realmente Funcionan Principio kanban: Limitar trabajo en progreso.
WIP de tablero generico: - Establecer limite a 3 - La gente lo ignora - 8 items se acumulan en 'En Progreso' - Cuello de botella invisible WIP de GitScrum: - Establecer limite a 3 por desarrollador - Advertencia visual cuando se excede - No se puede iniciar nuevo trabajo hasta que algo se mueva - Fuerza completar antes de comenzar Seguimiento WIP real: - Contar por asignado, no solo por columna - Ver quien esta sobrecargado - Balancear trabajo en el equipo - Realmente aplicar principios de flujo GitScrum vs Kanban Generico | Caracteristica | Kanban Generico | GitScrum | |----------------|-----------------|----------| | Fuente de estado | Arrastre manual | Actividad GitHub | | Visibilidad de PR | Ninguna | Estado completo mostrado | | Estado de CI | Ninguno | Pass/fail visible | | Estado de revision | Ninguno | Aprobado/cambios mostrado | | Aplicacion de WIP | Opcional/ignorado | Limites activos por persona | | Sincronizacion GitHub | Ninguna o unidireccional | Bidireccional tiempo real | | Visibilidad de commits | Ninguna | Conteo y actividad | | Conflictos de merge | Ocultos | Advertencia visible | Precios para Equipos de Desarrollo - 2 usuarios: GRATIS para siempre - 3+ usuarios: $8.90/usuario/mes - Todas las funciones de kanban incluidas - Tableros ilimitados - Integracion completa con GitHub Equipo de 5 personas: $26.70/mes - Tableros kanban ilimitados - Todas las vistas (kanban, swimlane, timeline, lista) - Aplicacion de limites WIP - Integracion con PR/CI de GitHub Equipo de 10 personas: $71.20/mes - Todo lo anterior - Vistas de carga de trabajo del equipo - Tableros entre equipos - Analiticas avanzadas La Linea Final Los tableros kanban genericos muestran estado que alguien escribio. Los tableros kanban de GitScrum muestran estado de tu codigo.
Cuando tu kanban refleja realidad: - Sin actualizaciones de estado manuales - Problemas de PR visibles inmediatamente - Limites WIP realmente aplicados - Problemas de flujo identificados temprano GitScrum: Tableros kanban que entienden el desarrollo de software. 2 usuarios gratis.
$8.90/usuario/mes. Ve lo que realmente esta pasando en tu codigo.
La Ventaja GitScrum
Una plataforma unificada para eliminar el cambio de contexto y recuperar horas productivas.
