Hemos presentado la semana pasada los ejes principales de la Gestión de la Capacidad de acuerdo con ITIL.

Si tratamos de aplicar estas mejores prácticas en el ámbito de la Calidad, ¿cuáles son las lecciones que se pueden aprender? ¿Cuál sería la gestión de la Calidad vista como una analogía de la gestión de Capacidad? ¿Es posible hacer « más con menos » en desarrollo como los equipos de Producción deben hacer cada vez más?

El objetivo principal de la Gestión de Capacidad es entregar la capacidad, es decir, los recursos que se necesitan: un servidor de desarrollo o de QA, un disco duro más importante para una base de datos, más CPU en una máquina virtual, etc.

ITIL añade que la capacidad debe ser garantizada de acuerdo con los objetivos de nivel de servicio, a tiempo y de una manera rentable.

Si aplicamos estos principios al mundo del desarrollo, podríamos decir que la gestión de la Calidad es entregar aplicaciones de calidad, de conformidad con los acuerdos de nivel de servicio, los plazos y presupuestos. ¿Cómo conseguir esto?

Saber lo que tenemos

Para proporcionar la capacidad, se necesita saber lo que tenemos. Este es el primer paso y la base de un plan de capacidad. No puedes gestionar lo que no conoces.

La virtualización se ha traducido en la creación de silos de tecnología y la ‘Prod’ debe ser capaz de medir el número de servidores físicos o virtuales para cada plataforma de virtualización, cada OS, etc. Es lo mismo para los portafolios de aplicaciones, que han visto una acumulación de varias tecnologías con el tiempo : mainframe, cliente-servidor, nuevas tecnologías (J2EE en su mayoría).

Además, durante su historia, una empresa va a evolucionar en diferentes mercados, crear nuevos negocios, a veces adquirir otras empresas, que multiplicarán las aplicaciones en soporte del negocio. La reorganización actual del sector bancario en España es la causa de fusiones y adquisiciones entre bancos, y cada vez surge la pregunta: ¿qué aplicaciones usar (o abandonar)? Puede parecer sorprendente, pero los departamentos de TI de algunos de esos bancos ni siquiera saben cuántas aplicaciones tienen y mucho menos qué tecnologías se utilizan o los enlaces entre ellas (cuando tirar una aplicación a la basura, mejor saber si está utilizada por un otro sistema).

Finalmente, los hombres van y vienen, cambian de trabajo o dejan la empresa y el conocimiento de la aplicación se pierde gradualmente con estos movimientos. Un responsable de desarrollo de una administración me hablo de una reunión entre sus directores y los más altos asesores del ministerio, para implementar una reciente decisión de Bruselas requierendo un cambio de normativa aduanera por cientos y miles de millones de euros. Pero nadie podía decir los impactos de estos cambios en el sistema que se encargaba de recoger ese dinerito. Tuvieron que invitar en la reunión un programador Cobol para preguntarle si era posible llevar a cabo estos cambios, qué otra parte del sistema informatico tocar también y en cuanto tiempo. Este responsable me dijo que esa reunión no sería posible hoy en día, y cuando le pregunté por qué, me contestó que el viejo programador Cobol se había jubilado y el conocimiento de estas aplicaciones se perdió con él.

Cuántas veces un cliente que quería una auditoría de una aplicación no sabía cuántos programas, cuantos ficheros ella contiene? Y no estamos hablando de líneas de código.

El primer paso de un plan de gestión de la Calidad se basa en un análisis del portafolio de aplicaciones. Una herramienta de análisis de código proporcionará datos cuantitativos sobre el tamaño de las aplicaciones, el número de objetos, su complejidad, el nivel de documentación (comentarios) o de código duplicado, por ejemplo.

Determinar el nivel de calidad de lo que tenemos

un análisis también proporcionará medidas cualitativas sobre los riesgos en diferentes aplicaciones. Estos riesgos son de dos tipos:

• Riesgos para el usuario: bugs, errores, defectos que impiden u obstaculizan el funcionamiento correcto de la aplicación, problemas de rendimiento y tiempos de respuesta altos, problemas de seguridad o corrupción de datos, etc.
• Riesgos para el mantenimiento de la aplicación: algunos defectos de calidad no dan lugar a un riesgo de error para el usuario, pero pesan sobre el mantenimiento de la aplicación, con consecuencias de retrasos en los plazos y sobrecostos.

Es importante conocer el nivel de ‘no-calidad’ y su naturaleza, en cada aplicación, para que sepas …

Responder a las solicitudes de los usuarios

« Más con menos » significa una repuesta mejor y más rapida a las peticiones de los usuarios, sin aumentar el nivel de recursos disponibles para satisfacerlas. El conocimiento adquirido a través de una herramienta de análisis de código permite calcular mejor el esfuerzo requerido para implementar los cambios exigidos por la actividad y los negocios.

Veo a menudo los usuarios quejarse de los retrasos en los equipos de proyecto y la falta de fiabilidad del planning previsto. A menudo, estos equipos están experimentando un alto turnover, especialmente cuando se subcontrata a un proveedor que está tratando de ajustar mejor la rotación de personal con la actividad de los diversos proyectos y de pasar desarrolladores de un equipo a otro en función de las necesidades.

Por lo tanto, cómo cuantificar la carga de un cambio en un código que no conocemos?

Este será el tema del siguiente post.