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 
Comenta la entrada