Un objetivo común en Sistemas es poder determinar la productividad de varias técnicas, herramientas y personas como parte del esfuerzo total para mejorar dicha productividad. Si podemos medir la productividad de manera simple, vamos a poder identificar lo que está funcionando bien en determinadas situaciones, o lo que no está funcionando, y realizar los ajustes necesarios.
¿Cómo medir la productividad en los equipos ágiles? Aunque se pueden usar estrategias tradicionales como contar los puntos de función (FP), u otras estrategias similares, en la práctica todo esto requiere de mucho esfuerzo. Recordemos que no sólo queremos medir la productividad, sino que también lo queremos hacer de forma simple. Idealmente estaría bueno si la productividad pudiera medirse usando información que ya está siendo generada por el equipo, sin tener que agregar ningún otro proceso burocrático adicional.
La velocidad del equipo
Una métrica común que capturan los equipos ágiles es su velocidad. La velocidad es una medida ágil de cuánto trabajo el equipo puede hacer en una iteración. Al principio de la iteración el equipo estima el trabajo que está por hacer en términos de puntos. Al comenzar el proyecto el equipo formula un sistema de puntos (suele tomar algunas iteraciones para que se estabilice) de manera que pueda estimar de forma consistente el trabajo de cada iteración.
Aunque el sistema de puntos es arbitrario, mi equipo podría determinar que un elemento de trabajo vale dos puntos de esfuerzo, mientras que tu equipo podría pensar que vale siete puntos de esfuerzo; lo importante es ser consistente. De manera que si hay otro elemento de trabajo de esfuerzo similar, mi equipo lo estimaría en dos puntos, y tu equipo en siete. Cuando se logra un sistema de puntos consistente, cada equipo puede estimar de forma precisa la cantidad de trabajo que pueden hacer en la iteración, asumiendo que pueden lograr la misma cantidad de trabajo que en la iteración pasada (un concepto de XP llamado "el clima de ayer"). Entonces, si mi equipo entrega 27 puntos de funcionalidad en la última iteración, es razonable asumir que van a poder hacer lo mismo en esta iteración.
Entonces, ¿es posible usar la velocidad como medida de productividad? No directamente. Por ejemplo, tenemos dos equipos, A y B, cada uno con 5 personas y cada uno trabajando en un sitio web, y cada uno con iteraciones de dos semanas. El equipo A informa una velocidad de 17 puntos en su iteración actual, y el equipo B una velocidad de 51 puntos. Ambos equipos tienen 5 personas, por lo que el equipo B parecería ser 3 veces más productivo (51/17) que el equipo A. ¡No! No podemos comparar la velocidad de dos equipos porque usan unidades de medida diferentes. El equipo A informa usando su sistema de puntos, y el B en los suyos, por lo que no podemos compararlos directamente. La estrategia tradicional sería pedirle a los equipos que usen las mismas unidades para los puntos. Esto puede ser una estrategia viable con dos equipos, aunque no tanto si tenemos veinte equipos ágiles, y seguro que no funciona si tenemos doscientos equipos. Sin importar la cantidad de equipo que tengamos, va a requerir de por lo menos algo de coordinación el lograr normalizar todas las unidades y quizás incluso algo de capacitación y desarrollo y soporte para las nuevas guías de cálculo de velocidad. Todo esto suena como burocracia innecesaria que preferiríamos evitar. Peor aún, estas llamadas mediciones "consistentes", como los FP, en realidad no lo son porque siempre existe algún factor de "engaño" involucrado en el proceso, que va a variar en las estimaciones individuales.
La aceleración
Existe una solución más simple. En vez de comparar las velocidades, podemos calcular la aceleración de cada equipo. Por ejemplo, consideremos las velocidades que nos informan los equipos más abajo. La velocidad del equipo A se incrementa a lo largo del tiempo, mientras que la velocidad del equipo B tiende a disminuir. Si todo es igual, podemos asumir que la productividad del equipo A se incrementó, mientras que la productividad del equipo B está disminuyendo. Por supuesto, no es bueno gestionar las cosas sólo por los números, así que en vez de asumir lo que ocurre sería mejor ir y hablar con las personas de ambos equipos. Al hacerlo podríamos descubrir, por ejemplo, que el equipo A adoptó prácticas orientadas a la calidad (como integración continua y análisis estático de código) que el equipo B no hace, lo que nos indicaría que al equipo B podría servirle implementar estas prácticas para que incremente su productividad.
Velocidad del Equipo A: 17 18 17 18 19 20 21 22 22 ...
Velocidad del Equipo B: 51 49 50 47 48 45 44 44 41 ...
Para calcular la aceleración se usa una fórmula muy simple:
aceleración = (velocidad iteración x2 - velocidad iteración x1) / velocidad iteración x1
Ventajas de la aceleración
Hay varias ventajas de usar la aceleración como un indicativo de productividad por sobre las técnicas tradicionales (como FP).
Es fácil de calcular
Por ejemplo, la aceleración del equipo A desde la iteración 1 a la iteración 6 es (20 - 17) / 17 = 0.176. La aceleración del equipo B es (45 - 51) / 51 = -0.118. Como vemos, el equipo A tiene una aceleración positiva (está aumentando su productividad), mientras que el equipo B tiene una aceleración negativa (su productividad disminuye).
Por supuesto, no es necesario calcular la aceleración en un periodo tan grande de tiempo, sino que se podría hacer iteración a iteración. Sin embargo, la aceleración a través de varias iteraciones tiene mucho más valor. Es necesario ir experimentando para ver qué funciona mejor para cada uno.
Es barato
La aceleración se basa en información que ya tiene el equipo (su velocidad), por lo que no hay trabajo extra para el equipo.
No es probable que se manipule
Los equipos no tienen motivos para mentir sobre su velocidad, porque es información importante que les sirve para auto-gestionarse de forma efectiva.
Es facil de automatizar
Como son cálculos sencillos, es muy facil de automatizar con distintas herramientas para hacerlo visible.
Brinda una oportunidad para una gobernabilidad más efectiva
Este enfoque refleja tres prácticas del Gobierno de Desarrollo Lean: Métricas Simples y Relevantes, Monitoreo Continuo de Proyectos, y Ambiente de Ciclo de Vida Integrado.
Se puede ajustar facil para tamaños de equipo cambiantes
Si el tamaño del equipo varía con el tiempo (y va a ocurrir eventualmente), la métrica no sirve así como la describimos. Para solucionar este problema necesitamos normalizarlo. Esto se logra dividiendo por la cantidad de personas en el equipo, para obtener la aceleración promedio por miembro del equipo.
La métrica es facil de monetizar
Al conocer la aceleración de un equipo, y sabiendo cuánto dinero se gasta en cada iteración, se puede estimar la cantidad de dinero que nos estamos ahorrando al mejorar el proceso. Por ejemplo, si estamos gastando $100.000 po iteración, y la aceleración es del 2%, estaremos ahorrando $2.000 por iteración.
Nada es perfecto... (desventajas de la aceleración)
Por supuesto, nada es perfecto y existen algunas potenciales desventajas.
Es una medición indirecta de la productividad
En realidad, la velocidad es una medición de la productividad, lo que ocurre es está medida en diferentes unidades, por lo que es dificil compararla entre equipos. La aceleración es un indicador en el cambio de la productividad.
Necesitamos medir lo que nos interesa
Vamos en contra de los vendedores de métricas, que durante años nos vendieron que hay que medir la productividad. Si pensamos un poquito, en realidad no nos interesa medir la productividad. Lo que realmente nos interesa saber son los cambios en la productivdad, porque nuestro objetivo es mejorar la productividad a través del tiempo (y es justo lo que la aceleración mide).
La gerencia debe ser flexible
Para que lo acepte la gerencia deben estar dispuestos a pensar más allá de la "caja tradicional de métricas". ¿Van a usar una métrica simple, no estándar, para calcular la productividad? ¡Hereje! ¿Van a medir directamente lo que les interesa en vez de calcular tendencias sobre largos períodos de tiempo? ¡Doblemente hereje!
Pueden cuestionar el programa actual de métricas
Una vez que la gerencia aprenda lo facil que puede ser obtener métricas que les permitan realmente guiar los proyectos de desarrollo de software, pueden empezar a preguntarse sobre la inversión que hicieron en el pasado es esquemas de métricas más costosos y complejos. Esto puede resultar peligroso para los profesionales de métricas en la organización, especialmente si este equipo de métricas no tiene mediciones válidas sobre el valor de su propio trabajo. Ummmm...
En resumen, medir la aceleración de los equipos de desarrollo es información facil de recolectar, y una medida directa de la productividad del equipo. Espero que tengan algo nuevo para pensar, y comenten si tuvieron experiencias aplicando esta métrica en la práctica.
