Trabajar de manera ágil es una cuestión de confianza más que de proceso y para todos los que estamos en la industria del software sabemos la importancia de hacerse de un equipo que trabaje desde el compromiso y las buenas prácticas de desarrollo, con una cultura de respeto y empoderamiento.
En alguna conferencia a la que asistí escuché que “La cultura se come a la estrategia en el desayuno” y nada más apropiado para graficar que por mucho que se intente implementar los principios de un marco de trabajo, no se llegará a feliz término dentro de un proyecto si no existe un cambio de mentalidad y se hace el esfuerzo necesario para entender los principios de la agilidad. Y uso la palabra principios en lugar de reglas, porque eso es lo que son, un conjunto de lineamientos que pueden guiar a ese cambio de mentalidad.
La agilidad tiene 4 pilares básicos desde donde funciona, estos pilares son: Individuos e interacciones sobre procesos y herramientas, Software funcionando sobre documentación extensiva, Colaboración con el cliente sobre negociación contractual, Respuesta ante el cambio sobre seguir un plan. Queriendo decir que los primeros se priorizan sobre los segundos, pero sin que estos dejen de existir. ¿Entonces? como Ingeniero de Pruebas, debes entender que tu rol debe ajustarse al proceso ágil y proveer soluciones que resulten en una respuesta de valor para el cliente.
Pero como podemos lograr esto sin morir en el intento, pues existen tres factores que quiero que tomes en cuenta cuando comiences a pensar en tu estrategia de pruebas y tu participación dentro del equipo
Piensa siempre en la calidad:
Para abrir este articulo quiero mencionarte que existen muchos equipos se centran mayormente en la entrega temprana más que en el proceso de calidad. En otros artículos he mencionado la importancia de centrarse en prevenir errores mas que en encontrarlos y nuevamente quiero afianzar la importancia de esto.
Establecer un proceso de desarrollo donde existan pruebas unitarias y de integración por parte de los desarrolladores, permitirá un acceso más inmediato a retroalimentación sobre los posibles errores que pudiera presentar la aplicación, adicionalmente las pruebas son más rápidas de desarrollar, se pueden hacer una mayor cantidad y se ejecutan con mayor rapidez, por lo cual terminan ofreciendo más rápidamente un estado de la aplicación.
Actualmente los equipos hacen uso de muy buenas practicas de desarrollo como la entrega continua que permite la construcción de un software más maduro y con menor presencia de errores, pero esto solo es posible cuando la calidad está en primer lugar y todos los miembros del equipo están comprometidos y adueñados de la calidad de su producto.
Asegúrate de que todos entiendan de la misma manera el “Definition of Done” (DoD):
La definición de hecho puede variar dependiendo del equipo, pero dentro de los miembros de un mismo equipo, todos deben entenderlo de la misma manera.
Por ejemplo, para algunos equipos existen una lista que van chequeando una vez completadas cada tarea, y cuando todas esas condiciones se cumplen, entonces se considera que una tarea está hecha.
Entonces, para algunos equipos, dentro de la definición de hecho se incluyen las pruebas del equipo de calidad, como para otros no.
Pero para esos equipos que dentro de su definición no se incluye al equipo de calidad, de seguro existen una definición de cuando una tarea esta lista para ir al área de calidad. Así que asegúrate de entender estas definiciones y de tomar el turno al bate, cuando así se requiera.
No uses tus reportes de errores para medir el rendimiento del desarrollador:
Puedes estar tentado a señalar de alguna forma a los miembros del equipo, si alguno de ellos ha estado tomando con ligereza la creación de su código, e incluso de las pruebas unitarias. Cuando estamos dentro de un equipo, si tomamos nuestros reportes para evidenciar la reincidencia de errores en el código creado por un desarrollador, o incluso si comenzamos a demostrar la cantidad de errores que llegamos a encontrar en el código de alguien en especial lo que podemos ocasionar es un resentimiento e incluso podemos predisponer a un compañero y atentar contra nuestro trabajo y nuestros reportes. Desmeritando el valor que estos pudieran tener para el equipo. Objetando que reportamos muchas cosas, que los pasos son difíciles de reproducir o que los usuarios nunca tomarán esos caminos.
Recuerda que estamos haciendo un trabajo de equipo y no estamos en una pelea de poder. En la agilidad todos compartimos roles y podemos estar al tanto sobre las obligaciones que otros sombreros tienen.
Así que recuerda que tus reportes son para dar valor sobre el estado de la aplicación y permiten al cliente poder revisar las pruebas y la frecuencia con las que probamos el sistema, teniendo la certeza que el software que liberamos se le ha aplicado una estrategia con un número importante de pruebas para encontrar la mayor cantidad de errores y para finalmente liberar un producto con menor cantidad de errores.
Los reportes son una herramienta de información para cada uno de los miembros del equipo y no un documento para medir rendimiento del equipo o de cualquier integrante de él.
Y tú ¿qué opinas del trabajo de calidad dentro de un equipo ágil?
Déjame tus impresiones en los comentarios y recuerda compartir este articulo con alguien del mundo de la calidad si crees que puede ser útil.
También puedes acceder a mi curso de automatización con Selenium que continúo construyendo y mejorando AQUÍ