T E C N O L O G Í A
Aplicando
Kanban KANBAN ES UNA METODOLOGÍA ÁGIL QUE PERMITE VISUALIZAR EL FLUJO DE TRABAJO, DIVIDIR TAREAS Y OPTIMIZAR EL TIEMPO DENTRO DE LA OFICINA. UNA EFECTIVA ESTRATEGIA PARA LA GESTIÓN DEL CAMBIO QUE TÍMIDAMENTE VA ABRIÉNDOSE CAMINO EN EL UNIVERSO TI.
38
al testing de software POR ERNESTO KISZKURNO Socio Pragma Consultores y NORA SAIDMAN Coordinadora de proyectos de QA de Pragma Consultores
Un enorme tablero domina la pared de la oficina. Distintas tareas llenan filas y columnas junto a pequeños post-it amarillos que se van trasladando de forma dinámica. Detrás de esta aparente telaraña de anotaciones hay una metodología de trabajo conocida como Kanban y que ha demostrado ser muy exitosa en la disciplina del testing de software. La idea es simple y efectiva: las señales visuales marcan bloques de trabajo y el plan es no avanzar con una nueva tarea hasta que no se haya cumplido la anterior en la cadena. Si no se adelanta en el tablero, se corre el riesgo de que los elementos bloqueen el flujo productivo. Una imagen que funciona como una perfecta metáfora del trabajo en equipo. Cualquier problema o “cuello de botella” quedará en evidencia en la pizarra. El nombre Kanban surge de la combinación de dos conceptos: “kan” (visual) y “ban” (tarjeta o tablero). Es un término japonés acuñado por Toyota hace varios años. Ellos lo usaban para señalizar los productos parciales en la línea de montaje fabril. Kanban se enmarca dentro de las llamadas metodologías ágiles que, como su nombre lo indica, buscan dar rapidez y practicidad a los procesos. Entre sus fundamentos –establecidos en el año 2001 en el Manifiesto Agile–, se encuentra el de revalorizar las interacciones entre individuos por sobre los procesos y herramientas o la respuesta ante el cambio. Hoy, a casi una década, estas metodologías –a las que se suman por ejemplo Scrum o Extreme Programming–, se aplican en proyectos de software en todo el mundo. Si bien Kanban se usa en diversas industrias y desde hace mucho tiempo en la de software, en particular se comenzó a utilizar en 2003 gracias a David Anderson, pionero en la materia y autor de varios libros sobre metodologías ágiles.
Kanban en la industria del software El método Kanban fue inventado por Sakichi Toyoda en 1902 con el objetivo de mejorar el proceso de fabricación textil que el Grupo Toyota tenía en aquel momento (en lo que para algunos fue el nacimiento del concepto de “automatización” en la industria). Con el tiempo, el grupo fue evolucionando a la empresa que conocemos hoy y el método a lo que se conoce vulgarmente como Toyota Production System (TPS). En la disciplina de desarrollo de software, y dentro de las herramientas de proceso llamadas ágiles, Scrum es la más usada. Pero, según explica Anderson, Kanban funciona mejor para ciertos procesos de mantenimiento de software, y por eso su amplia difusión actual en esta industria. Pero, más allá de su creciente popularidad, es difícil encontrar referencias al uso de Kanban dentro de la práctica de testing de software. Es un hecho llamativo ya que esta metodología puede estructurar muy bien la actividad de un área o equipo de testing. Henrik Kniberg, reconocido consultor en compañías de IT, subraya tres ejes claves de Kanban. El primero implica visualizar el proceso (workflow) de trabajo, partiendo el trabajo en diferentes piezas. También ayuda a limitar el trabajo en curso (work in progress) y, por último, a optimizar el flujo de trabajo midiendo el lead time (el promedio de tiempo necesario para terminar una pieza). Estos tres puntos son más que importantes a la hora de testear software en forma continua. De la teoría a la práctica Una QAF (Quality Assurance Factory) es un área de servicios compartidos orientada a controlar la calidad de los productos de software elaborados en una determinada organización (u organizaciones). El concepto es similar al ampliamente difundido de Software Factory. Usualmente es vista como una unidad organizacional independiente que provee servicios a sus clientes (internos o externos) y percibe por ello ingresos (un profit center). En algunas organizaciones se encuentra totalmente tercerizada a manos de un proveedor especializado, en otras está formada por recursos propios. Dentro de los desafíos para gestionar una QAF hay dos que son los más importantes. El primero tiene que ver con establecer un modelo de cobros dinámico que permita obtener los recursos necesarios para brindar servicios al nivel de calidad esperado. El segundo implica gestionar la demanda de trabajo. La unidad organizacional tendrá múltiples clientes a los que deberá proveer diferentes servicios, con cronogramas
39
Un caso de éxito variables y cambios constantes (no olvidemos que estamos hablando de proyectos de desarrollo de software). Es en este último punto en el que las metodologías ágiles, y en particular Kanban, pueden ayudarnos. Utilizar un enfoque en cascada (o altamente estructurado) para este tipo de demanda cambiante resulta impráctico en el contexto dinámico que tienen hoy las áreas de sistemas de las grandes organizaciones. En cambio, aplicar metodologías agiles como Scrum o Kanban para gestionar una QAF nos permite disponer de mecanismos para planificar y comunicar los planes altamente efectivos; definir cuánto trabajo puede tomar el área y, en consecuencia, establecer prioridades; entender qué se está haciendo en todo momento y quien lo está haciendo; saber inmediatamente cuando algo ha detenido la correcta ejecución de nuestros planes; introducir cambios de prioridades o ajustar la planificación y, además, interactuar con los clientes en forma eficiente de cara al cumplimiento de los planes y objetivos. A menudo, uno de los principales inconvenientes que enfrenta una QAF es la de asignar sus recursos a tareas que realmente agreguen valor o, dicho de otro modo, mantener a todo el equipo asignado a tareas
Estado de situación - Proyecto X
Análisis de requerimientos
Entregable e-test plan Diseño de caso
Ejecución 1 Ejecución 2
Testing 1 Testing 2
40
DE LA MANO DE Pragma Consultores EL BANCO CREDICOOP INCORPORÓ KANBAN A SUS PROCESOS DE GESTIÓN. REDUCCIÓN DE LOS TIEMPOS DE PLANIFICACIÓN DEL TESTING Y AUMENTO DE LA PRODUCTIVIDAD DEL EQUIPO SON ALGUNOS DE LOS LOGROS PRINCIPALES DE ESTA NUEVA ORGANIZACIÓN DEL TRABAJO. productivas. Es por ello que en general la planificación se realiza desde los recursos hacia las tareas y no al revés. Esta diferencia sutil pero fundamental es la que hace más atractivo el uso de Kanban en este tipo de contextos y menos restrictivo en sus procedimientos. El método Kanban se implementa mediante un tablero que se coloca en un lugar visible para todo el equipo. La pizarra se divide en columnas, una para cada etapa del proceso. Luego se define un número límite para cada columna (WPI): las tareas avanzan sólo cuando hay espacio disponible, por lo cual es más sencillo establecer prioridades. Diariamente se realiza una puesta en común, en la cual todos los integrantes conocen las tareas que el resto del equipo lleva a cabo, pueden opinar al respecto y hacer sugerencias. Es fácil visualizar en el tablero los tiempos ociosos y poder adelantarse a ellos, realizando una distribución anticipada de las tareas o informando, a quien corresponda, los problemas antes que sucedan. Los miembros del equipo tienen obligación de informar la finalización de sus tareas, la disponibilidad para tomar otras y también las interrupciones. El proceso de planificación (partición de tareas y estimación) se puede realizar utilizando las mismas técnicas que en Scrum. La actividad de testing en áreas de sistemas de grandes compañías se ha vuelto muy dinámica. Aplicar metodologías demasiado predictivas en estos contextos constituye una fórmula para el fracaso. Es por ello que la exploración de métodos alternativos de gestión, como Kanban, es un tema clave para garantizar servicios de control de calidad a la medida de las necesidades de la organización. Lo importante de Kanban, como de otras metodologías ágiles, es generar un mecanismo de control visual que ayude a hacer un seguimiento del trabajo. Agilidad y transparencia son sus principales virtudes; evitar los cuellos de botella, las superposiciones de tareas y los tiempos muertos, sus ventajas inmediatas. La gran pizarra blanca delineada por columnas y filas y tapizada de papelitos amarillos está viva, acompañando el desarrollo de las tareas de ese día.
Las 9 ventajas principales del uso de Kanban 1. Se concentra en limitar el WIP (work in progress), transformando el flujo de las pruebas en un sistema pull y no push (en función de lo que “podemos” –equipo disponible– y no de lo que “queremos” hacer). Esto evita mucho esfuerzo de planificación y priorización, que la propia dinámica de la tarea de testing vuelve obsoleto. 2. Permite representar el proceso de testing en el tablero, especificando las responsabilidades de cada área. Al tener todo en el tablero es posible visualizar y responder a primera vista dos preguntas fundamentales: ¿Qué tareas se encuentran interrumpidas y por qué motivos? ¿Todo el equipo está trabajando? 3. Tiene una rutina diaria (heredada de Scrum) de puesta en común de todo el equipo. A partir de esto todos los integrantes conocen las tareas que el resto del equipo realiza, pueden opinar al respecto y realizar sugerencias, como así también colaborar en caso de que alguien esté con tiempo ocioso (incluidos los clientes). 4. Favorece el intercambio de información (vía el tablero) y la interacción entre los diversos equipos de testing de un proyecto. Por otro lado, obliga en forma natural a que se cumplan todas las etapas del ciclo de vida de testing de software. 5. Distribuye las actividades de gestión y planificación dentro del equipo, aliviando al líder de la QAF (que se sabe que es el rol más crítico en esta clase de estructuras). 6. Favorece la autogestión del grupo, que va balanceando sus necesidades, sin olvidar que el objetivo primordial es cumplir con los tiempos y con la calidad de entrega del producto. 7. Incentiva la participación, colaboración y expresión igualitaria de todos los miembros del equipo (impactando positivamente en su motivación). En los equipos que siguen metodologías ágiles cada integrante es activo (da un paso adelante para buscar tareas y comenta lo que los demás hacen). 8. Propone técnicas de estimación para lidiar con tareas complejas (como ventanas móviles en lugar de sprints rígidos). Esto es especialmente útil a la hora de planificar testing debido a que muchas de las decisiones del equipo están fuera del ámbito de la QAF. 9. Propone una orientación hacia los resultados: al final del día siempre es posible medir el progreso real del equipo en términos de tareas realizadas.
El Banco Credicoop, entidad financiera coorporativa y con amplia trayectoria en el mercado financiero argentino, contrató a Pragma Consultores servicios relacionados con el armado de estrategia de pruebas, pruebas funcionales y técnicas acompañando la migración de su aplicación “core”. El Proyecto –llamado QA Crecer 21– que comenzó en 2007, continúa su ejecución al día de hoy. ¿Cómo comenzó el QA Crecer 21? El banco se encontraba frente al proyecto más importante de TI: la migración de sus sistemas a un único sistema core, implementado sobre un producto. En ese contexto necesitaba contar con un partner que lo ayudara a definir una estrategia de calidad para todo el proyecto y luego implementarla. Dicha implementación se haría en fases, requiriéndosele al partner adaptar su servicio a las necesidades de cada una de esas fases. En las etapas iniciales el objetivo era establecer qué se quería probar, setear expectativas respecto al nivel de calidad que la implementación debía lograr y ajustar las interacciones entre los equipos de distintos proveedores. Luego el servicio cambió hacia una modalidad QAF donde el dimensionamiento del equipo de trabajo se realizaría siguiendo la demanda de pruebas que el proyecto tenía. Es en este punto donde se decide introducir Kanban como forma de organización para el equipo de testing. ¿Cuáles fueron los logros principales? Los resultados obtenidos pueden resumirse en tres puntos. Primero, la reducción de los tiempos de planificación del testing en general. Esto permitió destinar tiempo del líder del equipo a otras actividades como ser la revisión de la estrategia o el análisis de la funcionalidad desde el punto de vista del negocio. El segundo logro fue la reducción en el nivel de reporting requerido, gracias a la visualización diaria del tablero por parte de los stakeholders. Y, por último, el aumento en la productividad del equipo de trabajo. En paralelo, se formó un equipo multidisciplinario que agrupó perfiles funcionales y técnicos, y que fue variando a lo largo del desarrollo hasta transformarse hoy en un servicio de testing para todos los desarrollos realizados en el marco de este proyecto.
41