17 de octubre de 2012

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 permite:
  • 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 muy 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 y el estado del proyecto grande:

Tablero de un proyecto


Tablero del proyecto grande

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.

Pros y contras
Vemos varias ventajas asociadas con esta solución inicial, así como algunos problemas pendientes a resolver. Los resumo en la siguiente tabla:


Bueno, esto es lo que tenemos hasta ahora.
Te agradecería tus comentarios.

Y, en cuanto obtengamos algún resultado, bueno o malo, que merece la pena compartir, lo conocerás a través de este blog.

Otros artículos relacionados:

2 comentarios:

  1. Muy interesante! y este pequeño post abre mucho la curiosidad :)
    Por ejemplo, ¿por qué seguir intentando CMMI nivel3, qué les aporta? ¿y ese nivel de CMMI, cómo encaja con la mejora continua que sin duda estarán empezando a realizar los equipos?
    Genial la iniciativa, suerte con el proyecto de implantación, sin duda una de las mejoras que mas se suele agradecer es quitar la priorización del "que más llora" :D Poner un panel anterior a los paneles kanban de los equipos, donde realizar esas priorizaciones de manera transparente, a mi me ha dado muy buenos resultados otras veces.

    ResponderEliminar
  2. Joserra, muchas gracias por tu comentario.

    Si consideras el modelo CMMI como una colección de buenas prácticas, es útil y ayuda a identificar algunos aspectos en las prácticas actuales de trabajo en las que no se ha pensado hasta el moemnto y que se podrían mejorar.
    Estoy consiente que cuando no se implementa bien, añade carga y burocracia innecesaria.
    En este caso, la empresa necesita la certificación como un tipo de demostración que sabe hacer su trabajo y por el tema de benchmarking.

    Gracias por tu apoyo! Ya iré contacto cómo evoluciona esta iniciativa.

    ResponderEliminar