Calidad en desarrollo de software ágil (2da charla)

Presenté por segunda vez "Calidad en desarrollo de software ágil", en el IEEE, el jueves 24 de abril.
La charla fue básicamente la misma que la vez anterior (en esa entrada hay más datos de la presentación), salvo algunas correcciones menores en la segunda parte de la presentación.
En esta entrada quiero comentar algunas conversaciones que tuvimos con los asistentes.
Testers y líderes de QA/Testing
En ninguna de las charlas asistieron personas que tengan o hayan tenido como rol principal el de Tester o Líder de Testing/QA (excepto yo :).
¿Por qué vienen desarrolladores y project leaders y no vienen testers y líderes de QA/Testing?

• ¿No les llegó la convocatoria?, no creo, la convocatoria del IEEE es amplia, y sé que a algunos les llegó.
• ¿Adversión a la palabra ágil entre los Testers/QA? Es una posibilidad. Una de los metodologías ágiles con más exposición pública se llama Extreme Programming, no Extreme Development, ni Extreme Testing ... una primera impresión diría que los temas de testing son de segunda clase. Por supuesto, no es así. Por algo Ron Jeffries y Ward Cunningham son activos participantes en agile-testing
• ¿Testing visto con menor aura que QA? A pesar del título, que indica calidad, y no Testing, la descripción de la charla claramente refiere a temas de Testing. Todos sabemos que la prueba no la crea la calidad. Lamentablemente, creo que este conocimiento se ha deformado en considerar a Testing como una etapa transitoria e inicial en cualquier plan de carrera. Me inicio como tester, pero intento rápidamente "avanzar" a desarrollador o Analista, o responsable de procesos. Esto es en parte consecuencia de la poca importancia que se da a la calidad de software en nuestro mercado y a la forma en que se prueba: principalmente prueba manual, siguiendo script hechos por los "Analistas de QA". Hay poca prueba automática, y esta es hecha por los "Automatizadores".
• Ligado a los dos temas anteriores, lo "profesional" para personas involucradas en calidad de software es procesos (ISO / CMMI). Esto es contrario a los principios del manifiesto ágil, pero parece ser la percepción generalizada. Por ejemplo, el INTI a puesto en marcha la carrera de especializacion "Calidad Industrial de Software", en el que el testing (V&V) tiene 5% de la carga horaria, con 21 hs. Quizás me equivoco, ya que en el tema correspondiente a "Modelos de madurez y capacidad" (tiene el 19% de la carga horaria) se nombran "CMMi y metodologías ‘ágiles’" ... pero en qué contexto, no :)?

Varias personas de empresas con equipos trabajando en froma ágil me comentaron la dificultad de conseguir personas que aporten los skill de testing y calidad, pero que se sientan cómodos trabajando en un ámbito con alta automatización de las pruebas, sin separación organizacional de roles, y focalizados a la mejora práctica (no de libro) de los procesos.
Otras empresas han optado por contratar estudiantes de carreras no técnicas (sociales, económicas) no por la necesidad de sus skills particulares, sino porque son recursos más baratos para una prueba manual, que sólo requiere algún conocimiento de uso de computadoras, ser ordenado y tener un nivel aceptable de comunicación interpersonal.

Problemas en la implementación de métodos ágiles
Como comenté anteriormente, la calidad es central a las metodologías ágiles, sin embargo las personas de Testing/QA no son generalmente agentes de cambio.
¿Por qué?

• Separación de roles: después de pelear por años para que las organizaciones "den peso" a la Calidad, muchas de las personas en estas áreas ven con reluctancia ceder estas posiciones. En una estructura jerárquica, con muchos niveles, el nivel en el que aparece una función es una indicacón de la importancia que le da la organización. Sin embargo, en una organización horizontal, los niveles son pocos, y los equipos incluyen personas de todos los skill. La gran mayoría de las decisiones se toman por acuerdos dentro del equipo, por lo tanto, la necesidad de separar los roles de testing en una rama jerárquica separada al resto de desarrollo se hace innecesario e improductivo.
• Luego de un cambio hacia una organización horizontal, hay menos "jefes", por lo que los mandos medios se sienten amenazados (¿cómo manejar esto?).
• Por supuesto, los dos puntos indicados arriba se aplican no sólo a las personas con roles de Testing/QA. También pasa con los programadores, que no quieren "probar" o tener contacto con usuarios, y los líderes de programadores, que sienten la misma amenaza que los líderes de testing. Pero esta charla no era para programadores y líderes de programación :)

Estas dudas tienen respuesta, y esa fue la intensión de la charla, pero ... no vinieron los principales involucrados.

Conclusiones

Veo en el mercado argentino un problema con respecto a la implementación calidad de software en general y en el caso de metodologías ágiles en particular. No es visto como un rol dinámico que debe profesionalizarse y mantenerse actualizado, que debe guiar las mejoras desde el día a día, que debe retener a los recursos valiosos y que aporta valor al desarrollo de productos de software.
Esto no significa que los testers deben ser programadores, pero sí significa que deben entender y participar en temas de análisis, diseño y programación, así como los perfiles más técnicos deben participar en temas de prueba.

En mi particular cruzada, estoy trabajando con gente de la Facultad de Ingeniería de la UBA para crear cursos con fuerte foco práctico, que permitan desarrollar algunas de los skills comentados aquí. Apuntamos a tenerlos en marcha a partir de Julio. Los mantengo al tanto.