Hace poco vimos el concepto de Aceleración como medida ágil de productividad en los equipos. La aceleración nos servía para ver cambios en la productividad de un equipo sobre un período de tiempo determinado.
Ahora vamos a analizar más en detalle algunas cuestiones relacionas con el uso de este indicativo para mejorar el rendimiento de los equipos ágiles de software.
¿Cómo monetizar la aceleración?
Es algo bastante simple de hacer. Por ejemplo, asumamos que la aceleración fue de 0,007 (0,7%), que hay cinco personas en el equipo, que el costo anual por persona es de $150.000, y que se hacen iteraciones de dos semanas. Todos estos números son inventados, pero ya sabemos cómo calcular la aceleración, y a la gerencia de Sistemas más le vale conocer el costo promedio de su equipo (el salario más los extras). Entonces, el costo promedio por persona por iteración es de:
$150.000 / 26 = $5.770 (un año tiene 26 iteraciones)
La mejora en productividad por iteración de este equipo es de:
$5770 * 5 * 0,007 = $202
Si la aceleración se mantiene constante en 0,7% la mejora general de productividad para el año sería de (1,007)^26 (asumiendo que el equipo trabaja las 52 semanas del año), lo cual sería 1,198 o el 19,8%. Esto representa ahorros por $148.500 (casi el equivalente a contratar una nueva persona). Por supuesto que un incremento de productividad del 20% en un año es una mejora realmente muy agresiva, sin importar lo que nos quieran vender ahí afuera. Sin embargo, un incremento del 10-15% es un objetivo razonable.
Lo que también podemos hacer es calcular la aceleración del año comparando la velocidad desde el inicio del año hasta el final del año (en las culturas occidentales es preferible evitar comparar iteraciones cerca de las fiestas). Entonces, si la velocidad del equipo en la primera semana de Febrero 2008 fue de 20 puntos, y ahora la velocidad del mismo equipo para la primera semana de Febrero 2009 es de 23 puntos, la aceleración es de (23 - 20) / 20 = 15% en el período de un año, representando ahorros por $112.500.
¿La aceleración no tiene unidad?
Por el bien de la comparación, la aceleración no tiene unidad. Las "unidades" son el porcentaje de cambio en puntos por itearción, o porcentaje de cambio en puntos por período de tiempo, dependiendo de la forma en que lo veamos. Como es un porcentaje es muy facil de monetizar, como vimos recién, y usarlo como base de comparación.
¿Cómo convencer a los equipos para que compartan sus datos?
Esto puede resultar dificil. Como la aceleración es facil de calcular para los equipos ágiles, y porque es facil de usar para comparar equipos (mi equipo tiene 0,7% de aceleración mientras que aquellos otros equipos detrás de esa pared tienen 0,3% y -0.2%), las personas se preocupan de que la métrica sea usada en su contra. Claro que, seamos justos, a MI equipo no le importaría... ;-) En serio, este es un temor válido que sólo puede superarse con un programa efectivo de gestión, basado en compromiso, colaboración y confianza en vez del enfoque tradicional de órden-y-control. Toda la historia de cómo las gerencias usaron en el pasado las métricas, y cómo se comportaron en general, tiene un gran impacto en la confianza que las personas están dispuestas a depositar en este nuevo enfoque de métricas, como la aceleración. La consecuencia es que necesitamos generar confianza, y esto es algo que puede llevar años lograr (si es que se logra).
¿Cómo funciona la aceleración con equipos ágiles?
Los equipos ágiles son auto-gestionados, y una consecuencia de esto es que son responsables de sus estimaciones. Por esta misma responsabilidad, y porque la velocidad es un dato vital para sus esfuerzos de planificación y estimación, los equipos ágiles se sienten motivados a calcular su velocidad de forma exacta, y hacer un seguimiento a través del tiempo. Como quieren mantener la velocidad correcta, y porque la aceleración se basa en la velocidad, hay grandes probabilides de que la aceleración sea bastante precisa.
¿Qué pasa con los puntos de función o medidas de productividad similares?
Los puntos de función se pueden calcular para proyectos que están siendo desarrollados con un enfoque ágil, u otros enfoques para el caso, pero es una tarea muy costosa comparada al cálculo de la aceleración (que es esencialmente gratis), y más probable que el equipo de desarrollo lo vea como algo burocrático. Mi regla general es que si no me están pagando explícitamente para que cuente puntos de función (como ser, por algún contrato que obligue a realizar estimaciones en puntos de función), entonces directamente ni me molesto con eso.
¿Se puede calcular la aceleración para equipos de proyectos iterativos?
Los equipos de proyectos iterativos, quizás siguiendo el Rational Unified Process (RUP), pueden elegir calcular su velocidad y su aceleración. La clave es permitirle al equipo que se auto-organice y sea responsable de sus estimaciones, que a su vez va a motivarlos a calcular correctamente su velocidad, al igual que los equipos ágiles (RUP puede ser tan ágil como uno quiera, no dejes que algún otro te diga lo contrario).
¿Se puede calcular la aceleración en equipos de proyectos tradicionales?
En teoría debería funcionar, en la práctica casi seguro que no. Los equipos tradicionales no trabajan con iteraciones ni producen software de manera regular, no suelen ser auto-gestionados, y por lo tanto no tienen ninguna motivación para calcular su velocidad (e incluso si lo hacen, hay muy poca motivación para que lo hagan bien). Sin saber la velocidad no podemos calcular la aceleración. Si no podemos confiar en la estimación de velocidad del equipo, y yo seguero que no confiaría en su estimado de velocidad, entonces no podemos confiar en el cálculo de la aceleración. Así que mi alternativa en estos casos sería hacer algo como contar puntos de función (lo cual es costoso y dificil para comparar entre equipos debido a los distintos factores de cambio que se usan, y a los distintos contadores de FP), y después miraría los cambios en FPs a través del tiempo.
¿Cómo puedo aplicar la aceleración en todo mi departamento?
Es bastante simple aplicar la aceleración de equipos de proyectos en un aceleración general para un portfolio de equipos. Simplemente se toma un promedio normalizado basado en el tamaño del equipo. Sin embargo, esto sólo aplica a los equipos que están en una posición de poder informar su aceleración precisa (equipos ágiles o iterativos), y por supuesto que estén dispuestos a hacerlo.
¿Qué me dice una aceleración negativa?
Si la aceleración es negativa entonces la productividad del equipo está disminuyendo, seguramente un indicador de problemas de calidad o de trabajo en equipo. Sin embargo, es mala idea gestionar con números, así que mejor deberías hablar con el equipo y ver qué está pasando realmente.
¿Qué me dice una aceleración en cero?
Este es un indicativo de que la productivdad del equipo no aumenta, y quizás deban considerar hacer retrospectivas al finalizar cada iteración y luego actuar en base a los resultados de dicha retrospectiva.
Basado en Examining acceleration.
