domingo, 30 de noviembre de 2014

II Jornadas sobre Calidad del Producto Software & QA Open Space - Día 2 (2/2)

http://calidaddelproductosoftware.com/2014/


(Puedes encontrar la primera parte de este artículo aquí)

La cuarta charla, titulada "Evolución de un Modelo de Pruebas tradicional a un Modelo de Calidad Total", fue presentada por Alfonso R. López Rivero, de Vodafone. En ella se explicó como Vodafone ha transformado por completo su modelo de la calidad para grandes aplicaciones corporativas de la mano de MTP.

Las ponencias en las que una empresa explica su "caso de éxito" siempre me resultan muy interesantes. Alfonso comentó que Vodafone había apostado por la calidad por encima de time to market (aunque sin olvidarse de él por completo, claro).

Para implantar todos estos cambios, realizaron en primer lugar pruebas de concepto y agruparon dichos cambios en 2 grandes grupos:
  1. Cambios Organizacionales
  2. Cambios Culturales
En el primero se encuadran los cambios que implican un cambio en la estructura jerárquica y organizativa de los equipos:
  • RM - Release Management
  • C&DM - Configuration & Data Management
  • SQA - Software Quality Assurance
    • Ejecución de pruebas
    • Automatización de pruebas y tareas
    • Provisión de datos de prueba
    • Calidad de código: cuando hay tiempo, tratan de "limpiar" código legacy para mejorar su calidad.
    • Calidad de requisitos
    • Pruebas de rendimiento: utilizan una línea base de rendimiento para determinar si el rendimiento de un software es o no aceptable
    • Pruebas funcionales

Los cambios culturales son los más difíciles de llevar a cabo:
  1. En primer lugar hay que pensar si realmente se desea cambiar
  2. Posteriormente hay que planificar la ejecución de los cambios
  3. Superar las barreras que se vayan encontrando y
  4. Por último decidir cómo se medirá el éxito (el valor creado)

En este proceso de cambio se lograron mejoras aplicando acciones proactivas, pero también se aprendió mucho a partir de los errores cometidos.

Por último, Alfonso nos comentó algo que realmente me pareció una gran idea y es que cuando hacen un cambio importante de software, hay gente que se desplaza físicamente a las tiendas para obtener el feedback del cliente.


En la quinta ponencia, "Calidad del Software bajo el paradigma Agile", Carlos Ortega (Vector) expuso algunas conclusiones del estudio realizado por Rally SW sobre Agile:
  • Los equipos estables o dedicados tienen una productividad que duplica a la de los equipos que no lo son
  • Los equipos Full Scrum tienen una productividad del 250% respecto a la de los equipos que no son Full Scrum
  • Las prácticas ágiles reducen el time to market a la mitad
  • Los equipos más productivos son los que tienen un tamaño de 7±2 personas
  • La duración óptima de los ciclos es de 2 semanas
  • Para mejorar la productividad hay que tener un WIP (Work In Progress) reducido
  • Las restrospectivas son completamente necesarias
  • La calidad es un concepto que debe estar siempre presente en la mente de los desarrolladores

Carlos también mencionó SAFe (Scaled Agile Framework) como solución para aplicar Agile en grandes empresas y citó a las siguientes como ejemplo de Full Agile:
  • Philips
  • John Deere
  • TomTom
  • Travis Perkins

El sexto acto del día fue el Open Space "Open Source en calidad software" en el que se habló sobre todo de si las ventajas y desventajas de las aplicaciones Open Source frente a las propietarias. Se comentó que algunas empresas quieren el soporte y ayuda que se obtiene de las grandes empresas creadoras de software propietarios. Sin embargo, otras empresas se sienten más cómodas con software libre porque obtienen respuestas inmediatas de la comunidad. Además, pueden modificar libremente el código sin tener que esperar una nueva release de la aplicación que arregle un determinado "bug" o incorpore una determinada funcionalidad. Por ese motivo, no se puede decir que un tipo de software sea mejor o peor en términos generales sino que es necesario analizar el proyecto en el que se van a utilizar así como la empresa en la que se va a utilizar.

La siguiente ponencia, "Modelo de IQA en sus factoría de desarrollo", de José Alberto García Coria (INSA) comentó la experiencia de INSA trabajando como factoría de desarrollo y de testing. En unas jornadas en las que destacaron las ponencias dedicadas al agilismo y prácticas relacionadas, esta charla una rara avis. Y tengo que decir que la ponencia, me pareció muy interesante.

INSA tiene un modelo near shore con centros CENIT (Centros de Innovación Tecnológica) en diferentes ciudades de España.

INSA divide su trabajo en 3 grandes áreas:
  1. Aseguramiento de la Calidad: basada en CMMI, en el que se encuadran los procesos de validación y verificación,el Process Assurance (asegurar que se cumplen los procedimientos), etc.
  2. Servicios de Pruebas (ISTQB): pruebas unitarias, end to end, fncionales, regresión, etc.
  3. Servicios Especializados (IBM Rational): integración continua, pruebas de seguridad, usabilidad, rendimiento, etc.

Las tareas de desarrollo y las de testing están completamente desacopladas.

INSA se apoya mucho en el uso de herramientas de pruebas. Por ejemplo, para asegurar la calidad del software, se establecen una serie de controles sobre los entregables de entrada y salida. Este trabajo se realiza con la herramienta IBM Rational Team Concert. Las pruebas funcionales se realizan con IBM Rational Quality Manager, la integración continua con Hudson, las validaciones de código con SonarQube y las pruebas de seguridad con IBM Rational Security App Scan. Además, se utiliza un cuadro de mando (Business Intelligence) con la herramienta IBM Rational Insight.

A continuación, José Alberto comentó que cuentan con un portal de Gestión del Conocimiento. En este portal se puede encontrar snipplets (partes reutilizables de código), documentos, foros, wikis, etc. INSA identifica deficiencias de conocimientos en su plantilla y pone en marcha un plan de acción para mitigarlos.

Por último, José Alberto indicó que ellos entienden la Calidad del Software como la suma de:
  • Valor (Calidad Externa)
    • Funcionalidad
    • Seguridad
  • Calidad Interna
    • Integración Continua
    • Deuda técnica
    • Gestión del conocimiento
  • Restricciones (costes, tiempo, alcance)
    • Objetivos de calidad

La última actividad del día y de las jornadas fue un debate abierto en el que se respondían preguntas de los asistentes y de las personas que seguían las ponencias vía streaming.

Posteriormente, como cierre, se informó de que se ha abierto un blog con el que se puede colaborar, así como un grupo de Meet Up, para continuar realizando eventos de testing durante todo el año.

No hay comentarios:

Publicar un comentario

Compartir