Vuelvo a leer a Antonio Quiros explicando su visión sobre la gestión de proyectos, en el número de Noviembre de dotNetMania, la revista de referencia en el mundo .Net en castellano. Ya comente lo poco que compartía su visión de la gestión de proyectos de software en un anterior post: ¿Nos podemos caer de maduros?. Pero no me resisto a comentar de nuevo sobre este tema.
Este més le toca a las métricas. Ya desde el propio título del artículo empiezo a disentir de la visión de la gestión de proyectos de Antonio Quiros: Métricas para la EVALUACIÓN de procesos de contrucción de software.
Que nadie piense que menosprecio el valor de la métricas. Las metricas son una arma de suma importancia para ganar información sobre los proyectos que nos permita gestionarlos mejor y reaccionar antes a los problemas.
Pero, si algo a descubierto la ingenieria del software en los últimos tiempos, es, que las métricas no sirven para evaluar. El motivo es sencillo, las personas son mucho más inteligentes que las métricas. Los proyectos son un sistema dinámico formado por personas dinámicas. Si tu estableces una métrica del estilo % eficiencia = 100 * (horas previstas / horas reales) es facil preveer como se va a mejorar esa métrica, ¡no reportando horas reales! es decir perdiendo información. Información que es valiosa sobre tu proyecto. El punto aquí no es que las métricas propuestas por Antonio Quiros sean más o menos validas, sino que para lo que no son validas, como cualquier otra, es para evaluar. Utilizar las métricas para evaluar nos puede llevar a generar una cultura de cumplimiento, en la que pongamos el proceso sobre las personas, olvidando la importancia de estas.
La métricas prescriptivas, del estilo 'la eficiencia tiene que ser mayor de x valor' se tienden a sesgar cuando se utilizan para evaluar. Y el problema es que cuando los desarrolladores sesgan las métricas el jefe de proyecto pierde valiosa información. Otro factor dañino de utilizar las métricas para evaluar, es que los desarrolladores se las apañaran para mejorar esas métricas sobre las que evaluamos, olvidando aquellos aspectos del proceso de desarrollo que no se evaluan. Y siempre hay algún aspecto que no se evalua, sea este más o menos explicito.
Bien, si las métricas no sirven para evaluar y no pueden ser prescriptivas, ¿para qué sirven?. Sirven para recopilar información sobre nuestro proyecto, que nos permita una mejor toma de decisiones. Para ello debemos analizar las métricas no de manera prescriptiva, buscando una manera de estar en cierto rangos, sino de una manera descriptiva, viendo las métricas de una manera gráfica y multidimensional, relacionando varias de ellas, por ejemplo defectos abiertos, respecto a tareas bloqueadas, para ver que hay defectos que nos están bloqueando tareas.
El problema es que esa mirada, descriptiva, multidimensional y gráfica a las métricas, no es constante, debe cambiarse de proyecto a proyecto e incluso en diferentes momentos de un mismo proyecto. Esta visión de las métricas es la que ayuda a mejorar el proceso de desarrollo, aunque, por mucho que pese a algunos gestores no sirve para evaluar el desempeño. No es tan comoda como la visión prescriptiva, pero es mucho más ágil y nos permite detectar problemas mucho antes en aspectos sobre los que no tenemos métricas explicitamente establecidas; y lo que es más importante, evitar que los desarrolladores sesguen las métricas. El acercamiento a las métricas de manera descriptiva, multidimensional y gráfica es el que propone MSF e implementa Team System. Es cierto que es dificil de llevar a cabo sin herramientas adecuadas, pero ahora esas herramientas existen: VersionOne, Team System…
Ojo, nadie piense que este sesgo de las métricas es un proceso consciente del desarrollador, es incosciente. Pero es evidente que si a mi me evaluan por tal o cual factor es ese el que voy a tratar de maximiza, aunque probablemente me olvide de otros. Sobre este tema es especialmente esclarecedor el artículo 'Larry's rules of software engineering #2: Measuring testers by test metrics doesn't'.
En mi opinión el principal problema de las métricas que propone Antonio Quiros es que todas son subceptibles de ser sesgadas del mismo modo: trabajando horas de las que no informas. No voy a ser mal pensado y deducir que esto es precisamente lo que tratan de buscar estas métricas (y muchas otras propuestas con anterioridad). Con esta simple acción, trabajar más horas de las oficiales, mejoras todas las métricas que propone en su árticulo, y a medio plazo ¡destrozas a tu equipo de desarrollo!. Espero que en los proyectos en los que se aplican esas métricas vayan acompañadas de una clara política de ferreo control de excesos de horarios, pero, conociendo esa industria me temo que no sea así. Las métricas propuestas en el artículo caen en el error, ya descrito hace 15 años en Peopleware, de realizar el llamado 'spanish management', nombre que tiene su origen la gestión realizada por los conquistadores sobre los recusos de las tierras Americanas. Básicamente consiste en mejorar la productividad no mediante mejores prácticas sino mediante mayor utilización de recursos, práctica solo sostenible a corto plazo.
Por último me sorprende ver en el artículo métricas que hacen referencia a líneas de código. ¿Sabe Antonio Quiros cuantas lineas de código se generan en un IDE moderno con solo arrastrar un botón? (Se que lo sabe). ¿Cómo se comparan esas líneas con las necesarias para escribir una capa de acceso a datos empresarial? En los tiempos que corren la línea base se debe establecer en puntos función. Y los puntos función solo sirventras un largo proceso de ajuste por tipo de proyecto y organización. Tambien hecho de menos algunas de las métricas clasicas, por ejemplo las relativas a bugs, a cambios en los requisitos, a retrabajo, etc… realmente centradas en el desarrollo de software y no en la gestión mal entendida de recursos.
Para cerrar un poco de humor relacionado con el tema de los datos: