¿Qué lecciones podemos aprender si se aplica al campo de la calidad del código los principios de ITIL para la Gestión de la Capacidad?

Vimos en el post anterior que, para proporcionar la Calidad de acuerdo con los SLAs, la planificación y los presupuestos, necesitamos saber lo que tenemos, es decir, conocer el portafolio de aplicaciones y también la calidad de esas mismas.

Este conocimiento basado en los indicadores cuantitativos y cualitativos permite satisfacer mejor las necesidades de los usuarios y del negocio, como veremos en este segundo y último articulo de esta serie.

Responder a las necesidades del negocio

Hacer más, mejor y más rápido con menos es el reto principal de los equipos de proyecto actualmente. El management está constantemente tratando de ajustar los recursos a nivel de actividad del proyecto, especialmente en los proveedores, y no es raro ver a uno o más desarrolladores pasar a otro equipo al final de un proyecto. El conocimiento del código se pierde, y con ello la fiabilidad en la predicción de las cargas y de los costes de realización de una nueva versión.

Incluso cuando las especificaciones funcionales son precisas, la carga exacta puede variar de simple a doble o incluso más, dependiendo del tamaño del código, su complejidad, su legibilidad, la dificultad con la que introducir cambios sin fallo.

Conocer la aplicación y su estado de un punto de vista cuantitativo y cualitativo permite entonces establecer una estrategia. Por ejemplo:

• ¿Hay cambios en esta área que presenta riesgos para la mantenibilidad? Si realmente debemos tocar cualquier de estos componentes, entonces mejor planear una QA exhaustiva para cada uno de ellos y evitar regresión.
• Se necesita una refactorización previa en esta parte de la aplicación porque hay demasiado código duplicado que nos va a costar un gran esfuerzo para implementar los cambios solicitados. Es mejor volver a re-escribir algunos de esos componentes en lugar de perder tiempo para identificar todos los trozos de código copiado y pegado donde introducir los cambios. Este refactoring también disminuirá las cargas de prueba y el riesgo de error.
• Esta aplicación no está bien documentada, con una muy baja tasa de comentarios, y hay demasiados nuevos desarrolladores en el equipo. Mejor proporcionar unos días extra de descubrimiento del código, incluso redocumentación al comienzo del proyecto. Esto puede evitar sorpresas desagradables más adelante, y tal vez podrémos recuperar el tiempo perdido, sobre todo en caso de cambio funcional durante el proyecto.

No es posible definir un plan de acción, un nivel de recursos y un calendario sin saber lo que tenemos y la calidad de lo que tenemos.

Optimizar la decisión

Otra lección que podemos establecer desde una analogía con la Gestión de la Capacidad y me parece particularmente interesante: la posibilidad de orientar una solicitud de los usuarios basandonos en datos objetivos.

ITIL precisa que la gestión de la infraestructura debe hacerse:

• En cumplimiento de los acuerdos de nivel de servicio, que son más a menudo una cuestión de disponibilidad de recursos.
• De manera rentable: una disponibilidad de 100% no es el objetivo porque sería demasiado costoso.

Un ejemplo. En un departamento de marketing, los usuarios de un software de CRM (Customer Relationship Management) se quejan de las demoras y de los retrasos durante la temporada navideña, cuando más se utiliza, y que los SLAs no se respetan. Piden una actualización del servidor en el entorno producción, y que se mantengan sus compromisos, sin costo alguno para ellos.

El Capacity Manager luego se reúne con ellos y les explica que la potencia disponible en el servidor es de 8 000 MIPS, es insuficiente para una disponibilidad óptima en las últimas dos semanas del año, pero sólo 6 000 MIPS se utilizan durante los once meces y medio restante. A lo largo del año, los acuerdos de nivel de servicio se cumplen.

Con este conocimiento, se puede proponer varias soluciones:

• Actualizar el servidor de acuerdo con los usuarios, pero con un coste correspondiente a los recursos adicionales.
• Proporcionar 50 semanas al año la potencia de 6 000 MIPS, o un poco más con el fin de mantener un margen de seguridad, y subir a 9 000 MIPS en las 2 semanas restantes. La factura será menor, incluso con el coste adicional de la intervención para añadir los MIPS que faltan y manejar esta flexibilidad adicional.
• Una otra solución posible: rebajar el servidor para entregar 6 000 MIPS durante todo el año, a coste de la degradación de los recursos aún mayores durante la temporada navideña. Esta solución podría considerarse en caso de restricciones presupuestarias y / o si se reducen las acciones de marketing.

Cuando se trata de desarrollo de aplicaciones, se asume que la calidad es necesariamente máximal, mientras que las prioridades son por lo general los plazos y los presupuestos que siempre se deben cumplir. Ahora sabemos bien que rápido y barato no rima con calidad. Especialmente que el planning más a menudo se decide en el comienzo del proyecto, mientras que las especificaciones aún no están fijadas y las cargas de trabajo a menudo fluctúan, siempre en aumento.

Si esto ocurre en tu proyecto y esperas retrasos, utiliza una herramienta de análisis de código dentro de un proceso de Integración Continua lo que permite, como el Capacity Manager:

• Demostrar con medidas cualitativas (número de violaciones bloquantes, criticas, etc.) que la deuda técnica es controlada y el nivel de calidad del código se mantiene.
• Justificar el tiempo adicional necesitado para implementar las nuevas funcionalidades con el aumenta de la complejidad de desarrollo y de pruebas (en estos temas, ver Complejidad y esfuerzo de QA et La métrica ABC).
• Proponer soluciones.

Estas pueden ser múltiples:

• Posponer la fecha de entrega con el fin de mantener el nivel de calidad esperado, guardar el control de la deuda técnica y realizar un plan de pruebas completo.
• Mantener los plazos inciales pero aceptando un riesgo para la calidad y bugs potenciales para los usuarios. Probablemente se necesitará un refactoring ulteriormente.
• Entregar una primera versión de la aplicación sin tener todas las características que se esperan, pero respectando el calendario y con una calidad aceptable sin riesgos excesivos para los usuarios. Una segunda versión completará las funcionalidades en un segundo tiempo, y permitirá corregir los errores de la primera versión.

« Más con menos » no significa producir más código con menos recursos como a menudo veo que lo piensan muchos usuarios o clientes. Esto significa ser capaz de responder adecuadamente a las solicitudes de usuarios siempre más exigentes, en términos de funcionalidad, plazos y presupuestos.

Establecer un proceso de Integración Continua con una herramienta de análisis de código, una Quality Gate en QA o antes de implementar en Producción, y SLAs (ver Casos de uso – Encajar a la perfección) y podrás disponer de datos objetivos que te permitirán ofrecer estrategias alternativas para tus clientes y tus managers, sobre la base del conocimiento y el control óptimo de tus aplicaciones.

Como lo demuestran los principios ITIL de la Gestión de la Capacidad, para satisfacer las necesidades de los usuarios y facilitar la decisión de los directivos se requiere datos objetivos y conocimientos cuantitativos y cualitativos de las aplicaciones.

Más y mejor con menos: entrega la calidad a tiempo y dentro de los presupuestos.