Kanban: origen y definición: Difference between revisions

From Scrum Manager BoK
No edit summary
No edit summary
 
(4 intermediate revisions by 2 users 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.
==Origen==
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.


El término japonés Kanban, acuñado por Taiichi Onho (Toyota), 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. Hace referencia a un sistema de visualización empleado en los procesos de producción para coordinar en una cadena de montaje la entrega a tiempo de cada parte que cada parte, y sólo cuando se necesita, reduciendo al mismo tiempo la sobreproducción o almacenamientos innecesarios.  
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.


{{Párrafo_enmarcado|texto=El término kanban aplicado a la gestión ágil de proyectos se refiere a técnicas de representación visual de la información para mejorar la eficiencia en la ejecución de las tareas de un proyecto}}
==Kanban en el sector TIC==


===Su aplicación en el sector TIC===
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.


El uso de tableros kanban facilita la visualización y gestión del flujo constante de avance y entrega evitando los dos problemas más importantes: cuellos de botella y tiempos muertos.
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.  
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.
Desde 2005 es cada vez más frecuente reemplazar los formatos de lista para las pilas de producto y de sprint por notas adhesivas, que resultan más versátiles al poder cambiar su posición: para reordenar las prioridades de las historias de una pila de producto, e informar desde su posición cuáles se están programando, o probando, o ya se han terminado.
Las prácticas kanban son una ayuda especialmente útil en la gestión de proyectos evolutivos con entregas continuas. Como herramienta de control visual debe emplearse con criterios de flexibilidad, sin considerar prescripciones ni excepciones en el método de trabajo, para lograr la implementación personalizada, que de la mejor respuesta a los principios ágiles, de ingeniería concurrente o de síntesis de ambos, con los que trabaje la organización.  


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.
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.


==Gestión técnica vs. gestión experta==
==Gestión técnica vs. gestión experta==


Algunos autores consideran a ''scrum'' y ''kanban'' como marcos de reglas y prácticas diferentes.


Algunos autores consideran a Scrum y Kanban marcos o métodologías que prescriben prácticas, artefactos y roles concretos.
Según Kniberg & Skarin al considerarlos así, se dibujarían las siguientes diferencias entre ellos(Kniberg & Skarin, 2009):  
Según Kniberg & Skarin se dibujan las siguientes diferencias entre ellos [[Kniberg & Skarin, 2009]]:
*Scrum prescribe roles, kanban no.
*Scrum prescribe roles, kanban no.
*Scrum trabaja con iteraciones de tiempo fijo, kanban con cadencias (simples, múltiples o dirigidas por eventos).
*Scrum trabaja con iteraciones de tiempo fijo, kanban con cadencias (simples, múltiples o dirigidas por eventos).
Line 29: Line 32:
*Los tableros scrum se resetean al final de cada sprint.
*Los tableros scrum se resetean al final de cada sprint.


Al entrar en un modelo de gestión basado en la experiencia y conocimiento propio, y abandonar el modelo de gestión técnica, se flexibilizando las prácticas, y pierden relevancia cuestiones “técnico-metodológicas” como las siguientes:
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?.”
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) …”  
==Véase también==
 
*[[Lean]].
 
*[[Tableros kanban: conceptos]].
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?.”
*[[Tableros kanban: operativa]].
 
*[[Ejemplo de tablero kanban: "Kanban Box" para una oficina multiproyecto]].
 
*[[Ejemplo de tablero kanban: desarrollo evolutivo con incremento iterativo]].
El uso de kanban como metodología definida es una opción de trabajo para la gestión técnica, pero no para la autogestión y la gestión experta, porque limita la flexibilidad en la implantación
*[[Ejemplo de tablero kanban: desarrollo evolutivo con incremento continuo]].
 
*[[Ejemplo de tablero kanban: información relativa al estado de desarrollo del producto]].
[[Category:Scrum II]]
*[[Ejemplo de tablero kanban: equipo de operación y mantenimiento]].
[[Category:Glosario de términos]]

Latest revision as of 13:47, 12 January 2024

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.

Origen

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.

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 en el sector TIC

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.

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.

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.

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.

Gestión técnica vs. gestión experta

Algunos autores consideran a scrum y kanban como marcos de reglas y prácticas diferentes.

Según Kniberg & Skarin al considerarlos así, se dibujarían las siguientes diferencias entre ellos(Kniberg & Skarin, 2009):

  • 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 de 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.
  • 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.
  • En scrum se deben estimar las historias y las tareas y calcular la velocidad, kanban no mide tareas ni velocidad.
  • 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