domingo, 30 de noviembre de 2014

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

http://calidaddelproductosoftware.com/2014/


Los días 26 y 27 de noviembre se han celebrado las II Jornadas sobre Calidad del Producto Software & QA Open Space. Como el año pasado, este evento ha estado organizado por El Corte Inglés, la Universidad Rey Juan Carlos, la Universidad Carlos III y la UNED.

En esta ocasión, las jornadas se han celebrado en el Campus de Móstoles de la Universidad Rey Juan Carlos.

Si las primeras jornadas estuvieron centradas en el "QUÉ", éstas segundas han estado centradas en el "CÓMO". Otra de las novedades han sido los Open Space: los asistentes dejaban notas en un tablón con las ideas, preguntas o sugerencias relacionadas con el tema del Open Space. Posteriormente, los organizadores, a partir de esas notas planteaban 3 líneas argumentales diferentes y los asistentes podían unirse libremente a cualquiera de ellas. De esta forma se crearon debates abiertos y colaborativos en los que cualquiera podía expresar sus opiniones. Los 3 debates finalizaron con la exposición de las principales conclusiones alcanzadas en los debates.



Lamentablemente, sólo pude asistir al segundo día del evento. Tenía muchas ganas de asistir a algunas charlas del primer día pero por imprevistos en mi trabajo, no pudo ser.

La primera charla del segundo día fue "¿Y qué pinta la Integración Continua en un sitio como éste?", presentada por Ana María del Carmen García y Mariano Minoli, de 233gradosdeTI.

Los ponentes explicaron las 6 razones para utilizar integración continua son:

  1. Reducir riesgos y tiempos:
    Con la integración continua se introducen cambios pequeños y frecuentes en el código. Con el sistema tradicional de entrega de software tradicional se realizan grandes modificaciones cada muchos meses o incluso años.
    Una frase de Martin Fowler resume esta idea:
    "Si algo duele, hazlo más a menudo"
  2. Reducir procesos repetitivos manuales: los procesos manuales son propensos a errores.
  3. Crear una versión de software mediante un proceso conocido, confiable, probado, versionado y repetible
  4. Mejorar la visibilidad del estado del proyecto
  5. Lograr una mayor auto-confianza y seguridad en el equipo de desarrollo
  6. Obtener feedback rápido de los usuarios


Los ponentes también explicaron el camino a recorrer hasta la entrega continua de software:
  1. Fase de pre-requisitos:
    • Tener sólo un IDE
    • Tareas acotadas
    • Control de versiones
  2. Fase de Compilación Continua
    • Automatización de builds
    • Compilación continua
    • Tener un servidor de Integración Continua
  3. Fase de Integración Continua
    • Inspección de código
    • Automatización de Pruebas
  4. Fase de Entrega Continua
    • DevOps
    • Automatización de la versión

La entrega continua se diferencia de la integración continua en que la entrega continua implica el despliegue de software en producción mientras que en la integración continua el paquete generado podría dejarse por ejemplo, en el entorno de prueba.

Con la entrega continua, es el departamento comercial el que decide en qué momento se pasa el software a producción; es decir, se les proporciona lo que se conoce como "release button".

La segunda ponencia, "Ciclo de vida de aplicaciones y Modelo de Control de la Caliad del Producto. Innovación y operación de procesos de negocio en un nuevo nivel: calidad, simplicidad y eficiencia para obtener ventaja competitiva" corrió a cargo de Bernham Luecke de SAP. Bernham comenzó hablando de la importancia de la innovación para garantizar la supervivencia de las empresas. Indicó que actualmente, el 72% de los recursos de las empresas se dedica a actividades relacionadas con mantener la continuidad del negocio y sólo el 28% a la innovación. El objetivo es conseguir "mantener las luces encendidas"; es decir garantizar la continuidad del negocio  con mucho menos esfuerzo (mejorando los procesos de negocio y reduciendo los costes de operación), para poder destinar más recursos a la innovación.

Posteriormente, explicó que la solución propuesta por SAP es el Control Center Approach. Además, explicó la importancia de acompañar al cliente desde el principio en todo el proceso de implantación para asegurar la operación.

A continuación tuvo lugar un Open Space con DevOps como tema central. Los asistentes nos dividimos en tres grupos para debatir sobre:
  • ¿Qué es DevOps?
  • ¿Cómo implantar DevOps?
  • ¿Puede aplicarse DevOps en todo tipo de empresas?

Yo me uní al primer grupo porque mis conocimientos de DevOps son muy limitados. Las conclusiones más importantes que se extrajeron de DevOps fueron:
  • DevOps supone un cambio de mentalidad
  • Para aplicar DevOps se requiere un equipo multidisciplinar
  • Es muy importante tener scripts automatizados para las tareas más comunes y repetitivas
  • DevOps tiene su propio ciclo de vida (en el que se incluyen las pruebas)
  • Para implantar DevOps es necesario involucrar a todos los interesados para vencer las resistencias al cambio

No hay comentarios:

Publicar un comentario

Compartir