Hemos visto en los dos últimos posts una serie de casos de uso muy frecuentes que requieren un número limitado de métricas, entre 10 y 20 de ellas. Estos casos de uso son l0s siguientes:

• Validar la entrega de una aplicación (Quality Gate).
• Disponer de datos objetivos para los SLAs de los proveedores.
• Los procesos de Integración / Mejora continua de los equipos de desarrollo.

La pregunta en comentario del primer post es : ¿cuales son esas 10/20 métricas más importantes?

Veamos primero los casos de uso.

Quality Gate

Es un proceso de comprobación y validación de la calidad de la entrega de una aplicación.

¿Porque ese nombre de ‘Gate’?

Debido a que es una puerta entre dos fases que deja pasar o no el ‘output’ – es decir la entrega – de la fase anterior hasta la fase siguiente.

Encontraremos por lo general dos tipos de Quality Gate:

• Pre-QA: no sirve perder tiempo y esfuerzos (pues dinero) en pruebas cuando ya defectos se pueden identificar automáticamente con un análisis de código. Y si son demasiado numerosos, el código vuelve hacia el equipo de desarrollo para que los arreglen. Esta Quality Gate se encuentra a nivel de los equipos internos (de desarrollo o de QA) de un cliente o de un proveedor.
• Pre-producción, con el objetivo de comprobar si quedan errores. ¿Quieres que los usuarios encuentren esos fallos? Claro que no: sabes muy bien lo que eso puede costar para la imagen de TI.

¿Cuál de esa Quality Gate poner en marcha? Depende del contexto de desarrollo.
Si la aplicación está desarrollada internamente:

• Quality Gate pre-QA muy recomendable.
• Quality Gate pre-producción, para comprobar que las correcciones de defectos encontrados en QA no han producido nuevos defectos.

Si la aplicación es desarrollada por un proveedor (contexto Outsourcing):

• Quality Gate pre-producción mandatoria. Es recomendable que el proveedor tenga su propia Quality Gate.

Integración continua / Mejora continua

Es un proceso de análisis de código a nivel de desarrollo, para detectar defectos tan pronto como sea posible.
Idealmente, se necesita un equipamiento para automatizar este proceso y no añadir cargas de trabajo al equipo de proyecto:

• Una herramienta de gestión de versión para el seguimiento de los cambios de componentes y poder construir una nueva versión de la aplicación en cualquier momento.
• Una herramienta para lanzar automáticamente un ‘build’ (compilación) de la versión de la aplicación y un análisis de código. Hemos visto un ejemplo con Jenkins y Sonar: Sonar – Análisis con Jenkins.

Los beneficios de este proceso son múltiples:

• Integración continua: los defectos se corrigen lo más ante posible
• Mejora continua: la frecuente repetición de los análisis ayuda los equipos de proyecto a respetar las buenas prácticas de programación o de arquitectura.
• Es mucho más fácil realizar un Quality Gate exitosa.

El equipo de proyecto puede entregar o presentar al equipo de QA un informe con los resultados del último análisis. De nuevo, según el contexto:

• Desarrollo interno: el equipo de QA puede decidir pasar a la fase siguiente con solo revisar y aprobar ese informe.
• Desarrollo outsourcing: el equipo de QA revisa el informe proporcionado por el proveedor antes de poner en marcha un Quality Gate. Si se decide que se quedan demasiados defectos, mejor esperar una versión de mejor calidad y ajustar la planificación. Si se aprueba el informe, la QA realiza su propio análisis en su repositorio, para comprobar los resultados del informe.

Comprobar los SLAs de los proveedeores

Un Service Level Agreement (SLA) o Acuerdo de Nivel de Servicio es un contrato entre un proveedor de servicio y su cliente con objeto de fijar el nivel de calidad de dicho servicio.

El problema más habitual es de disponer de datos objetivos y irrefutables para medir el nivel de calidad. Es cuando una herramienta de análisis de código es muy útil.
Aquí, el contexto es únicamente de Outsourcing. Bueno, se puede también tener SLA a nivel de equipos internos pero eso se encuentra en organizaciones bastante grandes con muchos equipos de proyecto que trabajan como proveedores internos. O los directivos quieren monitorizar el rendimiento y la calidad de sus equipos internos pero en este caso, no se trata solamente de calidad de software pero también de otros datos como costes, time to market, etc.

Un SLA se puede comprobar con cada entrega de una versión de aplicación, con los resultados del Quality Gate. El cliente puede escoger entre 3 posibilidades, normalmente definidas en el acuerdo:

• OK: aceptación de la entrega, cuando todos los objetivos de calidad han sido cumplidos.
• OK con reservas: aceptación de la entrega, pero unos objetivos no han sido cumplidos y el proveedor tendrá que entregar una nueva versión con correcciones. Esto ocurre bastante a menudo, para evitar retraso en la puesta en producción de la aplicación, pero normalmente si los defectos que quedan no son muy graves o no impactan tanto al usuario (lo veremos a nivel de métricas).
• KO: quedan demasiados defectos en la nueva versión, la entrega es rechazada.

Este proceso de SLAs es muy aconsejable cuando un cliente tiene diferentes proveedores, porque se puede realizar una evaluación comparativa (benchmarking) de proveedores, con la consecuencia de crear una emulación (para no decir una competición) entre ellos. Sabes, para poder decir algo como “Eres el último en el ranking de este trimestre”. Eso explica también que no es muy fácil imponerlo cuando hay un único proveedor: en este caso, el cliente no tiene mucho peso.

Es recomendable tener estos tres procesos en marcha para lograr una mejor sinergia y maximizar los beneficios pero de nuevo, depende del contexto:

• Desarrollo interno: integración continua muy recomendable, Quality Gate más fácil y no se necesitan SLAs (pero los datos de calidad pueden entregarse en un dashboard de pilotage de los equipos internos especialmente en TI de grande tamaño).
• Outsourcing: Quality Gate esencial y SLAs muy muy recomendables (para no decir mandatorios). Mejor que el proveedor ponga en marcha un proceso de Integración continua a nivel de sus equipos, para facilitarse la vida con el cliente y no fracasar en sus Quality Gate y SLAs.

El principal beneficio de una herramienta de análisis de código proviene de las métricas de calidad que pueden objetivamente facilitar la relación con el proveedor.

Y como esos procesos trabajan juntos, vamos a encontrar métricas parecidas. En el próximo post.

Esta entrada está disponible también en Lire cet article en français.