Nuestro proceso de construcción de sistemas no funciona con una metodología ágil "tradicional" con iteraciones de dos semanas (o Sprints). En cambio, usamos un sistema de Kanban para realizar los Pedidos de Cambio (PdC). Cuando se completa un PdC permanece en el estado Listo para Entregar, hasta que ocurre la próxima entrega planificada cada dos miércoles.
Aunque llevamos todas las PdC con Team Foundation Server, el trabajo del día-a-día ocurre sobre una pizarra con notas Post-It que se usan como tarjetas de Kanban.
El día-a-día con Kanban
No tenemos un equipo de mantenimiento dedicado, sino que el proceso de mantenimiento se sostiene con un pool de tamaño variable de personas. Como usamos un límite de Kaban podemos garantizar a la gerencia que vamos a cumplir con nuestro compromiso de dedicar cierto porcentaje de nuestra capacidad a la actividad de mantenimiento, sin tener que asignar y dedicar a personas específicas.
Cada mañana el equipo se reune alrededor del tablero de Kanban para discutir el trabajo-en-progreso y qué hacer para que se siga moviendo (muy parecida a la reunión diaria de Scrum). Todos los días se puede ver a uno de los líderes del grupo llevando adelante la reunión, trabajando con cada una de las tarjetas y discutiendola con el equipo de turno. Las tarjetas en el tablero contiene el título del PdC, su número de identificación, y el nombre de la persona que en ese momento tiene asginada la tarea. Los miembros del equipo tienen la responsabilidad para actualizar el tablero y de mover las tarjetas de kanban a medida que avanzan los PdC por el sistema. El líder utiliza esta reunión diaria para actualizar la versión electrónica del tablero. El sistema de kanban se auto-organiza y tiene una validación diaria con el líder.
Las claves del tablero
Hay algunas claves interesantes para el uso del tablero. Una marca roja indica que el item lleva mucho tiempo y excede nuestro Acuerdo de Nivel de Servicio (SLA) de 28 días para procesar un PdC. Esto nos permite que los elementos "atrasados" puedan tener prioridad sin que la gerencia tenga que intervenir. Los PdC que están bloqueados se les pegan notas rosadas para indicar que hay algún problema abierto. Estas notas rosadas contienen la descripción del problema y el número de identificación en el sistema. Hay otros tipos de notas, como ser para bugs. Los colores que usamos son: Amarillo - PdC valioso para el cliente; Azul - Arreglo de bug valioso para el cliente; Verde - elemento de mantenimiento de IT (por ejemplo, una actualización de la base de datos); Naranja - un bug adicional; Rosa - problemas.
Limitando la demanada
El límite de Kanban para el sistema de de 20 tarjetas, que se dividen en diferentes etapas en el proceso - análisis de sistema, desarrollo, pruebas, construcción / merge, despliegue. Además, permitimos que haya 3 bugs extra en cualquier lugar del sistema. Esta separación del límite de kanban y los 3 bugs nos permite ir quemando el backlog de bugs usando personas que están temporalmente libres. Cuando estas personas dejan de estar libres, quitamos o reducimos el límite de 3 bugs. También hay un límite de kanban de 2 elementos de mantenimiento. Esto nos permite asignar un pequeño porcentaje de las personas a realizar tareas de mantenimiento de IT vitales, como ser actualizar versiones de APIs, cambio de plataformas, etc.
El sistema de Kanban nos permite cumplir con 3 elementos de una "receta para el éxito": reducir el trabajo-en-progreso (de hecho, queda limitado completamente); balancear la capacidad contra la demanda (ya que sólo se pueden agregar nuevos PdC a medida que se liberan tarjetas luego de la entrega); y la prioridad del trabajo. Tenemos una reunión para priorizar los PdC una vez por semana con los vice presidentes de la organización. Pueden elegir nuevos PdC del backlog para asignar a tarjetas de Kaban que estén libres. Esto los fuerza a pensar en una, dos o tres cosas importantes para que se hagan. Se tiene que priorizar de manera forzada.
El sistema de Kanban también nos libera de las limitaciones de las cajas-de-tiempo de las iteraciones. Aunque hacemos publicaciones cada dos semanas, los elementos en el sistema pueden llevar hasta 60 días para moverse en el proceso, dependiendo de su tamaño y complejidad. Se puede agregar al sistema elementos que son muy grandes para una única iteración de dos semanas, e igual se va a trabajar sobre ese elemento sin necesidad de ninguna intervención especial.
Equipos auto-gestionados
Por último, el sistema de Kanban nos liberó de tener que llevar cada iteración como un mini-proyecto. El sistema se volvió auto-gestionado en su totalidad, y se necesita muy poca intervención de la gerencia a menos que ocurran circunstancias excepcionales que requieran de una petición de emergencia, o un cambio en las fechas de entrega por motivos de entorno o temas de mantenimiento.
