Los estándares automatizables de OMG/CISQ para la medida del Software (parte 4 - Medición de la Eficiencia y Agilidad del proceso ADM)

Este cuarto artículo de la serie dedicada a los estándares de OMG/CISQ para la medida del software, describe las medidas relativas al tamaño de éste, que pueden utilizarse para medir la eficiencia del proceso ADM. Ya escribí un artículo hace algún tiempo relativo a estas medidas, donde hacía un planteamiento general, describiendo sus características y cómo utilizarlas. Ver Medida y mejora de la productividad del desarrollo; recomiendo su lectura previa para una visión general de estos dos estándares.

En este artículo voy a centrarme en el uso de una de estas medidas de tamaño, Automated Enhancement Points (AEP, en adelante), para medir, de forma objetiva, la eficiencia y velocity de equipos de desarrollo Agile.

Los AEP miden el tamaño de los cambios funcionales y técnicos realizados en una aplicación entre dos versiones de ella. La aplicación puede ser multicapa y multitecnología. Este estándar se definió de forma que esta medida pudiera obtenerse automáticamente analizando el código fuente de la aplicación junto con la estructura de la base de datos utilizada.

Un problema que nos transmiten directivos de TI es la dificultad que encuentran para objetivar el rendimiento de equipos Agile. La medida de productividad basada en Story Points es simple y efectiva cuando se refiere al contexto de un único equipo Agile, pero cuando hay varios equipos (que pueden ser de distinto tamaño) trabajando en paralelo sobre la misma aplicación o producto, es muy difícil determinar cuál ha sido la eficiencia total.

Este es un tema importante para las organizaciones en lo que se refiere al riesgo relacionado con la no obtención de suficiente valor por lo que se paga cuando el desarrollo se externaliza. Hasta el año 2000 lo habitual eran los contratos de outsourcing Time&Material y ese riesgo lo tenía el cliente, ya que el proveedor recibía su compensación en base al número total de horas trabajadas, independientemente del resultado entregado. A partir del año 2000 comenzó la adopción de contratos a Precio Fijo y ese riesgo se trasladó al proveedor. En los últimos tiempos, con la adopción de metodologías Agile, los contratos relacionados (normalmente T&M) vuelven a dejar el riesgo en el lado del cliente.

Los Story Points se basan en una evaluación personal que realizan los miembros de un equipo Agile acerca del tamaño, complejidad y el nivel de incertidumbre de realizar una historia considerando el contexto tecnológico, sus habilidades, conocimientos y experiencia. Es, por tanto, una medida subjetiva del equipo y no tiene por qué coincidir con la de otros equipos Agile.

La propuesta que hacemos desde CAST Software, es complementar el uso de Story Points con la medida de AEP, que es la forma más efectiva de medir el output del desarrollo de aplicaciones, ya que es objetiva y mide el tamaño de los cambios realizados en cada sprint de forma consistente y no dependiente del equipo Agile.

Esta medida de AEP:

• mide componentes funcionales y técnicos
• facilita la medición de la eficiencia del desarrollo al capturar componentes creados y modificados en aplicaciones programadas en diferentes lenguajes

Vamos a ilustrar con un esquema su uso en el ciclo de desarrollo Agile:

Comentarios:

• La aplicación se analiza de forma automática después de cada sprint para obtener los AEP
• El cálculo de AEP por FTE y release se basa en un equipo de 10 miembros a tiempo completo
• El número de AEP medido para la release puede no coincidir con la suma de los AEP de cada uno de los tres sprints (y así se ve en el ejemplo). Esto es así porque es posible que en un sprint se hayan eliminado cambios de un sprint anterior. Si mides después de cada sprint, sí que tienes el detalle; si mides después de cada release, el valor se refiere al tamaño de los cambios realizados respecto a la release anterior.
• Dependiendo de quién vaya a consumir estas medidas, la frecuencia de medición puede ser una u otra o ambas. Cuando es el equipo de desarrollo, las medidas de interés serán el número de AEP por sprint y la media y mediana de AEP del conjunto de sprints medidos. Cuando se trate de perfiles de gestión, las medidas de interés serían el número de AEP por release y el número de AEP por FTE y release.

Resumiendo, el uso de AEP, debido a sus características, permitirá un análisis comparativo objetivo entre los distintos equipos Agile. Además, complementando estas medidas de tamaños con las otras medidas de CISQ relativas a la salud o calidad técnica del software entregado, se dispone de un completo conjunto de medidas dirigidas a facilitar y hacer más eficiente la medida del rendimiento del proceso de desarrollo ágil de aplicaciones.