Una experiencia aplicando Kanban en Testing [Parte 1]

Hace unos días rearmamos el tablero Kanban de un proyecto de testing en el que estoy actualmente trabajando. La experiencia fue interesante ya que debíamos explicar el tablero y los conceptos principales de esta metodología a integrantes nuevos del equipo. Esto nos obligó a repasar, hacernos preguntas, definir nuevos criterios y generar discusiones en el grupo.

Proyecto

Servicio: Testing Funcional

Equipo: 3 personas (1 diseñador de casos y 2 ejecutores)

Objetivo: Agregar valor al producto manteniendo el equipo asignado a tareas productivas

Implementado Kanban

Hicimos una reunión con el equipo en la que discutimos los siguientes puntos (notar que algunos pueden ser muy generales y otros quizás más específicos del proyecto):

1. ¿Qué es Kanban?

Como definición general, es una técnica que se usa para gestionar el proceso de desarrollo de software de una manera eficiente. Kanban es una palabra japonesa que puede traducirse como tablero visual o sistema de tarjetas. 

2. ¿Cuáles son las reglas de la metodología?

- Visualizar el flujo de trabajo: dividir el trabajo en tareas/items/funcionalidades/necesidades, escribirlas en una tarjeta (post-it) y pegarlas en un tablero. Usar columnas etiquetadas con las etapas de nuestro proceso para indicar dónde, cada item, está en dicho proceso.

- Limitar el trabajo en progreso (WIP): asignar un límite explícito a cuántas asignaciones pueden estar en progreso en cada etapa del workflow.

- Medir el "lead time": (tiempo promedio para completar un item) optimizar el proceso para hacer el lead time tan pequeño y predecible como sea posible.

3. ¿Para qué armamos un tablero? ¿Qué información nos brinda?

El tablero es la foto del proyecto. Necesitamos visualizar su estado actual, tareas en curso, manejo de asignaciones, limitaciones, "cuellos de botella", problemas y mejoras para optimizar el proceso. Además queremos favorecer la autogestión del team, balancear necesidades e incentivar la participación, colaboración y expresión de todos sus miembros.

4. ¿Lo hacemos?

Las columnas etiquetadas con las etapas del proceso dependen del proyecto. En este caso, diseñamos el tablero de la siguiente manera:

- Backlog: lista de necesidades que deben ser testeadas, ordenadas por prioridad.

- En Definición: features en esta etapa están en definición de estrategia y diseño de casos de prueba.

- En Cola de Ejecución: los casos para la funcionalidad fueron definidos y están esperando la ejecución.

- En Ejecución: la ejecución de casos comenzó.

- Finalizado: la funcionalidad ya fue testeada (*)

5. ¿Cómo lo mejoramos?

- Fila EXPRESS: puede darse el caso de que nuevas funcionalidades tengan prioridad por sobre las planificadas inicialmente. Esto (a veces) implica dejar de trabajar sobre las que están en proceso y, por lo tanto, es necesario definir un segmento express por donde "circulen" estos items con mayor prioridad.

- Fila BLOQUEADOS: por aquí van las features que no pueden avanzar en nuestro proceso. Esto puede deberse a falta de documentación (bloqueado en definición de casos), funcionalidad no implementada (bloqueada esperando ejecución) o bugs invalidantes (bloqueado en ejecución). Además, este segmento funciona como segundo ciclo de pruebas con funcionalidades que pueden volver a priorizarse cuando son desbloqueadas.

Por último, luego de haber diseñado el tablero del proyecto, el equipo comenzó a discutir sobre cómo trabajar con el workflow definido, qué información debemos registrar para mantener trazabilidad, cómo medir, el work-in-progress y algunos criterios de aceptación (*). Todos estos puntos son motivo de la Parte 2 de esta experiencia.

Fuentes:

Foto: http://blog.crisp.se

1. http://www.kanbanblog.com/explained/
2. http://www.fuerzatres.com/2011/07/trabajar-sin-estres-kanban.html
3. http://www.fuerzatres.com/2011/03/kanban.html
4. http://www.xqa.com.ar/visualmanagement/tag/kanban/
5. "Kanban and Scrum: making the most of both" Henrik Kniberg y Mattias Skarin