Ya hemos hablado anteriormente de Kanban y de cómo mezclar lo con Scrum para implantar una cultura Agile dentro de nuestros proyectos. Uno de los objetivos de todo del manifiesto ágil es entregar software que funciona y que el cliente necesita. Por ello herramientas como Kanban nos ayudan a tener una visión global del proyecto.
Este post es una traducción libre de http://java.dzone.com/articles/estimation-and-measurement
Ya hemos visto que el sistema Kanban nos puede ayudar en:
- Aumenta la visibilidad del flujo del proyecto (quien está haciendo qué, si hay algún problema en el flujo de trabajo)
-
Se limita el work in progress al mismo tiempo, de manera que el software entregado está más focalizado, entregas más rápidas.
-
Permite que te des cuenta inmediatamente de si hay un bloqueo en el flujo del proyecto.
-
Hace que la resolución de bloqueos sea más fácil.
Límite del “Work in progress” y la ley de Little
Podemos comparar kanban a una cola. Solo empezamos a trabajar en nuevas tareas si se han completado las que estábamos realizando en ese momento. Por ello deberíamos, con el fin de poder planificar las tareas de futuro, cuál debería ser el “work in progress” (WIP) utilizando la “Ley de Little”.
Normalmente es que WIP varíe en función del proyecto y del equipo. Por tanto debemos y podemos adaptar el WIP en todos los proyectos.
Podemos calcular fácilmente el WIP si conocemos la fecha de entrega de un proyecto y se conoce el tiempo medio por tarea (por ejemplo una semana)
Veamos un ejemplo:
Si el proyecto nos va a llevar un año y entregar una tarea (de media) una semana, entonces podemos decir que WIP es 3.
¿Por qué es tan necesario el límite?
Es necesario centrarse en un objetivo con el fin de poder terminar el trabajo correctamente.
Nos pasa a todos, no pasa nada si intentamos hacer 10 tareas al mismo tiempo. El único inconveniente es el tiempo que se pierde al cambiar de una tarea a otra (Costo del cambio). También es cierto que al realizar varias tareas al mismo tiempo no ponemos el foco (nuestra atención al 100%) en todas. Limitando el WIP lo que hacemos que ahorrar tiempo al saltar de tareas.
Este sistema también nos ayuda a localizar los errores y evitarlos. Si solo tenemos 3 tareas que hacer es más fácil ir corrigiendo errores que si tenemos una pila de 10.
Seguimiento del proyecto en términos kanban
Hay 2 tipos de gráficos muy populares a la hora de ver como evoluciona el proyecto:
- CFD(Diagrama de flujo Acumulativo)
-
Analisis Semanal Velocity.
CFD ofrece una visión más clara de gráficos “burn down”
Análisis Semanal Velocity
Responde a la pregunta ¿Cuántos requisitos hemos terminado esta semana?
Kanban necesita tiempo para mejorarse a sí mismo
Nos es bueno trabajar a un ritmo continuo. Si la CPU funciona siempre al 100% no tenemos margen para mejorar. La creación de tiempo libre nos ayuda a mejorar. Esto siempre permite terminar los trabajos con mayor rapidez.
Kanban antes que kaizen
Los problemas se notan con mayor rapidez cuando se limita el trabajo. Cada problema observado es la mejor oportunidad para el desarrollo (kaizen). Para poder comprender el espíritu kaizen (“¡Hoy mejor que ayer, mañana mejor que hoy!”) es necesario revisar y aplicar kanban.
Recursos
Lean from the Trenches: Managing Large-scale Projects with Kanban
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
David Anderson -Kanban: Successful Evolutionary Change for Your Technology Business
Jesús L.C. - Apuntes de un aprendiz 
Useful information shared..Iam willing to read this article..thanks for supplying us great info.Amazing walk-through. I see why post.
Me gustaMe gusta
Muchas gracias por tu aporte Jesús!
Si bien la fórmula de TIEMPO= WIP/Tiempo Medio puede ofrecer una idea inicial, el resultado final podría no ser tan bueno en el mediano plazo (trataré de explicar porqué a continuación).
Si el equipo ha sobrecalculado sus estimados o los procesos son deficientes, entonces el resultado conservará las carencias y las amplificará. La idea es que Kanban mejore la calidad y baje los costes eliminando los retrasos e indicando un WIP, y todo esto se logra formulando las políticas de forma explícitas y visibles. De lo contrario sería como instalar semáforos en una avenida sin primero analizar el tráfico y sus características.
Esto quiere decir que por ejemplo, si se tiene un valor 5 de WIP en una columna y esto va bien para el desarrollo pero genera una cola para la parte de pruebas u otra área, entonces se debería prestar atención al flujo o equipo y buscar una adecuación al mismo. Esto podría ser por ejemplo «si en general se tienen 6 fichas en una columna pero el máximo es 5, entonces analizar la estructura del equipo, el flujo, ver el problema, buscar una solución, expresarla reglas visibles y rever WIP.». Por ejemplo, si hay mas de 5 entonces analizar la estructura del equipo, ver que procesos llevan mas tiempo y porqué, y escribir algo que se deberá hacer siempre para poder mover una tarjeta de una columna a otra (ej. si> 5 entonces pedir ayuda a Juan y Pedro que para que ayude con tal cosa).
El crear reglas explícitas basadas en el movimiento de las tarjetas entre columnas permite que el WIP esté relacionado con ellas y sea de mejora constante y por supuesto ello debería ser discutido con el grupo y no dictado por una jerarquía. Ésta discusión fuerza al mismo a tener una conversación sobre ello así como un crecimiento.
Representar el flujo es entonces la parte más importante, lo que permite en sí una mejora.
Una de las formas de transformar Kanban de un tablero a una herramienta que aumente el valor de negocio producido y disminuya el tiempo obsoleto o de espera (cuando se pasa una tarea a otro grupo o persona y ella está ocupada o demora su comienzo) es preguntarse:
1. ¿Quién o quienes son las personas que trabajan en mejorar el flujo y cómo lo hacen?
2. ¿Qué tiempo en total gasta la empresa en su totalidad en tiempos de espera?
3. ¿La eliminación del tiempo de espera entre tareas se ha transformado en un incremento del valor de negocio producido?
4. ¿Las metodologías actuales de trabajo apoyan la disminución activa de los tiempos de espera o lo contrario?
La mayor parte de las empresas de software se apuran a instalar un tablero Kanban y definir un WIP, no obstante, al ver las reglas de LEAN, podemos apreciar que establecer WIP se encuentra último. ¿Qué se hay antes (o debería hacer previamente)?
1. Gestionar la carga de los equipos a nivel global
Rever si se pueden disminuir los tamaños de las tareas y la especificación de incrementos en el software de forma regular, lo que disminuirá ciertamente las pilas y tiempos de respuesta.
2. Estructurar los equipos corréctamente.
Ver como están compuestos los equipos y si se pueden mejorar de acuerdo a la situación actual (que puede ser diferente en unos meses o semanas).
3. Oden del flujo de trabajo
Analizar el flujo y ver como mejorarlo (con las posibles reglas explícitas entre columnas).
4. WIP
Indicar el WIP
Seguir estos pasos en éste órden implica un cambio de mentalidad en cuanto a que se deberá asumir que la forma en la que se hacían las cosas anteriormente quizá ya no sea más válidas.
Muchas gracias por tu aporte y la oportunidad de iniciar esta convesación.
Me gustaMe gusta
Hola, lo primero gracias por el comentario. Es genial que aportes otro punto de vista a la cuestión.
Como dices, es necesario tener a alguien en el equipo que revise el proceso productivo. Por ello es necesario que alguien chequee al equipo para conocer si esta cómodo con el Wip que se ha calculado.
Hace tiempo realice otro post con la siguiente idea:
Los equipos scrum deben ser multidisciplinares, aún teniendo a alguien por ejemplo que sea muy bueno maquetando, si hay un atasco en testing y el maquetador esta algo libre debe ayudar en testing. Te dejo el post por si quieres echarle un vistazo:
https://jesuslc.com/2013/06/07/de-scrum-a-lean-kanban-una-gran-herramienta/
Así qué resumiendo, la fórmula puede ser válida en un principio, pero si vemos que el equipo no esta cómodo, o el Wip no es fluido debemos comprobar si es el Wip calculado el que hace que el trabajo no vaya fluido.
Un saludo y gracias por comentarios tan trabajados 😉
Me gustaMe gusta
Reblogged this on Agile Lean Scrum Kanban para Ibero américa and commented:
Jesús publicó un artículo estos días sobre estimación y medición con Kanban. A su vez, e incluído com comentario mi punto de vista sobre WIP (Work in progress) y los beneficios de Kanban, para así poder tener una visión más global de la mejora de procesos y equipos mediante el pensamiento planteado por LEAN.
Me gustaMe gusta
Hola Jesús,
Interesante post! Sin embargo, tengo una duda existencial cuando dices «Si el proyecto nos va a llevar un año y entregar una tarea (de media) una semana, entonces podemos decir que WIP es 3.». la pregunta es, como se que el proyecto me va a llevar un año? Digamos, que técnica se utiliza para estimar el tiempo que nos va a llevar el proyecto?
]Gracias desde ya,
Jay
Me gustaMe gusta