El desarrollo de software que todos sufrimos en estos días es muy similar al sistema de producción "just in time" por lo que no es descabellado adoptar paradígmas que funcionan es otros entornos de producción.
Al igual que en una planta de coches el driver que dispara la producción es el equipo de ventas que hace un pedido, en los equipos de desarrollo de software en disparador son los requisitos, las peticiones de cambio, o los defectos detectados.
Condición “sine qua non” para una mínima organización de un equipo de desarrollo es que conozcamos cuál es el ciclo desarrollo que seguimos desde que recibimos un "requisito", hasta que el cliente dispone del software que lo implementa. Este flujo es comparable a la línea de producción de una fábrica tradicional.
Un sencillo ejemplo de un flujo de trabajo:
requisito >> análisis >> construcción >> calidad >> aceptación del cliente.
La idea es asignar a cada uno de estos requisitos un identificador: El "kanban". Para que en todo momento los equipos que se encargan de cada tarea sepan en qué están trabajando. Al mismo tiempo, permitirá al jefe de proyecto conocer cuál es el estado de cada requisito y calcular métricas sobre los diferentes procesos.
¿Como articular esto?: Podemos empezar por una sencilla hoja de excel. Aquí podmeos ver claramente el pool de Kanbans pendientes al final de la hoja.
La idea no es nueva, por ejemplo: los códigos de incidencia de un equipo que se dedique a arregar defectos pueden ser tomados como Kanban. Las herramientas lo soportan fácilmente, por ejemplo: Clear Case puede almacenarlo sin problemas en la actividad.
Simplemente trataba de adecuar los paradigmas del "lean management" tradicional al mundo del desarrollo.
0 comentarios:
Publicar un comentario en la entrada