El sistema Kanban para el software, derivado del Sistema de Producción de Toyota (TPS), son un enfoque sin iteraciones para organizar el trabajo. En vez de usar iteraciones de tiempo fijo y reuniones de planificación, el equipo toma historias del backlog sólo cuando completó su trabajo anterior.
En la comunidad ágil no existe un único modelo ágil de trabajo que se aplica a todas las situaciones. Es importante expandir el repertorio de opcionas más allá de Scrum / XP y familiarizarse con otras herramientas, como ser Kanban.
Hay varios enfoques para implementar Kanban en los equipos que desarrollan software. James Shore, autor de El Arte de Desarrollo Ágil, escribe: "El equipo toma una historia del backlog, la desarrolla, y la entrega ni bien esté completa. Luego toman la historia siguiente del backlog, la desarrollan, y la entregan. El trabajo se entrega ni bien está listo, y el equipo sólo trabaja de a una historia a la vez".
Los elementos claves para hacer funcionar a un sistema Kanban son:
- Características Vendibles Mínimas (Minimally Marketable Features - MMF): un MMF es es la característica más pequeña que tiene valor para el mercado. Los MMF se mantienen en una cola (muy parecida al Backlog del Producto de Scrum), pero que tiene un estricto tamaño fijo que la limita (en general, entre dos y siente elementos en la cola).
- Trabajo en Progreso: el equipo trabaja en el elemento más importante hasta que lo termina. Trabajan un único elemento por vez, descomponiéndolo en muchas tareas pequeñas.
- Estimación: en vez de usar la planificación y estimaciones habituales, se asume que todos los MMF tienen aproximadamente el mismo tamaño. Así se puede seguir el tiempo promedio en completar una caractarística, y se puede calcular el tiempo de espera en la cola para cada elemento.
- Elementos urgentes: ocasionalmente puede surgir trabajos de emergencia. Se reserva un único casillero para el trabajo de emergencia. Este lugar tiene más prioridad que el resto del backlog y el equipo trabaja para terminar ese elemento lo antes posible. Si aparece más trabajo urgente mientras el casillero está ocupado, va a parar el backlog común.
- Bugs: los errores en la programación se arreglan inmediatamente si la característica está en construcción. Sino, se los ubica en el backlog.
¿Por qué Kanban?
Para lograr entregar las características de un producto tienen que trabajar personas con diferentes capacidades. No hay que construir características que nadie necesita ahora. No hay que escribir más especificaciones de las que se pueden codificar. No hay que escribir más código del que se puede probar. No hay que probar más código del que se puede desplegar... Kanban ayuda a resolver estos problemas de manera más eficiente que otras alternativas.
En definitiva, ágil no es Scrum (aunque Scrum es ágil). Ágil no es XP (aunque XP es ágil). Ágil consiste en entregar valor, calidad, y lograr un proceso que pueda aprender de si mismo. Kanban en el software es una alternativa ágil más para lograr estos objetivos.
Basado en Kanban as alternative agile implementation.