Per Kroll

La plática se enfocó en dos puntos. El primero fue simplemente hacer ver que no existe una forma única de hacer desarrollo ágil; no existe ningún método “listo para usarse” que funcione para todos.
Las organizaciones que desean adoptar ágil deben comprender que deben ajustar los procesos en base al tipo de problemas que buscan resolver, así como al contexto de la organización. El otro tema que manejé en mi plática fue el de métricas. En la industria de software tenemos el problema de que muchas organizaciones se embarcan en esfuerzos de mejora de procesos, pero no tienen forma de
medir qué es lo que les está funcionando y qué no, así que simplemente están adivinando cuáles son las prácticas que les traen beneficios.

Por lo pronto encontramos que la mayoría de las organizaciones de software no tienen métricas establecidas. En el caso que las tengan, tienden a recolectarse de forma manual, esto quita tiempo a los desarrolladores y es susceptible a errores humanos o malas intenciones. Otro problema es que las métricas solo son de interés para los gerentes pero no para el equipo, por lo que no hay un sentido de responsabilidad.

Existen dos grandes tipos de métricas: las de resultados y las de control. Las primeras te indican si se está cumpliendo un objetivo específico, las segundas si se está trabajando de la forma que se
había acordado para poder cumplir los objetivos. Nosotros identificamos tres niveles de métricas: el nivel de negocio que se enfoca en métricas de valor, como sería el retorno de inversión; luego está el nivel operacional donde nos enfocamos en métricas de efectividad, como la productividad, el tiempo para implementar un proyecto (time to market); el último nivel es el de prácticas, es decir las métricas para determinar si un proceso se está ejecutando de forma adecuada y si el equipo está satisfecho
con la forma en la que se está trabajando. Las métricas de los dos primeros niveles son de resultados, mientras que las métricas del nivel de prácticas son de control. A final de cuentas, los tres niveles están ligados. Es decir, la forma en la que el equipo trabaje (métricas de control), afectará los resultados operativos y esto a su vez afectará el valor entregado al negocio.

Lo que hemos encontrado es que muchas organizaciones de software que se embarcan en iniciativas de mejora, deciden adoptar marcos genéricos y los adoptan al 100%. Esto rara vez es exitoso,
ya que las organizaciones adoptan más prácticas de las que necesitan, lo cual es costoso e inútil.
Hagamos una analogía, imagínate que decides entrenarte para poder correr un maratón. Para ello, seguramente recurrirás a un entrenador. Lo primero que el entrenador hará será hacerte una evaluación
para conocer tus fortalezas y debilidades. En base a ello, te hará un plan de entrenamiento basándose en tu estado actual y los objetivos que deseas; tal vez se enfoque en aumentar tu fuerza, tu resistencia, tu técnica de respiración, tu alimentación, etcétera. Conforme vaya avanzando tu entrenamiento y en base a los resultados que se vayan obteniendo, el plan de entrenamiento se irá adaptando para poder cumplir los objetivos establecidos. Esto mismo debe hacerse cuando una organización desea mejorar sus resultados de desarrollo de software. Es decir, en lugar de ponerse a implantar de principio a fin un proceso genérico, primero debe establecer sus objetivos, luego evaluarse para saber cual es su estado, en base a esto determinar en qué necesita enfocarse para lograr los objetivos establecidos, e ir adaptando dicho plan conforme se vayan teniendo resultados. Esto es lo que llamo adopción de prácticas incremental.

Así es. Dependiendo de qué es lo que busca el equipo (mejorar la calidad, el tiempo de desarrollo, la satisfacción del usuario, etc) se deben identificar las prácticas que tengan mayor impacto hacia esos objetivos e implementarlas de forma incremental.

Por ejemplo desarrollo iterativo, integración continua, arquitecturas basadas en componentes, desarrollo dirigido por pruebas.

Les recomiendo que busquen información sobre el “Measured Capability Improvement Framework” (MCIF), que es la iniciativa en la que trabajo, y que captura mucho de lo que he comentado aquí.