11 razones por las que el testing y kanban se llevan bien
La aplicación de métodos ágiles, en particular Scrum, a la actividad de desarrollo de software es un tópico hot desde hace tiempo. También se ha escrito bastante sobre el uso de SCRUM en la actividad de testing. Sin embargo, poco se ha hablado del uso de Kanban como forma de organizar la actividad de los equipos de testing.
En este post me propongo dar algunas razones y consejos relacionados con la aplicación de Kanban a la dinámica de pruebas de un área o un equipo de testing.
Mis razones
Respecto del proceso..
- #1 Es posible organizar el trabajo en proceso (WIP) de testing en términos de la capacidad operativa del equipo. La limitación del WIP permite transformar 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 El proceso canónico de testing funcional es fácilmente representable en un tablero (a), permitiendo agrupar el trabajo en estados entendibles por los stakeholders de la prueba (b). De esta forma todos ven la misma película ahorrándose una cantidad importante de tiempo de planificación.
- #3 Gracias a la flexibilidad del método, es posible poner como etapas del proceso a aquellos hitos requeridos por el proceso de desarrollo. Por ejemplo, si todas nuestras pruebas deben tener un informe final, podemos poner un estado que nos obligue a generarlo.
Respecto de la planificación y reporting..
- #4 El líder puede planificar y priorizar diariamente sobre el tablero, dejando a disposición de todos y, en un único lugar, el trabajo pendiente. Esto aumenta la visibilidad de la situación y disminuye la necesidad de reporting.
- #5 Los miembros del equipo pueden ver el trabajo pendiente y autoasignarse nuevas tareas, en la medida a medida que va terminando con lo que hace (c). Esto minimiza los tiempos de gestión del líder drásticamente.
- #6 En entornos donde el bloqueo de tareas es moneda corriente, permite aprovechar los tiempos muertos de una actividad en otra o de focalizar a todo el equipo en la resolución del cuello de botella (d).
- #7 El líder puede darse cuenta rápidamente si se está quedando sin trabajo para el equipo (viendo el backlog) y agregar tareas.
- #8 Es posible medir y optimizar el tiempo de ciclo (desde que la tarea entra al backlog hasta que se termina) volviendo más objetiva y simple la tarea de planificación.
Respecto de los miembros del equipo..
- #9 Fomenta el trabajo en equipo y la interacción, para resolver cuellos de botella, sobrecarga y tiempo ocioso de personas, etc. Al exponer la situación, el método fomenta naturalmente la colaboración entre todo el equipo, no dependiendo totalmente de las directivas del líder.
- #10 Incentiva la mejora continua, ya sea para mejorar la técnica (por ejemplo en reuniones de retrospectiva) o para proponer tareas que no están incorporadas en el backlog. La técnica misma fuerza la participación, haciendo que todos los integrantes tengan la misma oportunidad de mostrarse y opinar.
- #11 Aumenta el compromiso con la tarea finalizada puesto que cada uno es responsable de pasar a finalizadas las tareas (e).
Algunos Consejos
- a) Un proceso canónico de testing podría ser: Backlog, Planificando, Definiendo Casos, Ejecutando Pruebas, Siguiendo Incidentes, Cerrado, Archivado, Bloqueados.
- b) Diferenciar claramente a los stakeholders de la prueba: usuarios, equipo de desarrollo y equipo de testing
- c) Tener tareas de 1 o 2 días de duración, no más.
- d) Tener un estado bloqueado para esas tareas o tener un color especial para agregarle a la tarea cuando vuelve al backlog.
- e) Tener un criterio consensuado para dar por finalizada una tarea. Esto es muy importante dado que todos los miembros del equipo deberían verificar que se está cumpliendo con el criterio de finalizado antes de indicar que la tarea está terminada en el tablero.
Seguimos pensando..
PD: Quiero agradecer especialmente a Damián Famiglietti, Nora Saidman y Thomas Wallet por su colaboración y aportes en este post.
Algo que me gusta de Scrum, aún para las tareas de test, es que los fines de sprint fuerzan un corte obligatorio. Este corte es a veces lo que se necesita para atacar las tareas que se están completando asintóticamente (ya sea por desidia o por dificultad) y moralmente funciona como un "reset" de la monotonía que hace limpiar los vicios y volver a enfocarse en lo importante. Creo que es un beneficio doble, desde el punto de vista de la priorización y desde el sentimiento individual de "terminé algo y ahora empiezo con otra cosa".
ResponderBorrar¿Cómo sugerís con esta metodología de pulling lograr que las tareas no se alarguen cada vez más como chicle? Tareas de 1 o 2 días es una forma de controlar la percepción de atrasarse (personal y grupal), pero ¿cómo se ayuda al grupo cuando es el grupo el que no se da cuenta que se está achanchando? ¿Les vas mostrando la evolución de sus métricas respecto al trabajo hecho? Y por otro lado, ¿cómo hacés para cortar con la monotonía rutinaria y dar "sensación de cierre"?
Ojo, me gusta la idea, pero me cuesta ver cómo se superan estas dificultades generadas por la rutina y la continuidad. Por otro lado si se te ocurre una forma de hacer esto, me gusta, porque Scrum tiene como desventaja que las mismas reuniones de fin de sprint son hasta cierto punto "desperdicio" (entendido como tiempo en que se podría estar produciendo en lugar de planificando).
Rula,
ResponderBorrarGracias por el comentario. Dicho esto, paso a contestar..
Lo primero que hay que decir es que usar prácticas de Kanban no invalida usar otras de Scrum. Es posible combinar prácticas de ambos efectivamente.
El “efecto chicle” que mencionas se contrarresta por la existencia de un product owner (o cliente en nuestro caso) que funciona como “control por oposición” respecto de las estimaciones de tiempo y tareas para hacer un determinado test (o proyecto). El comentario de 1 o 2 días viene a cuento de las cosas que hay que hacer dentro de un test. Si una tarea de 2 días, de un determinado test, se demora más que eso hay un problema y debe resolverse. Ahí se para la línea de producción y se sale a resolverlo. Típico ejemplo: error invalidante. Si no se puede resolver se pone como "bloqueado". Justamente al tener fijo el WIP esto es fácil de ver (en nuestro caso WIP = “cantidad de personas en el equipo”).
El “efecto reset” se implementa incluyendo tareas no relacionadas con tests. Por ejemplo “inducir a Pepe en el módulo XXX” podría ser una tarea a incluir. Trabajar sin sprint planning no significa no hacer tareas de infraestructura.
En cuanto a la sensación de cierre, usamos una etapa en el pipeline llamada “informe final” que obliga al equipo a escribirlo y por el otro lado funciona como “corte” para un determinado test (o proyecto).
En cuanto al tema del “desperdicio”, una cosa que aprendimos por las malas es que se necesita cierto “colchón” para garantizarnos una cierta cuota de innovación. No se puede estar todo el tiempo al 99% de tiempo productivo. Conocer qué porcentaje es razonable para el equipo es todo un tema.
Espero haber aclarado..
Slds,