Kanban: origen y definición - Revision history

Mberne at 12:47, 12 January 2024

2024-01-12T12:47:27Z

← Older revision		Revision as of 14:47, 12 January 2024
Line 37:		Line 37:
	==Véase también==		==Véase también==
	*[[Lean]].		*[[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]]

Mberne at 09:46, 19 December 2023

2023-12-19T09:46:12Z

← Older revision		Revision as of 11:46, 19 December 2023
Line 35:		Line 35:
	*'''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 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 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]].
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]

Mberne at 09:41, 19 December 2023

2023-12-19T09:41:49Z

← Older revision		Revision as of 11:41, 19 December 2023
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, 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.
	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==

	{{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 información para mejorar la eficiencia en la ejecución de las tareas de un proyecto}}		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 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.		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.		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.


			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 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):		Según Kniberg & Skarin al considerarlos así, se dibujarían las siguientes diferencias entre ellos(Kniberg & Skarin, 2009):
	*Scrum prescribe roles, kanban no.		*Scrum prescribe roles, kanban no.
Line 36:		Line 33:

	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:		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) …”

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

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]

Smanager at 08:22, 26 April 2021

2021-04-26T08:22:56Z

← Older revision		Revision as of 10:22, 26 April 2021
Line 42:		Line 42:
	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 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?.”

	[[Category:~~Scrum II~~]]		[[Category:Glosario de términos]]

Smanager at 16:27, 2 May 2014

2014-05-02T16:27:41Z

← Older revision		Revision as of 18:27, 2 May 2014
Line 1:		Line 1:

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

	{{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}}

	===~~Su aplicación~~ en el sector TIC===		{{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 información para mejorar la eficiencia en la ejecución de las tareas de un proyecto}}

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

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


Line 15:		Line 21:


	Algunos autores consideran a ~~Scrum~~ y ~~Kanban~~ marcos ~~o métodologías que prescriben~~ prácticas~~, artefactos y roles concretos~~.		Algunos autores consideran a scrum y kanban como marcos de reglas y prácticas diferentes.
	Según Kniberg & Skarin se ~~dibujan~~ las siguientes diferencias entre ellos [[Kniberg & Skarin, 2009]]:		Según Kniberg & Skarin al considerarlos así, se dibujarían 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 35:
	*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 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 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?.”


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

	[[Category:Scrum II]]		[[Category:Scrum II]]

Smanager at 19:06, 27 August 2013

2013-08-27T19:06:15Z

← Older revision		Revision as of 21:06, 27 August 2013
Line 16:		Line 16:

	Algunos autores consideran a Scrum y Kanban marcos o métodologías que prescriben prácticas, artefactos y roles concretos.		Algunos autores consideran a Scrum y Kanban marcos o métodologías que prescriben prácticas, artefactos y roles concretos.
	Según Kniberg & Skarin se dibujan 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).

Smanager: Created page with " 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 ..."

2013-08-20T12:10:21Z

Created page with " 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 ..."

New page

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.

{{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}}

===Su aplicación en el sector TIC===

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

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

Algunos autores consideran a Scrum y Kanban marcos o métodologías que prescriben prácticas, artefactos y roles concretos.
Según Kniberg & Skarin se dibujan 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 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:

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

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

[[Category:Scrum II]]