Kanban en software ) es metodología de desarrollo ágil de “segunda generación”, popularizada por David J. Anderson y creada pensando en equipos que rechazaron adoptar otras metodologías agiles como el Scrum.
Kanban es evolutivo e incremental, no intrusivo (“Kanban es como agua” es decir evita solucionar impedimentos grandes inmediatamente) y permite partir con la situación tal como está. El primer paso es simplemente visualizar el proceso y flujo de las tareas.
En raíz de método Kanban es “pull” y “just-in-time” donde cada desarrollador toma la tarea una vez que termina con la anterior, así liberándose de presión, trabajando de acuerdo a sus capacidades y con tiempo de trabajar en mejora continua o Kaizen. De acuerdo al Anderson, Kaizen emerge naturalmente en equipos que implementen Kanban.
Hay que mencionar que el tablero Kanban es la manifestación física de esta metodología, a cual también comúnmente nos referimos con palabra “Kanban”, pero tener el tablero no basta para hablar de metodología.
Los 5 principios de Kanban son:
- Visualizar el flujo
- Limitar el WIP (Trabajo en curso)
- Manejar el flujo
- Hacer políticas del proceso explicitas
- Mejorar colaborativamente utilizando modelos y método científico.
Literatura gratis:
“Kanban y Scrum – obteniendo lo mejor de ambos”
El libro con que empezó todo: Kanban: Successful Evolutionary Change for Your Technology Business
Excelente aporte!… lo de los 5 principios, ayuda mucho a entender…
De todas maneras quedan algunas dudas…
- Lo del cuarto punto en los principios "Hacer políticas del proceso explicitas", ¿está relacionado con los estados que tiene el Kanban?...
- Y lo de metodología de desarrollo ágil de "segunda generación", quiere decir que es parte del software craftmanship?
Un ejemplo para el principio “Hacer políticas del proceso explicitas” habla de analistas y toma de requerimientos. En caso de que analistas son sobrecargados de trabajo, desarrolladores podrían ayudar escribiendo los requerimientos. Pero, si lo hacen analistas podrían reclamar porque otros están haciendo su trabajo y sentirse amenazados. Si tenemos la política explicita que dice “Solamente los analistas escriben los requerimientos”, entonces esta política se puede discutir y modificar para que diga por ejemplo que desarrolladores cuando estén desocupados pueden ayudar a los analistas con requerimientos para una parte de sistema más conocida, menos critica etc. Es la existencia de la política que permite que esta se discuta y adecue a las necesidades del equipo. Lo esencial es entender que las políticas se pueden y deben modificar en mediad que equipo evoluciona.
Kanban no es parte de “Software craftmanship” y si bien históricamente es de segunda generación, tiene enfoque diferente que el craftmanship, el cual trata de promover importancia de maestría y de software bien hecho.
Kanban es una señal informativa, un tablero kanban donde pones las señales. El objetivo es informar a todos los que vean el tablero de manera sencilla y expedita.
Algunas de las ventajas y desventajas están descritas en Kanban web o análogo. Esta discución es muy interesante.
El post que mencionas se focaliza en kanban web (virtual) vs análogo (físico), creo que esta pregunta viene antes la mencionada… la idea es tener algo simple y directo para responder las típicas preguntas… ¿que es un kanban?, ¿por que kanban y no otra cosa?, ¿que resultados puedo obtener si lo implemento?… dado que en la lista se habla constantemente del kanban…
Saludos






All Shapado.com content and data are available under the
Me gustaría preguntar acerca del Kanban a modo de establecer una definición, me refiero a lo que ofrece la Herramienta Kanban en un proyecto de desarrollo de software…
Quizás se logre respondiendo a las siguientes preguntas, no lo sé de antemano… =)
En caso que sea una pregunta muy sencilla, voy a dejar el link a wikipedia: http://es.wikipedia.org/wiki/Kanban