![\"Gesti\u00f3n](\"https:\/\/www.scrummanager.com\/blog\/wp-content\/uploads\/2013\/08\/kanban_operativa.png\")
<\/a><\/p>\n<\/p>\n
<\/p>\n
La principal car\u00e1cter\u00edstica del ciclo est\u00e1ndar de Scrum es el uso de tiempo prefijado (timeboxing) para mantener el avance continuo del trabajo marcando \u00abpulsos\u00bb de sprints.<\/p>\n
El timeboxing<\/em> obliga de forma pragm\u00e1tica al mantenimiento de un ritmo de avance, reduciendo la tendencia natural a la dilataci\u00f3n los tiempos de entrega previstos.<\/p>\n Los equipos que desarrollaron Scrum, observados y descritos por Nonaka y Takeuchi (Nonaka & Takeuchi, The New New Product Development Game, 1986) y los principios del manifiesto \u00e1gil no prescriben que deba emplearse tiempo prefijado o \u00abtimeboxing\u00bb para mantener el avance en el incremento continuo del producto.<\/p>\n El equipo puede tambi\u00e9n sostener un flujo constante de las tareas una tras otra, sin empaquetar en incrementos cerrados para cada pulso de timeboxing (sprint).<\/p>\n Pero mantener un flujo continuo de tareas no es f\u00e1cil porque suelen formarse zonas de cuellos de botella que taponan el avance, y producen en otras tiempos muertos sin tareas que realizar.<\/p>\n La gesti\u00f3n visual kanban es la t\u00e9cnica m\u00e1s empleada actualmente para regular un flujo continuo de tareas en proyectos TIC y de servicios del conocimiento con gesti\u00f3n evolutiva.<\/p>\n Las pr\u00e1cticas de gesti\u00f3n visual con kanban son \u00fatiles para:<\/p>\n Un tablero kanban puede emplearse con uno de estos fines, o con los dos a la vez, aunque en realidad si se usa para mantener el flujo del trabajo, siempre acompa\u00f1a el hecho de mostrar la informaci\u00f3n de avance del trabajo.<\/p>\n Monitorizaci\u00f3n y regulaci\u00f3n del flujo y la carga de trabajo<\/strong><\/p>\n La posici\u00f3n de cada tarjeta sobre el tablero refleja el estado en el que se encuentra el trabajo correspondiente. En algunos casos puede resultar conveniente marcar sub estados (por ejemplo: Testeado, Validado).<\/p>\n El orden de los trabajos desde el \u00e1rea \u201cpendiente\u201d, indica ya en el inicio, la secuencia de las tareas seg\u00fan sus prioridades.<\/p>\n Los trabajos monitorizados puede ser del tama\u00f1o de tareas<\/a>, historias de usuario<\/a> o epics<\/a>, seg\u00fan el uso que interese en cada tablero.<\/p>\n Secuencia y polivalencia<\/span><\/p>\n Al dise\u00f1ar la estructura y el funcionamiento de un tablero kanban adecuado a un entorno determinado, dos son las variables de ese entorno a las que debe dar respuesta:<\/p>\n \u00bfLos trabajos reflejados en las tarjetas del tablero tienen que ejecutarse en un orden determinado o pueden realizarse en cualquier orden?<\/p>\n No es lo mismo dise\u00f1ar un tablero para el equipo de programadores de una aplicaci\u00f3n, que para el de mantenimiento de los sistemas inform\u00e1ticos de una empresa. Para los primeros los trabajos se deben completar en un orden de secuencia determinado. As\u00ed por ejemplo, no es posible realizar la tarea de pruebas si antes no se ha hecho la de programaci\u00f3n.<\/p>\n Sin embargo las siguientes podr\u00edan ser las tareas de un equipo de mantenimiento: \u201cinstalaci\u00f3n de nueva impresora en el equipo de direcci\u00f3n\u201d, \u201cactualizaci\u00f3n del sistema operativo en el servidor web\u201d, etc. Este tipo de tareas se pueden realizar en cualquier orden. No hay una relaci\u00f3n de dependencia entre ellas de forma que no se pueda realizar una si la otra no se ha completado..<\/p>\n \u00bfEs un equipo polivalente o de especialistas? \u00bfPor el tipo de trabajo y el perfil de los integrantes del equipo, cualquier miembro puede realizar cualquier tarea?<\/p>\n Siguiendo con los ejemplos anteriores, es posible que en el equipo de mantenimiento la misma persona pueda indistintamente instalar una impresora, o un sistema operativo; o es posible que no: que haya t\u00e9cnicos de hardware y t\u00e9cnicos de software. De forma similar un proyecto de programaci\u00f3n puede incluir tareas espec\u00edficas de dise\u00f1o gr\u00e1fico, o programaci\u00f3n integraci\u00f3n testing, etc que pueden realizar s\u00f3lo determinados miembros del equipo.<\/p>\n Cuatro son los patrones posibles seg\u00fan se combinen tareas secuenciales o libres, con un equipo polivalente o de especialistas:<\/p>\n Este es el entorno m\u00e1s f\u00e1cil de gestionar: cualquier persona del equipo puede realizar cualquier tipo de tarea, y las tareas se pueden tomar en cualquier orden. El hecho de que los miembros del equipo est\u00e9n especializados en determinadas tareas aporta un factor de complejidad para solucionar los posibles problemas de cuellos de botella y tiempos muertos.<\/p>\n Si se producen cuellos de botella, la estrategia con el tipo de tareas que los provocan debe encaminarse en una o en ambas de las siguientes l\u00edneas:<\/p>\n En este caso la dependencia que unas tareas tienen de otras tiende a generar tensiones en el flujo y producir cuellos de botella en puntos determinados de la secuencia. WIP es un t\u00e9rmino ingl\u00e9s que en el campo de la manufactura lean, de donde proviene, se emplea para designar la cantidad de productos a medio fabricar que a\u00fan no est\u00e1n terminados.<\/p>\n En el uso de tableros kanban, por analog\u00eda se emplea este t\u00e9rmino para indicar las tareas que se encuentran en una fase del proyecto pendientes de pasar a la siguiente o de completarse, y en este entorno el t\u00e9rmino WIP se suele emplear con la acepci\u00f3n de l\u00edmite o n\u00famero m\u00e1ximo de tareas que pueden llegar a acumularse en un \u00e1rea determinada. As\u00ed por ejemplo, decir que en un tablero kanban para programaci\u00f3n de software el \u00e1rea de testing o pruebas \u201ctiene un WIP de 3\u201d quiere decir que no puede haber m\u00e1s de tres tareas simult\u00e1neamente en esa fase.<\/p>\n Este es el entorno m\u00e1s complejo porque requiere el ajuste y revisi\u00f3n en todas las l\u00edneas de mejora posible: dimensi\u00f3n y equilibrio de especialistas en el equipo, dimensi\u00f3n o equilibrio de tiempos de respuesta en el compromiso, y ajuste de l\u00edmites WIP en cada fase.<\/p>\n En cada una de estas cuatro situaciones posibles el tablero saca en la superficie los problemas, y el equipo o gestor puede realizar los ajustes en las l\u00edneas de trabajo posibles seg\u00fan cada caso y en funci\u00f3n de su criterio y las circunstancias de su organizaci\u00f3n.<\/p>\n <\/p>\n El ejemplo muestra un posible tablero instalado en la oficina de responsable de producto para reflejar el estado en el que se encuentra la construcci\u00f3n del producto.<\/p>\n En este caso no se emplea la faceta de herramienta para gestinar el mantenimiento del flujo de las tareasl, sino solamente la de \u201cradiador\u201d de informaci\u00f3n visual.<\/p>\n Tablero para mostrar visualmente la siguiente informaci\u00f3n relativa al estado de desarrollo del producto:<\/p>\n <\/p>\n <\/p>\n <\/p>\n Este es un buen ejemplo del principio de flexibilidad<\/a> o adecuaci\u00f3n de las pr\u00e1cticas a la organizaci\u00f3n y no al rev\u00e9s. Kanban, adem\u00e1s de ofrecer informaci\u00f3n visual, permite aplicar t\u00e9cnicas como limitaci\u00f3n del wip y muestra las l\u00edneas de mejora para ajustar la cadencia del flujo. Resulta por tanto \u00fatil, como ya hemos visto para trabajar con incremento continuo<\/a>.<\/p>\n \u00bfPero puede emplear kanban un equipo que haga scrum con incremento iterativo<\/a> para emplear la representaci\u00f3n visual del avance de las tareas en lugar de usar un gr\u00e1fico de avance? (por ejemplo)?.<\/p>\n Por supuesto. Este apartado muestra ejemplos de tableros para ambos casos.<\/p>\n Las siguientes im\u00e1genes representan posibles tableros para guiar la gesti\u00f3n de trabajo de un equipo que est\u00e1 desarrollando un producto en incremento continuo y en el que se refleja la siguiente informaci\u00f3n:<\/p>\n<\/a><\/p>\nTrabajando con tableros kanban: conceptos<\/h2>\n
\n
1.- Kanban para trazar la Gesti\u00f3n y Mantener el flujo.<\/h3>\n
\nLos estados b\u00e1sicos que se suelen representar en un tablero kanban son \u201cpendiente\u201d, \u201cen curso\u201d y \u201cterminado\u201d.<\/p>\n<\/a><\/p>\n\n
Secuencia.<\/h3>\n
Polivalencia<\/h3>\n
Trabajando con tableros kanban: operativa<\/h2>\n
<\/a><\/p>\n1.- Equipo polivalente para tareas que no requieren secuenciamiento.<\/h3>\n
\nSi presenta problemas de saturaci\u00f3n de trabajo o tiempos muertos son: la dimensi\u00f3n del equipo y \/ o la optimizaci\u00f3n del sistema las \u00e1reas que se deben ajustar y mejorar.<\/p>\n2.- Equipo de especialistas para tareas que no requieren secuenciamiento.<\/h3>\n
\n
3.- Equipo polivalente y tareas secuenciales<\/h3>\n
\nLa primera l\u00ednea de mejora en estos casos es el ajuste del WIP de cada fase, antes de antes de analizar el dimensionamiento del equipo y el compromiso.<\/p>\n4.- Equipo de especialistas y trabajo que requiere un orden secuenciado.<\/h3>\n
Ejemplos de posibles configuraciones de tableros kanban.<\/h2>\n
Ejemplo de tablero para ofrecer informaci\u00f3n relativa al estado de desarrollo del producto.<\/h3>\n
\n
<\/a><\/p>\nEjemplos de tableros para desarrollo evolutivo, en incremento continuo y en incremento iterativo.<\/h3>\n
<\/a><\/p>\n Caso 1: Incremento continuo<\/h3>\n
\n
<\/a><\/p>\n