Software Quality Maturity Model & Technical Debt

Software Quality Maturity Model & Technical DebtCreo que todos vosotros conocéis CMMI. Este modelo desarrollado por el Software Engineering Institute ofrece cinco niveles de madurez con el fin de medir la calidad de los servicios de TI y mejores prácticas asociadas con esta escala de niveles.

No voy a escribir un post entero sobre este modelo, ya que no es el objetivo de este artículo, sino que simplemente lo presentaré como yo pudiera resumirlo a alguien que no sabe nada acerca de la gestión de proyectos y del desarrollo de aplicaciones.

CMMI, los diferentes niveles

El modelo empieza en el nivel 1, donde no hay ningún proceso definido. Esto es lo que yo llamo “el nivel de los campeones” o, “the stuff of heroes”, “elegidos para la gloria”, ya que el éxito de un proyecto depende de la presencia de un campeón, como un experto de las tecnologías empleadas o un director de proyecto con experiencia . En resumen, al menos una persona, generalmente bien reconocida, siempre deseada y que va a terminar con más frecuencia asignada a proyectos prioritarios. El fracaso de otros proyectos no anima a la organización a mejorar.

El objetivo de nivel 2 (“Managed” en la terminología CMMI) es poner en marcha procesos que permitan precisamente superar a los campeones y garantizar el éxito del proyecto por cualquier equipo que los implementa. Esto es lo que yo llamo ‘repetir el éxito’, independientemente de los individuos.

Estos procesos se ajustan posteriormente (Nivel 3 “Defined”), es decir, se adaptan según el proyecto, con bucles de mejora para sacar provecho de cada experimento y mejorar. El nivel 4 (“Quantitatively Managed”) implementa métricas y mediciones estadísticas para controlar los procesos, y así sentar las bases del nivel 5 (“Optimized”) en el que la organización trabaja en un proceso de constante optimización.

CMMI, nivel cero

Siempre me ha sorprendido que el modelo se inicia en el nivel 1, ya que, de hecho, a este nivel, no hay nada, ningún proceso, es amateurismo perfecto. Pero me permitió definir lo que yo llamo el “CMMI nivel cero”, que conviene a algunas organizaciones que he conocido, cuando la cultura de la empresa promueve y apoya la aparición de campeones. En lugar de tratar de progresar a nivel 2, donde la “gente indispensable” no se necesita para el éxito de un proyecto, los managers más bien tienen una mala opinión de cualquier intento de creación de un pequeño proceso un poco organizado, y por ejemplo consideran una pérdida de tiempo cualquier documentación para replicar las tareas usuales del proyecto y asegurar su continuidad en la ausencia de “campeones”. Incluso ayudan a crear situaciones inextricables y extremadamente difícil de superar con el objetivo de demostrar que son del “stuff de los heroes”. Como “Vamos a cambiar todo a última hora y trabajar durante toda la noche para entregar mañana a toda prisa.”

En general, esos managers dividen el mundo entre los “winners” — grupo en que obviamente consideran que pertenecen y “loosers”, esos pobres infelices débiles y caprichosos que posiblemente pudieran, pero en general rehúsen, a trabajar en el caos permanente generado por una jerarquía elitista . Esos managers no quieren progresar hacia el nivel 2 sino por contrario evolucionaer hacia abajo: un nivel cero de la Calidad donde cualquier idea de mejora es sospechosa y fantasiosa.

Un modelo de madurez de la calidad del software

El modelo CMMI ha perdido popularidad desde que algunas empresas supuestamente certificadas en el nivel más alto han demostrado en realidad ser incapaces de ofrecer una calidad de servicio correcta. Pero tiene la ventaja para mí de ser lógico y fácilmente comprensible por todos, y en muchas áreas.

Así que imaginé el siguiente modelo que propongo para los clientes que quieren medir su nivel de madurez en la Calidad de software.

Qualilogy_Modelo_Madurez_Calidad_Software

En el primer nivel, no hay procesos o estructura de gestión de la calidad del software. Eso no quiere decir que no hay iniciativas, pero es sólo por unos campeones que deciden por sí mismos de instalar en su proyecto una herramienta de análisis de código, controlar versiones o hacer un seguimiento de los bugs y de Change Requests.

El nivel dos se caracteriza por una actitud reactiva a los problemas de calidad: la organización busca identificar defectos de software, el incumplimiento de las buenas prácticas de programación que puedan afectar a los usuarios y poner en peligro el negocio de la empresa, o causar retrasos en la entrega de aplicaciones y incrementar los costes de mantenimiento. En este nivel, la gestión de la calidad del software usualmente se confía a una estructura específica, que instala y gestiona de manera centralizada una plataforma de Calidad que consta con herramientas que pueden utilizar los proyectos, pero con procesos obligatorios y no siempre muy flexibles. Este equipo realiza a petición Quality Gates, por lo general para aprobar o rechazar la entrega de una nueva versión de aplicación por un proveedor externo, y a veces lleva a cabo auditorías a petición del management.

El nivel tres permite cambiar a una actitud proactiva en la que ya no se contenta simplemente de identificar y responder a defectos en la calidad del software, sino de prevenirlos, y tan pronto como sea posible en el ciclo de vida del proyecto. Esto requiere un proceso de Integración Continua y por lo general algunas prácticas Ágiles.

En el nivel cuatro, las métricas de calidad se utilizan para medir y controlar la calidad del software en todos los aspectos de la gestión de proyectos. Los outsourcers deben cumplir con los SLA (Service Level Agreement o Acuerdo de Nivel de Servicio) que se basan en estas métricas. Se hacen benchmarkings para comparar los proveedores y situarlos en un ranking muy apreciado por los servicios de Compras: “Señor, usted pasó de quinto a séptimo lugar este trimestre. Se necesita hacer algo. Espero de usted un esfuerzo“. Las organizaciones de TI utilizan medidas de calidad con el fin de elaborar un mapa de sus sistemas de información y definir una estrategia para cada bloque de aplicaciones.

En el nivel cinco, se anima a los proyectos para optimizar la gestión de la Calidad con la experimentación de nuevas prácticas, como revisiones de código por pares, el desarrollo basado en pruebas (Test Driven Development) o Extreme Programming (XP ). Los resultados en calidad de código se miden y se comparan para determinar cuáles de esas prácticas son más fructiferas en el corto, medio o largo plazo. Formaciones y talleres (workshops) se llevan a cabo para difundir las mejores prácticas y fomentar su adopción.

Madurez y Deuda Técnica

La medición de la Deuda Técinca puede utilizarse en todos los niveles del modelo. No en el nivel uno, claro, excepto por unos campeones que conocen la metáfora, pero esto sería iniciativas aisladas, y, además, no siempre entendidas por el management.

Las auditorías a nivel 2 pueden basarse en una evaluación de la deuda técnica, sobre todo cuando el management tiene preguntas en cuanto a la estrategia que escoger para una aplicación. He utilizado con frecuencia la evaluación de la Deuda Tëcnica durante assessments, en conjunto con ciertos criterios, como la criticidad de la aplicación y su alineación con el negocio. Por ejemplo, dentro de la misma empresa, encontrarémos nuevos mercados de alto crecimiento que dan lugar a nuevas aplicaciones en las que el time-to-market, la fiabilidad y el rendimiento son fundamental para diferenciarse de la competencia y ganar preciosas cuotas de mercado. En los mercados más antiguos, la estrategia se centrará en el mantenimiento de los márgenes, y por lo tanto el cumplimiento de los presupuestos de TI: entonces nuestra evaluación de la Deuda Técnica se alinea con la capacidad de mantenimiento de aplicaciones.

Siempre es importante alinear la Deuda Técnica con el negocio para responder a las preguntas formuladas por la dirección TI  y ofrecer diferentes estrategias y planes de acción: externalización de aplicaciones, transferir el conocimiento a un otro equipo interno (posiblemente compuesto de desarrolladores externos), refactorización, reingeniería (ver nuestra serie de posts sobre el tema). Para un assessment de la calidad de una aplicación, la evaluación de la Deuda Técnica representa un verdadero valor añadido para el cliente.

En el nivel 3, la Deuda Técnica se mide diariamente o al menos de manera frecuente por el equipo del proyecto, para evitar la inflación de la deuda y de sus intereses. La Deuda técnica se gestiona en cada iteración del proyecto y no específicamente al final (Quality Gate) u ocasionalmente (auditoría) como en el nivel 2.

En el nivel 4, la Deuda Técnica se mide de manera normalizada en todos los proyectos. Esto se traduce en los SLAs para los proveedores externos. Por ejemplo:

  • No nueva clase de alta complejidad / no clase de tipo ‘God class’ adicional.
  • 0 Blocker (KO de la Quality Gate).
  • 0 defecto crítico (OK si está corregidoen la próxima versión).
  • La cobertura de código por medio de pruebas unitarias no ha disminuido.
  • El nivel de documentación no ha bajado.

La normalización de las medidas de la Deuda Técnica y de los SLAs entre proveedores hace posible realizar los benchmarkings mencionados antes. Obviamente, podemos realizar estas mismas medidas con los equipos internos, y por lo tanto responder a esta pregunta universal de todos los CIOs: ¿por qué algunos equipos entregan sus proyectos a tiempo y en el presupuesto fijado, mientras que otros fracasan continuamente?

Las mismas medidas se pueden utilizar para construir un mapa de la Deuda Técnica a nivel del portafolio de aplicaciones (por negocios). Es posible construir diferentes tipos de representación con diferentes ejes, tales como:

  • Treemap con ejes Tamaño (Size) x Deuda Técnica.
  • Cuadrante con ejes Criticidad x Deuda Técnica.
  • Representación 3D en forma de ciudad con ejes Complejidad x Deuda Técnica.

Estas representaciones proporcionan una valiosa información para la toma de decisión, y créame, no hay nada más apreciable para una dirección TI que unos datos que permiten decidir una estrategia para las aplicaciones del portafolio. Creo que dedicaré un post específico al respecto, este ya es demasiado largo.

No hago mucha diferencia entre los niveles 4 y 5: en general, encontramos los mismos procesos, con la idea generalizada en el nivel 5, de experimentar con nuevos métodos que ayudan a contener o incluso reducir la Deuda Técnica, y la difusión de las prácticas exitosas a través de formaciones y talleres (workshop).

Usando el modelo

Que me perdonen los puristas de CMMI, pero comprenderán que estoy utilizando este modelo, no como un proceso de implementación de procesos o de certificación, sino como un modelo explicativo, lógico y fácil de entender. Además, considero que es posible mezclar los niveles, es decir, tener algunos equipos en el nivel 1 y otros de nivel 3, dentro de la misma organización.

Por ejemplo, a menudo me encuentro con empresas que se podrían considerar a nivel dos de este modelo, con la gestión de la Calidad bajo la responsabilidad de una estructura específica. Debido a que está centralizada, esta gestión de la Calidad no está siempre presente en todos los proyectos. Al mismo tiempo, he visto casos en que algunos equipos trabajan con sus propias herramientas y procesos, independientemente de esta estructura de Calidad, con la consecuencia que generalmente esa entidad se encuentra aislada, sino desempleada.

Otro beneficio de este modelo: promueve la participación de la jerarquía, cada vez más importante a medida que se suben los niveles. Puedes tener algunos equipos en el nivel 2 o 3, pero sin un enfoque apoyado por la dirección, seguirás siendo bloqueado en el nivel uno con unos pocos equipos de campeones.

Otro de los beneficios — y el punto final en conclusión de este post: el modelo muestra que la calidad viene de abajo y se extiende hacia arriba en la organización. Para alcanzar el nivel 4, donde las medidas de Calidad y de la Deuda Técnica se utilizan por los managers como elementos de decisiones estratégicas, necesitamos primero que estas medidas se llevan a cabo a nivel de proyecto o por los proveedores externos. Pero la Calidad no se decreta. Aunque la dirección sea voluntaria y impulse programas de gestión de Calidad, sin embargo, se necesita ganar el apoyo de los equipos, a menudo reacios a iniciativas que creen dirigidas a medir o controlar su productividad con reglas poco claras e incluso arbitrarias.

Aquí es donde la Deuda Técnica, porque es objetiva y medible, constituye una herramienta valiosa. La medición de la Deuda Técnica ahora se implementa en muchos proyectos, también gracias a las herramientas de análisis de código que la soportan. Los métodos Ágiles también cada vez más presente, promoven su adopción y uso. Dos ingredientes esenciales para el éxito de los proyectos y una receta ganadora para los managers TI.

Esta entrada está también disponible en Lire cet article en français y Read that post in english.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *