Kanban y XP

Kanban es un método para gestionar el flujo de trabajo. Su idea de partida viene de la fabricación japonesa: hacer visible todo el trabajo en curso y no empezar nada nuevo hasta que salga algo por el otro extremo. La palabra kanban significa tarjeta o señal visual, y de ahí viene su herramienta característica.

Esa herramienta es el tablero. Se divide en columnas que representan los estados por los que pasa una tarea y cada tarea es una tarjeta que se mueve de izquierda a derecha. En su versión mínima las columnas son «por hacer», «en curso» y «hecho», pero un equipo real suele desglosar el «en curso» en las etapas de su propio proceso: por ejemplo pendiente, en desarrollo, en revisión, en pruebas y publicado. Herramientas como Trello o los tableros de proyecto de GitHub y GitLab son tableros kanban.

• Visualizar el trabajo: si una tarea no está en el tablero, no existe.
• Limitar el trabajo en curso (WIP): cada columna tiene un tope de tarjetas simultáneas.
• Gestionar el flujo: el objetivo es que las tarjetas atraviesen el tablero deprisa y sin atascos.
• Hacer explícitas las políticas: qué condiciones debe cumplir una tarjeta para pasar de una columna a la siguiente.
• Mejorar de forma continua y evolutiva, sin reorganizar el equipo de golpe.

El límite de trabajo en curso es lo que distingue un tablero kanban de una simple lista de tareas con colores. Si una columna está llena, no se mete nada más: primero se ayuda a desatascar lo que ya está dentro.

Kanban es un sistema de tirón (pull): el trabajo no se empuja sobre el equipo, sino que cada persona coge la siguiente tarjeta cuando tiene hueco. Las dos métricas propias del método son el lead time, el tiempo que pasa desde que se pide algo hasta que se entrega, y el cycle time, el tiempo que la tarjeta pasa efectivamente en curso.

Los dos son ágiles y los dos usan tableros, así que se confunden con facilidad. La diferencia de fondo es que Scrum trocea el tiempo y Kanban trocea el trabajo: Scrum organiza el proyecto en sprints de duración fija, y Kanban mantiene un flujo continuo sin ciclos.

No son excluyentes. Es habitual combinarlos en lo que se llama Scrumban: se conservan los eventos y los roles de Scrum y se añaden el tablero visual y el límite de trabajo en curso de Kanban.

XP es la metodología ágil más centrada en cómo se programa. Su apuesta es potenciar las relaciones personales dentro del equipo y mantener una retroalimentación continua entre el cliente y los desarrolladores, de modo que ningún malentendido sobreviva más de unos días.

Los requisitos se escriben como historias de usuario: frases cortas, en el lenguaje del cliente, que describen una necesidad y el valor que aporta. Las historias grandes se agrupan en épicas, y una épica se desgrana en las historias concretas que la componen. Cada historia se estima y se convierte después en tareas técnicas.

• Programación en parejas (pair programming): dos personas en un mismo puesto, una escribiendo y otra revisando, alternando papeles.
• Refactorización: reescribir código ya funcionando para dejarlo más limpio, sin cambiar lo que hace.
• Desarrollo dirigido por pruebas (TDD): se escribe primero la prueba unitaria, que falla, y después el código que la hace pasar.
• Integración continua: se integra el trabajo de todos varias veces al día en vez de esperar al final.
• Cliente en el sitio (customer on-site): un representante del cliente disponible para resolver dudas al momento.
• Ritmo sostenible: alrededor de cuarenta horas semanales, sin horas extra sistemáticas.
• Entregas pequeñas y frecuentes, y propiedad colectiva del código.

En XP los técnicos estiman el coste y el cliente decide la prioridad. Nunca al revés: ni el cliente estima ni el equipo decide qué es más importante para el negocio.

XP define además sus propios roles: programador, cliente, encargado de pruebas o tester, encargado de seguimiento o tracker, entrenador o coach, consultor y gestor. Son más numerosos que los de Scrum, pero en un equipo pequeño una misma persona asume varios.

Es la comparación que más aparece en examen, y conviene tenerla ordenada por criterios en vez de como dos listas de virtudes. La clave es que cada enfoque asume una cosa distinta sobre los requisitos: las clásicas suponen que se pueden conocer al principio, y las ágiles suponen que van a cambiar.

Ninguno de los dos enfoques es mejor en abstracto. Las clásicas encajan donde los requisitos son estables y hay exigencia normativa o contractual fuerte; las ágiles, donde el producto se va a descubrir mientras se construye.