Agilidad vs Calidad

Marcos es responsable de proyecto de una consultora muy exitosa. Cuando leyó por primera vez sobre metodologías ágiles, le pareció estar soñando: había encontrado la forma de librarse de todo lo que hacía engorrosos sus desarrollos de software: la documentación, los procesos, la “gente de QA”…

Apoyándose en la moda que comenzaba a imponerse, no le costó mucho convencer a su nuevo cliente, ni tampoco a sus jefes, de las ventajas de utilizar una metodología ágil: entregas frecuentes, equipo reducido y un rol preponderante del cliente.

Cuando le preguntaron sobre el equipo, respondió que no necesitaría Testers, con la misma sonrisa de triunfo con la que mandó a la papelera de reciclaje los templates de documentos funcionales que había utilizado en los anteriores proyectos.

La primera etapa del proyecto pareció muy exitosa: Marcos se sentaba con el cliente a escribir las user stories, de ahí derivaba los UAT que servían como base para el desarrollo. A cada desarrollador le exigió que automatizara una batería de pruebas unitarias y después, uno de ellos, automatizó una regresión completa basándose en los UAT. Las primeras entregas no sólo llegaron a tiempo, sino que además, el cliente declaró al verlo que el software era “justo lo que necesitaba”.

Claro que hasta ese momento, nadie lo había utilizado. Tuvieron que pasar varias entregas para que el software llegara a algunos de los usuarios finales, y comenzaran a utilizarlo intensivamente. Ahí surgieron los problemas.

¿Qué pasó?

El software satisfacía al cliente (que no era el usuario final, sino un gerente de área; el producto era utilizado por la gente que estaba dos niveles más abajo), cumplía con lo que se le había requerido, pero en cuanto se lo sometía al uso cotidiano (lo que implica concurrencia de usuarios, alta carga de uso, errores de operación, etc.), las fallas eran tremendas, en cantidad y en gravedad.

Ante las quejas de su cliente, Marcos se movió rápido. Le aseguró que era conciente de los problemas que tenía el producto, y que por eso ya estaba contratando a un especialista en calidad, que ayudaría a resolver los numerosos defectos del software. Comprendió que había zafado, había salvado el proyecto, y que debía resignarse a volver a caer en manos de un “árbitro de la calidad”…, ya se lo imaginaba: retrasaría las entregas, pondría el grito en el cielo por la falta de documentación, perseguiría a todos exigiendo el agregado de un acento o el cambio de color de un botón…

En fin, se dijo Marcos, yo intenté ser ágil, pero si el cliente lo que quiere es que el proyecto se demore hasta el infinito, allá él.

Se sorprendió un poco cuando su jefe le presentó a Julio, un Tester con experiencia en proyectos ágiles. A Marcos le pareció un poco contradictorio: ¿no era que las metodologías ágiles prescindían de Analistas Funcionales y Testers?

Julio fue rápido para el diagnóstico del problema. Las cosas no se habían hecho del todo mal, simplemente, se había dejado de lado una parte importante. Se habían detallado bien los user stories, se habían automatizado bien las pruebas unitarias y las regresiones, pero el problema era que con eso no alcanza: eran necesarios más niveles de prueba, para exponer al producto a mayor exigencia.

Julio explicó que con la automatización de pruebas que el equipo de desarrollo había armado, se habían constituido en responsables de la calidad del producto, lo cual era más que acertado, ya que para las metodologías ágiles, la calidad es responsabilidad de todos los miembros del equipo.

El nuevo integrante del equipo ayudó a diseñar otros niveles de pruebas, que sacaron a la luz numerosos defectos, que el equipo de desarrollo fue corrigiendo. Así, cada iteración se componía de una parte de agregado de funcionalidad, y una parte importante de corrección de defectos. Cuatro o cinco versiones más adelante, el producto mostró una solidez mucho mayor, resistiendo el uso intensivo de los usuarios finales, y cambiando su imagen ante los ojos del cliente.

Una de las cosas que más sorprendió a Marcos fue que Julio ejecutaba pruebas todo el tiempo. Nunca se quedaba esperando a que le entregaran una funcionalidad completa, sino que estaba constantemente probando. De esa manera, logró detectar defectos muy tempranamente.

El producto siguió su evolución y el proyecto terminó siendo un rotundo éxito. El cliente obtuvo el producto que necesitaba, en tiempo y forma, con una alta percepción de calidad. Marcos estaba gratamente sorprendido y feliz con esta nueva experiencia. Pese a haberse equivocado en un comienzo, había tenido la flexibilidad para cambiar su enfoque y aprender de los errores cometidos. Y sobre todo, había cambiado radicalmente su forma de ver a los testers: no concebía un equipo sin que alguno de sus integrantes fuera un especialista en calidad.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s