T E C N O L O G A

Kanban
KANBAN ES UNA METODOLOGA GIL QUE PERMITE VISUALIZAR EL FLUJO DE TRABAJO, DIVIDIR TAREAS Y OPTIMIZAR EL TIEMPO DENTRO DE LA OFICINA. UNA EFECTIVA ESTRATEGIA PARA LA GESTIN DEL CAMBIO QUE TMIDAMENTE VA ABRINDOSE CAMINO EN EL UNIVERSO TI.

Aplicando

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 ocina. Distintas tareas llenan las y columnas junto a pequeos post-it amarillos que se van trasladando de forma dinmica. Detrs de esta aparente telaraa de anotaciones hay una metodologa 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 seales 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 ujo productivo. Una imagen que funciona como una perfecta metfora del trabajo en equipo. Cualquier problema o cuello de botella quedar en evidencia en la pizarra. El nombre Kanban surge de la combinacin de dos conceptos: kan (visual) y ban (tarjeta o tablero). Es un trmino japons acuado por Toyota hace varios aos. Ellos lo usaban para sealizar los productos parciales en la lnea de montaje fabril. Kanban se enmarca dentro de las llamadas metodologas giles que, como su nombre lo indica, buscan dar rapidez y practicidad a los procesos. Entre sus fundamentos establecidos en el ao 2001 en el Maniesto 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 dcada, estas metodologas 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 metodologas giles.

Kanban en la industria del software El mtodo Kanban fue inventado por Sakichi Toyoda en 1902 con el objetivo de mejorar el proceso de fabricacin textil que el Grupo Toyota tena en aquel momento (en lo que para algunos fue el nacimiento del concepto de automatizacin en la industria). Con el tiempo, el grupo fue evolucionando a la empresa que conocemos hoy y el mtodo 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 ms usada. Pero, segn explica Anderson, Kanban funciona mejor para ciertos procesos de mantenimiento de software, y por eso su amplia difusin actual en esta industria. Pero, ms all de su creciente popularidad, es difcil encontrar referencias al uso de Kanban dentro de la prctica de testing de software. Es un hecho llamativo ya que esta metodologa puede estructurar muy bien la actividad de un rea o equipo de testing. Henrik Kniberg, reconocido consultor en compaas de IT, subraya tres ejes claves de Kanban. El primero implica visualizar el proceso (workow) de trabajo, partiendo el trabajo en diferentes piezas. Tambin ayuda a limitar el trabajo en curso (work in progress) y, por ltimo, a optimizar el ujo de trabajo midiendo el lead time (el promedio de tiempo necesario para terminar una pieza). Estos tres puntos son ms que importantes a la hora de testear software en forma continua. De la teora a la prctica 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 organizacin (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 prot center). En algunas organizaciones se encuentra totalmente tercerizada a manos de un proveedor especializado, en otras est formada por recursos propios. Dentro de los desafos para gestionar una QAF hay dos que son los ms importantes. El primero tiene que ver con establecer un modelo de cobros dinmico 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 mltiples clientes a los que deber proveer diferentes servicios, con cronogramas

38

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 metodologas giles, y en particular Kanban, pueden ayudarnos. Utilizar un enfoque en cascada (o altamente estructurado) para este tipo de demanda cambiante resulta imprctico en el contexto dinmico que tienen hoy las reas de sistemas de las grandes organizaciones. En cambio, aplicar metodologas agiles como Scrum o Kanban para gestionar una QAF nos permite disponer de mecanismos para planicar y comunicar los planes altamente efectivos; denir cunto 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 ejecucin de nuestros planes; introducir cambios de prioridades o ajustar la planicacin y, adems, interactuar con los clientes en forma eciente 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

DE LA MANO DE Pragma Consultores EL BANCO CREDICOOP INCORPOR KANBAN A SUS PROCESOS DE GESTIN. REDUCCIN DE LOS TIEMPOS DE PLANIFICACIN DEL TESTING Y AUMENTO DE LA PRODUCTIVIDAD DEL EQUIPO SON ALGUNOS DE LOS LOGROS PRINCIPALES DE ESTA NUEVA ORGANIZACIN DEL TRABAJO.
productivas. Es por ello que en general la planicacin se realiza desde los recursos hacia las tareas y no al revs. Esta diferencia sutil pero fundamental es la que hace ms atractivo el uso de Kanban en este tipo de contextos y menos restrictivo en sus procedimientos. El mtodo 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 dene un nmero lmite para cada columna (WPI): las tareas avanzan slo cuando hay espacio disponible, por lo cual es ms sencillo establecer prioridades. Diariamente se realiza una puesta en comn, 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 fcil visualizar en el tablero los tiempos ociosos y poder adelantarse a ellos, realizando una distribucin anticipada de las tareas o informando, a quien corresponda, los problemas antes que sucedan. Los miembros del equipo tienen obligacin de informar la nalizacin de sus tareas, la disponibilidad para tomar otras y tambin las interrupciones. El proceso de planicacin (particin de tareas y estimacin) se puede realizar utilizando las mismas tcnicas que en Scrum. La actividad de testing en reas de sistemas de grandes compaas se ha vuelto muy dinmica. Aplicar metodologas demasiado predictivas en estos contextos constituye una frmula para el fracaso. Es por ello que la exploracin de mtodos alternativos de gestin, como Kanban, es un tema clave para garantizar servicios de control de calidad a la medida de las necesidades de la organizacin. Lo importante de Kanban, como de otras metodologas 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 las y tapizada de papelitos amarillos est viva, acompaando el desarrollo de las tareas de ese da. Las 9 ventajas principales del uso de Kanban 1. Se concentra en limitar el WIP (work in progress), transformando el ujo de las pruebas en un sistema pull y no push (en funcin de lo que podemos equipo disponible y no de lo que queremos hacer). Esto evita mucho esfuerzo de planicacin y priorizacin, que la propia dinmica de la tarea de testing vuelve obsoleto. 2. Permite representar el proceso de testing en el tablero, especicando 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 comn 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 tambin colaborar en caso de que alguien est con tiempo ocioso (incluidos los clientes). 4. Favorece el intercambio de informacin (va el tablero) y la interaccin 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 gestin y planicacin dentro del equipo, aliviando al lder de la QAF (que se sabe que es el rol ms crtico en esta clase de estructuras). 6. Favorece la autogestin 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 participacin, colaboracin y expresin igualitaria de todos los miembros del equipo (impactando positivamente en su motivacin). En los equipos que siguen metodologas giles cada integrante es activo (da un paso adelante para buscar tareas y comenta lo que los dems hacen). 8. Propone tcnicas de estimacin para lidiar con tareas complejas (como ventanas mviles en lugar de sprints rgidos). Esto es especialmente til a la hora de planicar testing debido a que muchas de las decisiones del equipo estn fuera del mbito de la QAF. 9. Propone una orientacin hacia los resultados: al nal del da siempre es posible medir el progreso real del equipo en trminos de tareas realizadas.
El Banco Credicoop, entidad nanciera coorporativa y con amplia trayectoria en el mercado nanciero argentino, contrat a Pragma Consultores servicios relacionados con el armado de estrategia de pruebas, pruebas funcionales y tcnicas acompaando la migracin de su aplicacin core. El Proyecto llamado QA Crecer 21 que comenz en 2007, contina su ejecucin al da de hoy. Cmo comenz el QA Crecer 21? El banco se encontraba frente al proyecto ms importante de TI: la migracin de sus sistemas a un nico sistema core, implementado sobre un producto. En ese contexto necesitaba contar con un partner que lo ayudara a denir una estrategia de calidad para todo el proyecto y luego implementarla. Dicha implementacin se hara en fases, requirindosele al partner adaptar su servicio a las necesidades de cada una de esas fases. En las etapas iniciales el objetivo era establecer qu se quera probar, setear expectativas respecto al nivel de calidad que la implementacin deba 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 realizara siguiendo la demanda de pruebas que el proyecto tena. Es en este punto donde se decide introducir Kanban como forma de organizacin para el equipo de testing. Cules fueron los logros principales? Los resultados obtenidos pueden resumirse en tres puntos. Primero, la reduccin de los tiempos de planicacin del testing en general. Esto permiti destinar tiempo del lder del equipo a otras actividades como ser la revisin de la estrategia o el anlisis de la funcionalidad desde el punto de vista del negocio. El segundo logro fue la reduccin en el nivel de reporting requerido, gracias a la visualizacin 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 perles funcionales y tcnicos, 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.

Estado de situacin - Proyecto X

Anlisis de requerimientos

Entregable e-test plan Diseo de caso

Ejecucin 1 Ejecucin 2

Testing 1 Testing 2

40

41