Hola a todos,
En el último artículo os explique en que se basaba la metodología SCRUM y como algunos ya os habréis imaginado, hay situaciones en que, por buena que sea esta metodología, no va a funcionar de ninguna manera, por ejemplo en un equipo que se dedique a dar servicio de mantenimiento en que la respuesta no se puede alargar 2 semanas, sino como mucho horas. Además es muy normal que haya situaciones en que la carga de trabajo entre los diferentes miembros del equipo o de la cadena de producción no esté balanceado y por lo tanto se produzcan retrasos en la entrega del producto solamente por que una de las fases del desarrollo está demasiado cargada de trabajo. Todo esto SCRUM es incapaz de solucionarlo.
Para estas situaciones nació KANBAN (en japonés "tablero visual") , una forma de trabajar nacida en TOYOTA (de hecho apareció bastante antes que SCRUM) y pensada para producir coches más rápido y barato, pero que se puede aplicar a cualquier proyecto. Aparte de ser una metodología ágil se la conoce como uno de los troncos de la filosofía JIT (Just In Time). No explicaré aquí el KANBAN tradicional usado en la industria automovilística debido a que tiene poco que ver con la industria del software, pero si la parte más aceptada dentro de nuestro negocio.
La idea es sencilla, cada persona,departamento o elemento de la cadena de producción puede hacer un máximo de cosas a la vez en función de sus capacidades y recursos, lo que se le llama WIP (Work In Progress) Darle menos trabajo implica la posibilidad de perder dinero por que hay gente que no está haciendo nada o que en poco tiempo se va a quedar sin trabajo, darle más trabajo del que puede absorber no va ha hacer que ese eslabón de la cadena produzca más, sino más bien al contrario, se estresará, intentará ir más rápido y por lo tanto, hará el trabajo de menos calidad (y luego vendrán bugs que encarecerán el coste final del producto).
La solución entonces es obvia, cada fase del desarrollo no tiene que dar más trabajo a la siguiente fase que el que ésta pueda absorber, pero... que hacemos con el trabajo que hemos acabado y no hemos podido entregar a la siguiente fase? En principio lo tendremos que "guardar". Si es un periodo corto de tiempo no hay problema, estas cosas pasan, podemos seguir trabajando en otras cosas , pero si de mientras que tenemos "guardado" un producto para la siguiente fase ya hemos acabado otro parte del trabajo tenemos un problema gordo y hemos de parar immediatamente de producir. El siguiente eslabón va hasta los topes de trabajo y a la que acabe lo que está haciendo ya le están esperando como mínimo dos tareas más. Tenemos un problema en la producción bastante serio y que se ha de solucionar.
Como solucionar este problema? Hay varias maneras dependiendo de la situación. Una posible solución (si es un problema continuado) es asignar más trabajadores a la fase conflictiva a fin que pueda absorber más trabajo. Otra solución es intentar mejorar el proceso productivo de esa fase (replantearse tareas que aporten poco valor al producto, automatizar , mejorar en general los tiempos de respuesta ).
Si esta saturación es una cosa que pasa de vez en cuando y de manera más o menos aleatoria, tal vez la inclusión de nuevos trabajadores es innecesaria gran parte del tiempo y la mejora del proceso productivo (aunque siempre necesaria) es insuficiente para estos casos más o menos puntuales. La mejor solución en estos casos es que los elementos de la cadena que se queden sin trabajo por culpa de esta saturación (es decir, principalmente el que le da trabajo a la fase conflictiva y el que absorbe el trabajo de ésta) se pongan a ayudar en lo que puedan en la zona conflictiva. Ayudar significa ayudar en su máxima extensión, desde traer un café , aportar ideas, desarrollar software interno para automatizar tareas o realizar betatesting por ejemplo, cada uno en función de sus capacidades. Cada fase tiene una cierta especialización y se comprende que la ayuda que se pueda aportar no será como la de tener X personas especialistas trabajando en esa fase, pero todo ayuda.
La gracia de KANBAN no es que se gestione mejor o peor la producción de software que con otros métodos sino que los cuellos de botella emergen en toda su esplendor pidiendo a gritos que alguien los arregle. Si se es capaz de arreglar los cuellos de botella el ritmo de producción aumenta considerablemente , pero además se consigue que los trabajadores vivan mejor sabiendo que el trabajo nunca les faltará ni se les acumulará y por lo tanto rendirán más y mejor.
En el mundo del software el tablero típico de KANBAN vendría a ser algo así:
0 comentarios :
Publicar un comentario