Para inaugurar el blog, “Menos mal que aparecieron las metodologías Ágiles”…

Hola, mi nombre es Rodrigo Asenjo, tengo aproximadamente 8 años de experiencia en el campo de QA y actualmente me desempeño como Quality Assurance Specialist en el Centro de Excelencia Internacional de Investigación y Desarrollo de Telefónica Chile.

En lo personal, creo que tuve suerte con mi primer trabajo como QA, una empresa pequeña donde me contrataron por mis aptitudes profesionales en general, porque de QA no tenía idea, de hecho en esos años (2007 por ahí) recién se estaba hablando de QA en Chile, y mi primera labor fue estudiar mucho sobre toda la información disponible y formar una pequeña área de 3 personas (incluyéndome).

Luego de esos inicios fui saltando de empresa en empresa (como casi todo informático) desempeñándome como QA en varios lugares a lo largo de mi carrera, y a medida que pasaba el tiempo y miraba el mercado, me sorprendía como cada vez, alguien inventaba un nuevo cargo/perfil/nombre para la labor de QA, Analista QA, Téster, Ingeniero QA, Analista de Pruebas, Líder de pruebas, Líder QA, QA Automatizador, JP QA, etc., por nombrar algunos.

 A veces iba a algunas entrevistas donde buscaban un Analista QA y creo que en cada una de ellas las labores eran distintas, si multiplicaba eso por el resto de perfiles no había que ser un genio para darse cuenta que en cada empresa le estaban metiendo de su cosecha al tema QA.

No me molestaba que las empresas segmentaran las labores de QA en varios roles o perfiles, pero lo que sí me complicaba era que me estaba costando encontrar un trabajo que me guste, uno donde pudiera hacer todas las actividades que me permitan asegurar la calidad del software, ya que no soy de los que se siente cómodo solo haciendo una cosa, y era lo que pasaba en la mayoría de las empresas, por ejemplo, el Analista QA sólo analizaba requisitos y construía casos de prueba… boooooring, el Téster sólo ejecutaba casos de prueba que habían sido escritos por otra persona… booooring, el Líder QA dirigía al equipo sin meter las manos y había que pasar mucho tiempo en reuniones… booooooooring… y así con cada cargo.

Por otro lado, las áreas de QA de las empresas cada vez estaban más separadas de desarrollo, incluso en algunas partes (y no es broma) NO se nos permitía dirigirnos directamente a los developer, ¡ni siquiera por correo!, no sé cómo pero de un momento a otro resulta que QA era el enemigo de desarrollo, ahí me entré a preocupar, me di cuenta que no era el tipo de QA que yo quería hacer, muchos procesos, mucha burocracia, mucha documentación, poco trabajo en equipo, mucha desconfianza, etc. en resumen, para mi, era mucho ruido y pocas nueces.

La cosa iba así hasta que me topé con las metodologías ágiles, mi primer acercamiento fue leer el libro “Scrum & XP from the trenches”, me pareció interesante, pero pocas empresas estaban aplicando metodologías ágiles en ese entonces, por lo que decidí experimentar con cosas pequeñas como para ir entendiendo los beneficios, por ejemplo, utilizando un kanban, aunque en vez de historias de usuario eran tareas de QA, pero ya era algo, hasta que logré llegar a trabajar con Scrum en otras empresas, la verdad fue muy gratificante, y aunque en algunos lugares no se aplicaba de la mejor manera, se alejaba bastante de la figuras rígidas y estructuradas de las que venía, y en ese sentido, comencé a sentirme bien nuevamente en mi trabajo.

Una de las cosas que más valoro es el trabajo en equipo, y con las metodologías ágiles eso sí sucede, somos un equipo, distintas disciplinas juntas en busca de un objetivo en común,  nadie es más importante que el otro y tampoco hay jerarquía, todas las decisiones se toman en equipo, si ganamos, ganamos todos, si fallamos, fallamos todos.

Como el enfoque ágil se centra en entregar valor rápido, ¡es muy gratificante que tus labores estén centradas en hacer pruebas! y no a otras cosas innecesarias, pasé de dormirme en reuniones largas a tener reuniones diarias de 10 min. con el equipo, de documentar todo a sólo lo estrictamente necesario, de limitarme a hacer las pruebas a participar e inferir en el desarrollo del proyecto, y así suma y sigue, en general, un cambio que te hace valorarte y ser valorado por el equipo, al igual que cada especialista en su tema.

Actualmente trabajo con un equipo excelente utilizando Scrum, y recién en este último tiempo he encontrado el perfil que me gusta, el que desempeño actualmente, le llamo Qagile (otro nombre inventado),  que reúne varios skills que me he dado cuenta son necesarios para poder desempeñar este rol, pero el detalle de los skills de un Qagile no lo detallaré ahora, porque sería muy largo, por lo que ese tema lo dejo para un siguiente post.

¿Volvería a trabajar con metodologías rígidas?, no, de hecho es una de las primeras preguntas que hago cuando me llegan ofertas laborales, incluso por delante del dinero, es que creo que para allá va la cosa, y pienso que no estoy tan equivocado.

 

Leave a Comment