Hay varias áreas de software en donde Kanban funciona bien: proyectos de mantenimiento, desarrollo de juegos, proyectos multimedia. No hay datos claros sobre si es bueno usar Kanban para el desarrollo de productos.
Tengo mi propia visión sobre el rol de Kanban en los proyectos de desarrollo de software.
Cuando se inicia un proyecto, primero deberiamos usar iteraciones, y luego cambiar a un desarrollo por flujo usando Kanban
Los motivos son bien simples. Inicialmente no tenemos historia previa con la cual lidiar. Tenemos un conjunto grande de características que queremos incluir con la Entrega #1. Definitivamente es mejor tener un backlog pequeño, pero depende. A veces, un "producto vendible mínimo" tiene bastantes características. Así que podemos tener muchas historias de usuario para implementar, y no tenemos bugs de producción, ni peticiones de cambio, etc. Significa que estamos en un entorno bastante estable, con un backlog estable. Significa que no tenemos que ramificar características y hacer entregas en cualquier momento. Podemos definir objetivos claros para las iteraciones, estimar historias, usar velocidad y predecir la fecha de la Entrega #1 con bastante precisión.
Sin embargo, las cosas cambian con el tiempo. De pronto tenemos muchos usuarios, hay varias mejoras, y tenemos bugs urgentes para arreglar y entregar. Ahora el entorno deja de ser estable, y tenemos eventos inesperados en el proceso de desarrollo. Aquí pareciera ser un buen momento para cambiar a Kanban. Los bugs urgentes pueden arreglarse y entregarse en 1-2 días, las mejoras pueden planificarse a demanda con una buena predicción de entrega, la velocidad deja de ser crítica (los ciclos de trabajo funcionan bien para características pequeñas, ya que no necesitamos predecir ciclos de entrega largos).
Hicimos este experimento en TargetProcess. Iteramos durante 3 años, y hace algunos meses cambiamos a Kanban. Normalmente hacemos entregas pequeñas semanales, pero podemos entregar en cualquier momento si se necesita. No estimamos las historias (quizás volvamos a hacerlo, pero por ahora no nos resulta necesario). Usamos Git para el control de versiones, y hacemos un branch por cada característica o bug.
Irónicamente, fuimos nosotros quienees comenzamos a dejar de usar cosas como planificación de entregas/iteraciones y seguimiento de progreso. Era una señal clara de que debíamos agregar Kanban como herramienta. Y en eso estamos.
