Etiqueta: WIP

Kanban en una organización tradicional: Primeros pasos

Estoy trabajando con una empresa con las siguientes características:

  • Desarrolla sistemas de software complejos.
  • Actualmente está en curso un proyecto estratégico, que consiste en varios proyectos relacionados entre ellos
  • Cada proyecto involucra a equipos de distintas funciones y la coordinación entre los equipos no es fácil. Los desarrolladores están sobrecargados, a veces participan en más de un proyecto y trabajan horas extras.
  • Los Jefes de Proyectos están tan sobrecargados que hace varios meses la empresa decidió contratar asistentes para ayudarles con las tareas administrativas
  • Los retrasos en los proyectos no son excepciones
  • El proyecto estratégico se gestiona proyecto por proyecto.
  • Aunque en el sistema de gestión de la empresa se recopila una variedad de datos de los proyectos individuales, determinar el estado real del proyecto grande no es sencillo.
  • La empresa está implementando CMMI® nivel de madurez 3.
  • La gente ve cualquier metodología como una carga adicional de trabajo

En esta situación la empresa está interesada en establecer una forma ligera de gestión de proyectos que le permita:

  • Controlar el flujo de las actividades de desarrollo
  • Reducir los retrasos
  • Resolver los problemas de los proyectos a tiempo
  • Facilitar la colaboración entre los equipos funcionales dentro de un proyecto, así como las entre varios proyectos.

Kanban es un método apropiado para el contexto, sin embargo sé que la introducción del nombre de otro método puede confundir a la gente y algunos pueden ver la implementación de CMMI en riesgo (aunque yo controlo esto bien).

Por lo tanto, he sugerido aplicar algunos principios de Kanban como un medio para implementar las prácticas del área de proceso de Gestión Integrada de Proyectos de CMMI, relacionadas con la gestión del proyecto y la coordinación y colaboración entre las partes implicadas.

El tablero

Para empezar hemos diseñado los siguientes tableros para visualizar el flujo de trabajo de un proyecto individual

Tablero_Proyecto

y el estado del proyecto grande

Tablero_Portfolio_Interno

Las columnas tienen el siguiente significado:

  • Pendiente: Requisitos que están por empezar a trabajar en ellos
  • AF: Análisis Funcional
  • Code & Pru: Códificación y Pruebas
  • VAL: Validación. El equipo de Validación, en este caso, se dedica explícitamente a validar los desarrollos de todos los proyectos
  • En Prod: Requisitos que ya están implementados y subidos a producción
  • Hecho es una columna-colchón que se utiliza para recopilar los requisitos desarrollados antes de pasarlos a Validación o antes de subirlos a Producción.

En la columna izquierda presentamos:

  • <Nombre de proyecto>: <número de la iteración en curso>
  • Esfuerzo: <%Planificado> • <%Actual>
  • Fecha fin: <Planificada> • <Actual>

Las tarjetas amarillas representan Requisitos de Usuario. Las tarjetas moradas indican trabajos bloqueados por alguna razón. Las naranjas están reservadas para las peticiones de cambios a los requisitos. A nivel de proyecto individual hemos designado una fila especial para las peticiones de cambios a los requisitos con el fin de controlarlos mejor.

Límites de Trabajo-En-Curso (WIP: Work-In-Progress)

Con respecto a los límites WIP, los vamos a establecer paulatinamente. Empezamos con la simple política que una persona puede trabajar sobre una sola tarea en un proyecto. Por lo tanto los límites WIP de una columna se establecen en base al número de los miembros del equipo. En el tablero del proyecto grande los límites WIP están establecidos por columna y por proyecto.

Ventajas y temas abiertos

Vemos varias ventajas asociadas con esta solución inicial, así como algunos problemas pendientes a resolver. Resumiendo:

  • Ventajas:
    • Los Jefes de Proyectos y sus asistentes tendrán que dedicar mucho menos tiempo a la identificación del estado de proyecto y confección de los informes de seguimiento ya que la mayoría de la información está en el tablero.
    • La coordinación y colaboración en los proyectos son más enfocadas y requieren menos tiempo debido a la imagen completa del estado y las dependencias en el proyecto visualizadas en el tablero
    • Priorización de los requisitos de usuario: El principio actual usado a menudo es «el que más llora más requisitos implementados consigue». Nuestra intención es de vincular la priorización de los requisitos con la capacidad del equipo disponible y el valor que aportan al usuario.
  • Temas abiertos
    • Herramienta: El mantenimiento manual del tablero no se ve factible a largo plazo. Por lo tanto, tenemos que encontrar una herramienta Kanban que puede ser fácilmente integrada con el sistema de gestión de la empresa.
    • Planificación inicial del proyecto: La estimación del tiempo necesario para el proyecto, aplicando la Ley de Little, requiere estabilizar el flujo de trabajo y usar datos históricos de los tiempos de desarrollo de los requisitos. Todavía no estamos preparados para empezar con esta forma de planificación por tanto seguiremos con el método tradicional de estimación hasta que podamos incorporar métricas de Kanban.

Bueno, esto es lo que tenemos hasta ahora.

¿Cómo lo ves?

Deja tus comentarios abajo.

Artículos relacionados:

La Ley de Little

El origen de la ley de Little es la Teoría de las Colas. Es quizás la ley más conocida en el modelado del rendimiento de los sistemas TI.

La ley demuestra las relaciones entre el Lead Time, el Trabajo en curso (WIP) y el Rendimiento (Throughput).

Little's Law

  • El Lead time: El período entre la entrada de un petición en el sistema (petición  solicitada) y la recepción de la petición. Se mide por el tiempo transcurrido (minutos, horas, etc). La petición puede ser un requisito, una historia de usuario, una incidencia, material, una solicitud de un usuario, etc.
  • Trabajo en curso (WIP – Work In Process): el número de peticiones (unidades de trabajo) que se están procesando, es decir las que han entrado en el sistema, pero todavía no han salido.
  • Rendimiento (Throughput): el número de unidades de trabajo que salen del sistema en un tiempo determinado, p.ej., 3 historias de usuario por día.

Las conclusiones de esta ley son igual de interesantes e importantes:

  • Cuanto más grande es el WIP, más largo es el Lead time, es decir más tardamos en terminar el trabajo empezado. Dicho de otra manera, para cumplir los plazos de desarrollo o de los servicios, hay que reducir el trabajo en curso, o sea procurar de cerrar trabajos antes de abrir nuevos.
    Sin embargo, en muchas ocasiones ocurre justo lo contrario: los equipos empiezan a trabajar sobre muchas tareas para que así el proyecto entero “avance” más rápidamente. Otra razón por la que se busca asegurar mucho trabajo en curso es conseguir una alta utilización de los recursos.
    Independientemente del motivo, suponiendo que el rendimiento no cambia, el aumento del trabajo en curso aumenta también el tiempo necesario para su realización.
    Aunque parezca contra intuitivo, recuerda que reducir el trabajo en curso ayuda a cumplir los ANS y reducir los tiempos de desarrollo.
  • Enfocándose en reducir el Lead time ayuda identificar las actividades obsoletas que se están llevando a cabo. Eliminándolas tiene dos efectos positivos: (1) se eliminan desperdicios en los procesos, (2) se reduce el trabajo el curso total que resulta en un ciclo de desarrollo más corto y más eficiente.
  • Cuanto mayor es el Rendimiento, tanto más corto es el Lead time.
    Existen diferentes formas de mejorar el rendimiento: automatizando las actividades de valor (automatizar actividades que no aportan valor es equivalente a automatizar la producción de desperdicios), mejorando los procesos o añadiendo más recursos. Si decides añadir más recursos, observa el Lead time porque en general los recursos adicionales  añaden más trabajo en curso.
  • Cada iniciativa Lean procura de minimizar los desperdicios y de reducir los ciclos de producción. Reduciendo el ciclo de producción es equivalente a reducir el Lead time. Minimizar los desperdicios incluye un análisis del inventario actual y los pasos para reducirlos. Esto es equivalente a la reducción del WIP.

¿Por qué esta ley es importante para los Jefes de proyectos?

La ley de Little es una herramienta de conocer el rendimiento real de un equipo de operaciones o de desarrollo de software

  • Proporciona previsibilidad en el proceso.
    P.ej., si tenemos que implementar 50 requisitos y la capacidad del equipo es de unos 5 requisitos por semana, el tiempo que necesitaremos es

50 requisitos/5 requisitos por semana = 10 semanas.

  • Demuestra que cuanto más grandes son los batches de trabajo, tanto más largo es el tiempo de su procesamiento, el Lead time.
  • Explica por qué las multi-tareas retrasan en lugar de acelerar la terminación de trabajo.
    Habitualmente las personas creen que trabajar sobre varias tareas en paralelo aumenta la productividad. Por eso asignar unas cuantas tareas a una persona es una práctica común en las empresas. Sin embargo, a diferencia de las máquinas, las personas no son tan buenas en la ejecución de procesos paralelos. Aumentando el Trabajo en curso aumenta también en tiempo de cambiar y re-tomar las tareas y por lo tanto reduce el Rendimiento. A consecuencia, el tiempo para ejecutar el proyecto resulta insuficiente, el trabajo empezado y no terminado empieza a acumularse.
    En breve, la ley de Little ayuda a encontrar el punto de equilibrio entre el Trabajo en curso y el Lead time.
  • Proporciona los fundamentos para llegar a los óptimos límites de WIP. Si los límites de WIP están por debajo del nivel óptimo, hay recursos infrautilizados y el rendimiento es bajo. Si los límites WIP superan el nivel óptimo, entonces las unidades de trabajo empiezan a montar colas y el rendimiento baja.
  • Ayuda entender qué efectos tendrá sobre los plazos del proyecto o el servicio el bloquear un trabajo o tener que corregir errores. En ambos casos baja el rendimiento y de ahí aumenta el Lead time.

Condiciones importantes para que funcione la ley de Little

La ley de Little es muy útil, pero además de conocer la formula tienes que tener en cuenta las condiciones necesarias que se deben cumplir para que la ley de Little te sirva:

  • Se cogen valores medios de todos los parámetros: promedio del Lead time, promedio del trabajo en curso, y promedio del rendimiento
  • Las unidades deben ser coherentes, p.ej. si medimos el rendimiento en una semana, el lead time también tiene que ser en semana, así como el promedio del trabajo en curso
  • El sistema tiene que estar estable, es decir todo el trabajo que entra en el sistema, sale de este, el WIP total al inicio y al final del periodo es constante, la tasa media de llegada de trabajo es igual a la tasa media de salida de trabajo del sistema.
  • Para resumir, el uso correcto de la ley de Little ayuda conseguir un flujo de trabajo suave y estable, y a mejorar la previsibilidad de los proyectos y los servicios TI. El Trabajo en curso (WIP) es un factor clave para el rendimiento y el tiempo necesario para el desarrollo de software y/o la ejecución de los servicios. Limitar el trabajo en curso además de reducir el Lead time lleva a una reducción de los desperdicios en el flujo de trabajo.

Artículos relacionados:

Referencias

  1. Little’s Law on wikipedia
  2. Little’s Law – artículo en formato .pdf