El rol del QA tester en Scrum y el patrón rey-sirviente


En Scrum se entrega software funcionando en cada sprint. Si se puede, incluso antes, de forma continua. Un reto común Scrum es cómo integrar el rol del QA tester (incluido en el rol Dev Team de Scrum) en un equipo de desarrollo formado principalmente por desarrolladores.

El anti-patrón mini-waterfall

Lo fácil es caer en el anti-patrón de mini-waterfall. Empiezas el sprint haciendo un poco de análisis, diseño, después se desarrolla y al final del sprint se prueba. Cada sprint es un mini proyecto en cascada. Esto suele provocar que el QA tester está aburrido los primeros días del sprint y crispado los últimos. La aberración puede ser mayor si decides hacer el testing en sprints posteriores, o crear sprints de testing y de desarrollo, sacar el testing del Definition of Done, etc.

Esta trampa provoca múltiples desventajas. La principal es que el equipo está descoordinado. Cada uno empieza a trabajar en una cosa distinta. Hay cosas que se quedan paradas porque requieren diseños complejos, o requieren que 2 especialistas colaboren. Desde que se empieza algo hasta que se termina pasa mucho tiempo. La descoordinación también puede hacer que haya retrabajo, lo que aumenta aún más el tiempo para que las cosas se terminen. Ante la descoordinación se busca un coordinador, un jefe de proyecto o similar, que se preocupa de que las historias no queden paradas, avancen y se terminen.

Y ahora la pregunta clave, ¿cuál es la alternativa?¿cómo hacer para entregar valor de forma continua sin estos ciclos tan largos y con un equipo con más foco?

El principal reto, y el más difícil de conseguir es el cambio de mentalidad. Y para mí hay 2 aspectos importantes para reflexionar y plantear un cambio:

  1. Controlar el trabajo en curso
  2. Los miembros del equipo son T-Shaped

Controlar el trabajo en curso

El primer reto es dejar de trabajar en un montón de cosas a la vez. No tiene ningún sentido tener más historias en curso que miembros hay en el equipo. Parece algo obvio, pero pasa que las historias se bloquean, y las razones pueden ser millones: estoy esperando la revisión de código de un compañero, me faltan los textos o imágenes, estoy esperando la respuesta del proveedor, el entorno está roto, hay una dependencia que no habíamos identificado que tiene que hacer otro equipo, necesitamos un nuevo certificado, y así podría estar un buen rato. También está la intuición de que es más eficiente trabajar solo en una historia que tener que coordinarse con más gente para trabajar todos en la misma.

Para tomar conciencia de este problema y para combatirlo, algo que me ha ayudado es explicar y proponer al equipo que utilice el patrón del rey-sirviente de Henrik Kniberg. En resumen éstas son las reglas:

  • Cualquiera que esté trabajando en la historia de más prioridad es rey
  • El resto del equipo son sirvientes
  • Los sirvientes deben buscar maneras de ayudar al rey
  • Un sirviente no puede interrumpir al rey
  • Solo el rey puede hacer commit en la rama de desarrollo
  • Cuando la historia se termina, todo el que esté trabajando en la siguiente historia es ahora rey

Esto que aplica inicialmente a cómo organizarse en el control de código fuente, también se puede aplicar al nivel de cómo nos organizamos en el equipo para trabajar. Si la historia de más prioridad está ya codificada y en testing, el QA tester se convierte en el rey. La prioridad del resto del equipo es ayudar como sea a que la historia esté lo antes posible en Done. Y es posible que eso implique hacer cosas diferentes a las que hemos estado haciendo hasta ahora.

Los miembros del equipo son T-Shaped

Lo que nos lleva al segundo cambio de mentalidad, que es entender que en Scrum los roles no son estáticos en el equipo. No es que los programadores (solo) programan y los testers después prueban. El QA tester no es alguien que recibe unos requisitos escritos y se espera a que el desarrollador termine para hacer su magia negra y reportar defectos.

Hay muchas cosas que un QA tester puede y debe hacer durante todo el ciclo de vida del desarrollo. Voy a darte varios ejemplos concretos de esta colaboración siguiendo un ciclo de Scrum típico:

  • Antes del refinamiento el QA tester se lee las historias y contribuye en definir los criterios de aceptación (AC). También anota diversas consideraciones a la hora de probar la historia.
  • En esa sesión de refinamiento el QA tester hace preguntas como uno más.
  • Junto con el desarrollador añade diversas subtareas de pruebas manuales, retocar el test de regresión, etc. Ayuda al desarrollador a plantear las pruebas de integración necesarias.
  • Los primeros días del sprint comienza a automatizar pruebas end to end de algunas historias. También escribe los casos de test manuales que sabe que va a necesitar.
  • A medida que el sprint avanza algunas historias comienzan a estar listas para revisar. En las revisiones de código el QA tester participa y da feedback sobre las pruebas automáticas implementadas.
  • Si hay demasiadas pruebas automáticas por hacer, el QA tester pide ayuda al equipo para que le ayuden con el desarrollo de éstas. Esto a la vez hace que refinen los AC y casos de test.
  • Cuando las primeras historias están desarrolladas y listas para probar, se vale de los casos de test y tests automáticos que ha ido trabajando hasta el momento para hacer las pruebas.
  • En base al resultado de estas pruebas trabaja con el desarrollador codo con codo para trazar posibles soluciones. Si hay algún defecto le ayuda a reproducirlo e identificarlo y entre los dos discuten un plan para arreglarlo. Quizás sea necesario crear nuevas historias o defectos que se han descubierto y no tienen que ver con lo desarrollado.
  • En los últimos días del sprint es posible que hayan demasiadas historias acumuladas pendientes de probar. El QA tester pide ayuda activamente al equipo y colaboran en un plan para que entre todos se pueda completar todo al final del sprint. Se puede plantear por ejemplo hacer cross testing, los que no han participado en la historia X la prueban con la ayuda de las pruebas automáticas, los casos de test, los AC…

Resumiendo…

Se puede resumir todo en que el desarrollo de software es un trabajo colaborativo entre todo el equipo. Pero esto tan simple de explicar es difícil de llevar a la práctica. Este tipo de cambios requiere un gran esfuerzo, pues se trata de cambiar hábitos y nuestra forma de pensar.

Sin embargo, el esfuerzo merece la pena. Los beneficios conocidos son una mejor colaboración, más calidad, una velocidad más constante, menos cambios de contexto y entregar antes en el tiempo. Todos felices 😃

 

También te puede interesar...

Sprint Planning GTD para los objetivos del 2015 En la metodología ágil de desarrollo de software Scrum existe una ceremonia llamada Sprint Planning, en la que los miembros del equipo Scrum eligen me...
Tablero Kanban (Kanban Board) Kanban es una metodología que nos ayuda a mejorar los flujos de trabajo en cualquier proceso productivo, incluido el desarrollo de software. Se compon...
La mal llamada “Velocidad del Equipo” En las metodologías ágiles se utiliza una medida para calcular el ritmo en el que el equipo es capaz de ir avanzando en las tareas, mal llamada veloci...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *