Divide, ¿y testearás?
No todas las experiencias que llevamos adelante salen bien. Pero una filosofía que tenemos en redbee es la de equivocarse rápido para aprender y corregir. Y que, a veces, no todas las ideas puestas en marcha, salen como esperamos.
En esta ocasión les voy a contar una experiencia que atravesamos en el equipo cuando nuestro tester estaba por irse de vacaciones. Actualmente, es uno de los pocos que hace las pruebas manuales (estamos apuntando a automatizar todo) y, encima, estábamos en un situación agitada y en vísperas de un nuevo release. Era un momento complejo y no podíamos quedarnos sin tests.
Con él tres semanas afuera no podíamos parar el proceso, entonces decidimos dividirnos sus tareas. Al fin y al cabo, ya funcionábamos todos los días como un equipo autogestionado que podía solucionar sus propios problemas. ¿Qué podía malir sal?
Empezamos a planificar cómo llevar adelante estas tres semanas. Antes de que parta, Mati (nuestro querido tester) nos compartió una detallada lista de sus tareas diarias y lo que debíamos llevar adelante los siete del equipo.
Paso siguiente, empezamos a organizarnos para cubrirlas y le dimos forma entre todos. Parecía posible: agrupamos las tareas, las acciones únicas y empezamos a indagar cada uno de los puntos, su frecuencia y el tiempo que llevaba cada apartado. ¿La primeraconclusión? Era viable. Ahí empezamos a desglosar cada uno de estos puntos en acciones tangibles y a asignar responsables.
Los devs se ocupan de las tareas cotidianas y de hacer pruebas cruzadas antes de deployar para tratar de que lleguen menos bugs a test; UX sumaba algunas tareas más y el scrummaster del resto. Divididas las tareas, nos comprometimos a hacer nuestro trabajo de la forma más minuciosa posible para evitar errores a la hora de probar.
Pero nada salió como lo planeamos.
En el medio hubo mil problemas: los tests no salieron tan bien como esperábamos, no nos daban los tiempos y sentimos que no pudimos cumplir con los estándares que nos entregaba el tester profesional. A todo esto, Alex, el UX del equipo, se cargó gran parte del trabajo al hombro y tiró de la carreta para completar todas las tareas.
Inclusive, el día final del sprint nos dimos cuenta que teníamos todo en la columna de test, por lo que nos tuvimos que abocar todos a probar lo que se había desarrollado, obviamente teniendo en cuenta de no probar lo codeado por uno mismo. Pero en este punto pudimos organizarnos un poco mejor (no todo estuvo tan mal :P).
Concluidas estas tres semanas de correr y probar cosas, puedo decir que fue una experiencia caótica porque no estábamos preparados para este tipo de organización autogestiva completa.
En cierto punto, creo que fue una experiencia positiva porque los objetivos se cumplieron, el producto salió sin problemas aunque sentimos que no pudimos mantener la misma calidad que nos podía entregar la experiencia de Mati, además de su organización y resolución de los problemas.
En la balanza, creo que el resultado y el aprendizaje fue positivo, especialmente porque si hay una próxima vez de algo similar, la situación ya nos agarrará con más herramientas en mano y mejor parados. Sin embargo, no lo recomendaría como una práctica cotidiana a menos que haya una situación crítica como la nuestra.
Obviamente, esto no se puede aplicar a todos los roles, pero estas son algunas de las cuestiones que rescato de esta experiencia:
- Preguntarse, primero que nada, ¿qué rol hay que cubrir?, ¿quiénes están disponibles para distribuirse las tareas?, ¿hay barreras técnicas?, ¿son tareas que puede hacer cualquiera?
- Desglosar las tareas, identificarlas y analizar cómo se van a resolver
- No poner las expectativas muy altas si es la primera vez que el equipo intenta algo así. Hay que poner metas realistas.
- Hacer un chequeo constante de las tareas y no esperar a último momento.
- Por último, nadie tiene que intentar hacerse el héroe: en este tipo de experiencias lo que menos se necesita es un mártir. Para eso hay que trabajar con la distribución equitativa de tareas.
Espero que esta experiencia (con sus vaivenes positivos y negativos) y el aprendizaje les sirva para chocarse con la menor cantidad de paredes posibles, lograr crear experiencias de distribución de cargas mejores, cometer nuevos errores de los que podamos aprender y mejorar la dinámica de los equipos autogestionados.
