Jump to content

Kanban: origen y definición: Difference between revisions

From Scrum Manager BoK
No edit summary
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
El término '''''kanban''''' aplicado a la gestión ágil de proyectos se refiere a técnicas de representación visual de información para mejorar la eficiencia en la ejecución de las tareas de un proyecto.
{{Meta-bok|min=5}}
==Origen==
El término '''kanban''' (看板) proviene del japonés y puede traducirse como "tablero o tarjeta de señalización". Aplicado a la gestión ágil de proyectos, designa un conjunto de técnicas de representación visual del trabajo destinadas a mejorar la eficiencia en la ejecución de tareas, reducir los cuellos de botella y hacer visible el flujo de trabajo en tiempo real.
El término japonés ''Kanban'', fue el empleado por Taiichi Onho (Toyota), para referirse al sistema de visualización empleado en los procesos de producción que coordinan en una cadena de montaje la entrega a tiempo de cada parte en el momento que se necesita, evitando sobreproducción y almacenamiento innecesario de producto.  
== Origen ==
El término fue empleado por Taiichi Ohno (Toyota) para referirse al sistema de visualización usado en los procesos de producción que coordinan en una cadena de montaje la entrega a tiempo de cada parte en el momento que se necesita, evitando la sobreproducción y el almacenamiento innecesario. Su origen se remonta a finales de los años cuarenta o principios de los cincuenta, en el contexto del Sistema de Producción Toyota (TPS).
== Kanban en el sector tecnológico ==
* El uso de tableros kanban en desarrollo de software muestra y gestiona el flujo de avance y entrega, y ayuda a evitar los dos problemas más frecuentes: '''cuellos de botella''' (tareas que se acumulan en una fase porque la siguiente no puede absorberlas) y '''tiempos muertos''' (fases vacías de trabajo porque la anterior no produce suficiente).
* Desde 2005 es cada vez más habitual reemplazar los formatos de lista para las pilas de producto y de sprint por tarjetas en tableros, que resultan más versátiles al poder cambiar su posición para reflejar el estado de avance de cada tarea o historia.
* Las prácticas kanban son válidas para la gestión evolutiva con entrega continua. Deben emplearse con criterios de flexibilidad, sin considerarlas prescripciones rígidas, para lograr la implementación que mejor responda a los principios ágiles del contexto concreto.


Se puede traducir como "tablero o tarjeta de señalización", y su origen se remonta finales de los cuarenta o principio de los cincuenta.
== Kanban y Scrum: gestión técnica vs. gestión experta ==
Algunos autores tratan Scrum y Kanban como marcos de reglas diferentes. Kniberg y Skarin (2009) describen las diferencias en este sentido:
* Scrum prescribe roles; Kanban no.
* Scrum trabaja con iteraciones de tiempo fijo; Kanban con cadencias (simples, múltiples o dirigidas por eventos).
* Scrum limita el WIP por iteración; Kanban limita el WIP por estado del flujo de trabajo.
* Los equipos Scrum son multidisciplinares; en Kanban pueden ser de especialistas.
* Scrum no permite cambiar tareas del sprint; en Kanban la tarea puede alterarse hasta entrar en el flujo.
* Scrum necesita estimaciones y velocidad; Kanban no las prescribe.
* Los tableros Scrum se resetean al final de cada sprint; los Kanban son continuos.


==Kanban en el sector TIC==
Al evolucionar hacia un modelo ágil pragmático basado en valores y experiencia, estas diferencias "técnico-metodológicas" se relativizan. Un equipo maduro puede combinar libremente prácticas de Scrum y Kanban según las necesidades del proyecto, sin que esa combinación implique incoherencia metodológica.


El uso de tableros ''kanban'' muestra y gestiona el flujo de avance y entrega, y ayuda a evitar los dos problemas más importantes: cuellos de botella y tiempos muertos.
== Kanban y la IA como herramienta ==
Los tableros kanban están siendo adoptados como herramienta de gestión para flujos de trabajo con componente de IA:
* '''Pipelines de IA:''' equipos que construyen sistemas de procesamiento de datos o modelos de lenguaje usan tableros kanban para visualizar el estado de cada fase del pipeline (ingesta, preprocesamiento, entrenamiento, evaluación, despliegue).
* '''Asistentes de priorización:''' algunas herramientas de gestión ágil incorporan IA para sugerir reordenaciones del backlog o alertar sobre WIP excesivo, usando los principios kanban como lógica subyacente.


El desarrollo ágil de software emplea prácticas de gestión visual por ser las que mejor sirven a los principios de comunicación directa y simplicidad en la documentación y gestión.  
== Error frecuente ==
<div class="bok-aviso">
'''Tratar el tablero kanban como un fin en sí mismo.''' Un tablero kanban es una herramienta de visibilidad, no un método de gestión completo. Si el equipo actualiza el tablero pero no actúa sobre lo que revela —cuellos de botella que se repiten, WIP que se dispara, tareas que llevan días en el mismo estado— el tablero se convierte en decoración. El valor de kanban está en las conversaciones y decisiones que genera, no en el tablero en .
</div>
== Referencias ==


Desde 2005 es cada vez más frecuente reemplazar los formatos de lista para las pilas de producto y de sprint por notas adhesivas en tableros, que resultan más versátiles al poder cambiar su posición, bien para reordenar las prioridades de las historias de una pila de producto, o para reflejar a través de su posición en, cuáles se están programando, probando, o se encuentran terminadas.
Kniberg, Henrik; Skarin, Mattias. (2009). ''Kanban and Scrum: Making the Most of Both''. InfoQ.
Ohno, Taiichi. (1988). ''Toyota Production System: Beyond Large-Scale Production''. Productivity Press.


Las '''prácticas ''kanban''''' son válidas para gestión evolutiva con entrega continua. Deben emplearse con criterios de flexibilidad, sin considerar prescripciones ni excepciones en el método de trabajo, para lograr la implementación personalizada, que dé la mejor respuesta a los principios ágiles, de ingeniería concurrente, o de síntesis de ambos, con los que trabaje la organización.
== Véase también ==
 
<div class="bok-tags">
==Gestión técnica vs. gestión experta==
[[Tableros kanban: conceptos]] [[Tableros kanban: operativa]] [[Lead time]] [[Incremento continuo]] [[Lean]] [[Muda Mura y Muri: algunos consejos para ajustar el flujo]] [[Scrum estándar: componentes y marco]]
 
</div>
Algunos autores consideran a ''scrum'' y ''kanban'' como marcos de reglas y prácticas diferentes.
<div class="bok-ecosistema">
 
<div class="texto">
Según Kniberg & Skarin al considerarlos así, se dibujarían las siguientes diferencias entre ellos(Kniberg & Skarin, 2009):  
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
*Scrum prescribe roles, kanban no.
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
*Scrum trabaja con iteraciones de tiempo fijo, kanban con cadencias (simples, múltiples o dirigidas por eventos).
</div>
*Scrum limita el wip por iteración, kanban limita el wip por estado del flujo de trabajo.
<div class="botones">
*Los equipos de scrum son multidisciplinares, en kanban pueden ser de especialistas.
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
*Scrum no permite cambiar tareas del sprint, en kanban la tarea puede alterarse hasta entrar en el flujo.
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
*En scrum la pila de producto debe tener la longitud de al menos un sprint. En kanban se debe atender al ritmo de arrastre de tareas.
</div>
*En scrum se deben estimar las historias y las tareas y calcular la velocidad, kanban no mide tareas ni velocidad.
</div>
*Scrum necesita una pila de producto priorizada, en kanban es la siguiente historia o tarea arrastrada desde el cliente.
*Scrum prescribe reuniones diarias, kanban no.
*Scrum emplea diagramas burndown, kanban no.
*Los tableros scrum se resetean al final de cada sprint.
 
Al evolucionar hacia un modelo de scrum pragmático, basado en la aplicación de los valores de la agilidad con la experiencia y conocimientos propios, y abandonar los modelos basados en reglas, se aprende a romper éstas y flexibilizar las prácticas, quedando como triviales cuestiones “técnico-metodológicas” que de otra forma distorsionan la realidad y el foco de la gestión:  
*'''Situación A:''' “Por un lado se desea usar kanban, pero por otro se quiere estimar las tareas (por ejemplo para registrar la velocidad por razones organizativas de mi empresa) …”
*'''Situación B:''' “La empresa gestiona proyectos simultáneos con una organización de oficina de proyectos y por eso encaja mejor el establecimiento de roles; pero sin embargo se quiere trabajar con kanban en lugar de con scrum… ¿Debería hacer scrumban? ¿qué es eso? ¿o lo que se va a hacer es Scrumbut? ¿es la solución de un mal gestor?.
==Véase también==
*[[Lean]].
*[[Tableros kanban: conceptos]].
*[[Tableros kanban: operativa]].
*[[Ejemplo de tablero kanban: "Kanban Box" para una oficina multiproyecto]].
*[[Ejemplo de tablero kanban: desarrollo evolutivo con incremento iterativo]].
*[[Ejemplo de tablero kanban: desarrollo evolutivo con incremento continuo]].
*[[Ejemplo de tablero kanban: información relativa al estado de desarrollo del producto]].
*[[Ejemplo de tablero kanban: equipo de operación y mantenimiento]].
[[Category:Glosario de términos]]
[[Category:Glosario de términos]]
[[Category:Kanban]]
[[Category:Metodologías ágiles]]

Latest revision as of 14:37, 12 May 2026

⏱ 5 min de lectura  ·  📅 Actualizado en 2026

El término kanban (看板) proviene del japonés y puede traducirse como "tablero o tarjeta de señalización". Aplicado a la gestión ágil de proyectos, designa un conjunto de técnicas de representación visual del trabajo destinadas a mejorar la eficiencia en la ejecución de tareas, reducir los cuellos de botella y hacer visible el flujo de trabajo en tiempo real.

Origen

El término fue empleado por Taiichi Ohno (Toyota) para referirse al sistema de visualización usado en los procesos de producción que coordinan en una cadena de montaje la entrega a tiempo de cada parte en el momento que se necesita, evitando la sobreproducción y el almacenamiento innecesario. Su origen se remonta a finales de los años cuarenta o principios de los cincuenta, en el contexto del Sistema de Producción Toyota (TPS).

Kanban en el sector tecnológico

  • El uso de tableros kanban en desarrollo de software muestra y gestiona el flujo de avance y entrega, y ayuda a evitar los dos problemas más frecuentes: cuellos de botella (tareas que se acumulan en una fase porque la siguiente no puede absorberlas) y tiempos muertos (fases vacías de trabajo porque la anterior no produce suficiente).
  • Desde 2005 es cada vez más habitual reemplazar los formatos de lista para las pilas de producto y de sprint por tarjetas en tableros, que resultan más versátiles al poder cambiar su posición para reflejar el estado de avance de cada tarea o historia.
  • Las prácticas kanban son válidas para la gestión evolutiva con entrega continua. Deben emplearse con criterios de flexibilidad, sin considerarlas prescripciones rígidas, para lograr la implementación que mejor responda a los principios ágiles del contexto concreto.

Kanban y Scrum: gestión técnica vs. gestión experta

Algunos autores tratan Scrum y Kanban como marcos de reglas diferentes. Kniberg y Skarin (2009) describen las diferencias en este sentido:

  • Scrum prescribe roles; Kanban no.
  • Scrum trabaja con iteraciones de tiempo fijo; Kanban con cadencias (simples, múltiples o dirigidas por eventos).
  • Scrum limita el WIP por iteración; Kanban limita el WIP por estado del flujo de trabajo.
  • Los equipos Scrum son multidisciplinares; en Kanban pueden ser de especialistas.
  • Scrum no permite cambiar tareas del sprint; en Kanban la tarea puede alterarse hasta entrar en el flujo.
  • Scrum necesita estimaciones y velocidad; Kanban no las prescribe.
  • Los tableros Scrum se resetean al final de cada sprint; los Kanban son continuos.

Al evolucionar hacia un modelo ágil pragmático basado en valores y experiencia, estas diferencias "técnico-metodológicas" se relativizan. Un equipo maduro puede combinar libremente prácticas de Scrum y Kanban según las necesidades del proyecto, sin que esa combinación implique incoherencia metodológica.

Kanban y la IA como herramienta

Los tableros kanban están siendo adoptados como herramienta de gestión para flujos de trabajo con componente de IA:

  • Pipelines de IA: equipos que construyen sistemas de procesamiento de datos o modelos de lenguaje usan tableros kanban para visualizar el estado de cada fase del pipeline (ingesta, preprocesamiento, entrenamiento, evaluación, despliegue).
  • Asistentes de priorización: algunas herramientas de gestión ágil incorporan IA para sugerir reordenaciones del backlog o alertar sobre WIP excesivo, usando los principios kanban como lógica subyacente.

Error frecuente

Tratar el tablero kanban como un fin en sí mismo. Un tablero kanban es una herramienta de visibilidad, no un método de gestión completo. Si el equipo actualiza el tablero pero no actúa sobre lo que revela —cuellos de botella que se repiten, WIP que se dispara, tareas que llevan días en el mismo estado— el tablero se convierte en decoración. El valor de kanban está en las conversaciones y decisiones que genera, no en el tablero en sí.

Referencias

Kniberg, Henrik; Skarin, Mattias. (2009). Kanban and Scrum: Making the Most of Both. InfoQ. Ohno, Taiichi. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.

Véase también

¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.