Kanban Para Desarrolladores Solo

Pasé seis meses usando Jira para mis proyectos personales. Seis meses creando sprints de una persona, escribiendo user stories que nadie iba a leer, y moviendo tickets entre 7 columnas que inventé para sentirme "profesional." Producía menos que cuando usaba un archivo de texto plano con una lista de pendientes.

No Necesitas Jira

Jira fue diseñado para equipos de 10-50 personas que necesitan coordinar trabajo entre departamentos, rastrear dependencias cruzadas, y generar reportes para management. Cuando lo usas solo, el 90% de la funcionalidad es peso muerto que te distrae de lo único que importa: hacer el trabajo.

Los desarrolladores solo necesitamos saber tres cosas: qué tengo pendiente, qué estoy haciendo ahora mismo, y qué ya terminé. Eso es un Kanban de 3 columnas. No 7. No 5. Tres.

Notion, Linear, Monday.com, ClickUp. Todos excelentes para equipos. Para un solo desarrollador con 1-3 proyectos activos, son como usar un tráiler para ir al supermercado. Funciona, pero la relación esfuerzo-resultado es absurda.

Las Tres Columnas que Funcionan

Por hacer

Todo lo que necesitas hacer eventualmente va aquí. Features, bugs, ideas, tareas de mantenimiento. Sin prioridad numérica, sin estimaciones de puntos, sin épicas. Una tarjeta por tarea con un título que te diga qué hacer. "Agregar validación al form de contacto." "Corregir bug de timezone en dashboard." "Migrar base de datos a PostgreSQL 16."

El truco es mantener esta columna en máximo 15-20 tarjetas. Si pasa de 20, necesitas hacer una limpieza y aceptar que algunas cosas no las vas a hacer nunca. Borrar tarjetas que llevan 3 meses ahí sin moverse no es fracasar. Es ser honesto con tu capacidad.

Ordeno las tarjetas por lo que más importa arriba. Sin números. Sin etiquetas de prioridad. Solo la posición vertical me dice qué hago primero cuando termino algo.

En progreso (máximo 3)

Aquí están las tareas en las que estoy trabajando activamente. El número máximo es 3. Idealmente 2. Nunca más. Si necesitas agregar una cuarta, primero tienes que terminar o devolver una de las que ya están ahí.

Este límite es la parte más importante del sistema. Sin él, es fácil tener 8 tareas "en progreso" y no avanzar en ninguna. Cada cambio de contexto entre tareas te cuesta 15-23 minutos de productividad. Con 8 tareas activas estás cambiando contexto todo el día y completando cero.

Cuando algo se bloquea (espero respuesta de un API, espero que un deploy termine, espero feedback de un cliente), la regreso a "Por hacer" con una nota de por qué está bloqueada. No creo una columna de "Bloqueado." Eso complica el tablero sin agregar valor.

Hecho

Cuando una tarea está terminada, va aquí. "Terminada" significa que el código está en producción o merged al main branch. No "casi terminada." No "le falta el test pero funciona." Producción o merge. Esa definición estricta previene que cosas a medio hacer se acumulen.

Cada viernes reviso la columna de "Hecho" y la limpio. Me da un resumen visual de lo que produje en la semana. A veces es mucho y me siento bien. A veces son 2 tarjetas y eso me dice que algo no funcionó esa semana y necesito ajustar.

El Límite WIP Cambia Todo

WIP es "Work In Progress." El límite WIP es la regla más contraintuitiva de Kanban y la que más impacto tiene. Parece que limitar el trabajo activo te haría más lento. El efecto es el opuesto.

Con 2-3 tareas máximo en progreso, terminas cada una más rápido porque le dedicas atención completa. El throughput (tareas completadas por semana) sube aunque el trabajo en paralelo baje. Es matemática de teoría de colas, no opinión.

Antes del límite WIP, mi semana típica era: 8 tareas "en progreso," 1-2 completadas. Después del límite: 2-3 tareas en progreso, 5-7 completadas. Menos cosas activas, más cosas terminadas. El constraint te fuerza a tomar decisiones sobre qué importa ahora mismo en vez de hacer un poquito de todo sin terminar nada.

La parte difícil: decir "no" o "después" a cosas que se sienten urgentes. Cuando un bug aparece y ya tienes 3 tareas activas, la disciplina dice: termina una primero o devuelve una a "Por hacer." La urgencia percibida no es excusa para romper el límite. Si es realmente urgente (producción caída), intercambia: saca una tarea activa, mete el bug. Nunca excedas el límite.

Mi Sistema Kanban de Desarrollador Solo

Uso el Kanban de StackWaveHub en el navegador para el día a día. No necesita cuenta, no guarda datos en servidores, y es tan simple que no puedo sobre-configurarlo (que es mi tendencia natural).

Lunes a primera hora: reviso "Por hacer," muevo las 2-3 más importantes a "En progreso," y empiezo con la primera. No planeo la semana entera. Planeo lo de hoy y mañana ajusto.

Las tarjetas tienen títulos cortos y descriptivos. Nada de "Como usuario quiero..." Para mí mismo no necesito user stories. "Implementar auth con OAuth Google" me dice todo. Si necesito detalles, los pongo en un comment dentro de la tarjeta o en un doc aparte.

No uso etiquetas de color, story points, fechas de vencimiento ni subtareas. Cada capa de complejidad que le agregas a un sistema personal es fricción que te aleja de usarlo. El tablero más útil es el más simple que captura lo que necesitas.

Cuándo Kanban No es Suficiente

Si tu proyecto tiene un deadline fijo y muchas tareas que dependen entre sí, Kanban solo no te da visibilidad del timeline. No te dice si vas a llegar a tiempo. Para eso necesitas agregar algo de planificación temporal, quizás una lista con fechas estimadas o un gantt simple.

Si manejas más de 3 proyectos simultáneos con clientes diferentes, un solo tablero se vuelve confuso. En ese caso uso un tablero por proyecto o una sola columna "En progreso" dividida con separadores por proyecto.

Si trabajas con un cliente que necesita ver progreso, Kanban personal no sirve como herramienta de comunicación externa. Ahí sí necesitas algo como Notion o Linear donde puedes compartir una vista de solo lectura.

Pero para el 80% de los desarrolladores solo con 1-2 proyectos activos y sin deadlines imposibles, tres columnas y un límite WIP de 3 es todo lo que necesitas. El sistema perfecto es el que usas todos los días sin pensarlo. Si tu tablero requiere más de 10 segundos para actualizar, es demasiado complejo para sostenerse.