El pasado 16 de mayo, durante el 1º Evento Métrico organizado por GUFPI-ISMA en Roma, que tuvimos la oportunidad de patrocinar, conversamos con uno de los mayores referentes internacionales en métricas de software: Luigi Buglione. Presidente de GUFPI-ISMA, secretario de IFPUG, director para universidades y vicepresidente de ISBSG, Luigi ha dedicado su carrera a promover el uso de estándares como IFPUG Function Points y SNAP para mejorar la estimación, la productividad y la toma de decisiones basada en datos.
En esta entrevista, hablamos sobre el papel de la inteligencia artificial en el desarrollo y estimación de software, del estado actual de Agile, de la necesidad de medir para mejorar y cómo enfocar el futuro desde una perspectiva cuantitativa y humana.
Entrevista realizada por Julián Gómez, CDAIO de LedaMC y Quanter. En italiano, subtítulos disponibles en español e inglés
Julián Gómez: Primero de todo, gracias, Luigi por aceptar esta entrevista. Creo que será muy interesante porque eres una referencia en el mundo de las métricas.
Tu opinión siempre es importante para saber cómo avanzará este mundo.
Luigi Buglione: Gracias a ti Julián, gracias a Quanter Smart AI Estimation.
J.G.: Ok, gracias, para comenzar, H.P. Lovecraft decía: «No está muerto lo que puede yacer eternamente, y con el paso de extraños eones, hasta la muerte puede morir».
¿Agile ha muerto o aún tiene mucho que ofrecer?
L.B.: Aún puede ofrecer mucho valor. Lo que necesitamos es mejorar nuestras competencias, especialmente para medir sprints e interacciones.
Hay que dejar de hacer estimaciones basadas en la experiencia solo con story points o t-shirt sizing y empezar a introducir como base en la planificación de sprints también una medición funcional y no funcional, pero con métricas cuantitativas.
Usando puntos función, puntos SNAP u otras métricas ISO no funcionales puede ayudar sin duda alguna.
Sin eso, las estimaciones en días-persona siguen siendo muy variables.
J.G.: Ok bien, pero en esta línea que estamos hablando de aprovechamiento de Puntos Función, SNAP points, recientemente IFPUG en colaboración con Quanter publicó un informe sobre el mercado de desarrollo de software destacando los beneficios de estas métricas incluso en contextos Agiles. ¿Qué beneficios consideras para las empresas que aún no han utilizado las métricas basadas en el producto software? ¿Qué se están perdiendo?
L.B.: Principalmente dos cosas:
No pueden cuantificar el valor de un activo (lo que no se mide no existe, existe solamente el tiempo de trabajo).
Y la otra cosa se vuelve muy importante también, por otro elemento que implica a muchas de nuestras empresas, dentro de otro grupo que es ISBSG, es decir, la productividad.
Si no tienes una cantidad dividida por un tiempo de trabajo, no puedes calcular la productividad, porque solo tendrás un esfuerzo expresado en story points o en una estimación basada en la experiencia.
Y entonces, al faltar el elemento el histórico, cada vez se parte desde cero. En italiano diríamos, un poco como la memoria de un pez rojo (memoria de pez).
J.G.: Efectivamente. Has hablado en otras ocasiones del concepto de toma de decisiones basada en hechos, algo que encaja perfectamente con el paradigma del desarrollo de software. ¿Qué errores comunes observas en las organizaciones cuando intentan tomar decisiones basadas en datos?
L.B.: Que no recopilan datos.
Y en particular los jefes de proyecto, que normalmente deberían haber estudiado, también en guías como el PMBOK y muchas otras, que lo primero que hay que hacer en una fase de cierre es recopilar datos. En un proyecto ágil, esto sería hacer una retrospectiva.
El problema es que no siempre se hace, porque se dice que falta tiempo para ello.
Lo cual significa que no se ha planificado.
Y, por tanto, ese puede ser el primer punto de mejora.
J.G.: Ok, gracias Luigi. Con tu experiencia en organizaciones como GUFPI-ISMA, IFPUG o ISBSG, ¿qué crees que hace falta para superar la resistencia de algunas empresas a adoptar estándares ISO/IEE como IFPUG Function Points o IFPUG SNAP Points?
L.B.: Lo importante es entender bien el punto de vista de quien respondería «No los necesito» o «Creo que no sirven».
La motivación, en mi experiencia, es que a menudo te encuentras con managers que no quieren profundizar en el tema y que solo miran la rentabilidad a corto plazo.
Si, en cambio, uno empezara a comprender que no puedes decir cuánto tiempo necesitas para hacer algo si antes no sabes cuán grande es, y además con una medida objetiva, con un margen de subjetividad muy, muy reducido, entonces cualquier número pasa a ser importante.
Como en “La Guía del Autoestopista Galáctico”, donde el número mágico es 42.
J.G.: Exactamente, todo es válido. Hay críticas a los procesos de medición, ¿no? Algunos los consideran una carga innecesaria que no aporta beneficios.
Sin embargo, Agile nos ha mostrado que usar las métricas correctas marca la diferencia.
Lord Kelvin decía: «Lo que no se mide, no se puede mejorar.» ¿Crees que esta frase sigue siendo válida hoy en día?
L.B.: Absolutamente sí, pero por un motivo muy, muy simple: Si no sabes cuánto vale un objeto, es decir, su cantidad, no puedes saber cuánto tiempo te va a llevar.
Y si no sabes cuánto tiempo te va a llevar, ni quién va a trabajar en ello, no sabes cuánto te puede costar, ni a qué precio venderlo si fueras proveedor, o cuánto pagar por él si fueras cliente.
Nosotros lo llamamos un flujo QTC: de las cantidades a los tiempos, de los tiempos a los costes.
Así que otra de las cosas que sugerimos a toda la comunidad, métrica y no métrica, es usar las medidas para determinar tiempo correcto y según las personas asignadas al proyecto, que tienen costes distintos.
Tener en cuenta el skill mix, el coste medio diario de ese equipo en ese contexto, para luego fijar un precio de mercado.
Eso es lo que llamamos el modelo ABC.
J.G.: Perfecto, Luigi. Este primer evento de GUFPI-ISMA del año está teniendo un gran éxito. Y este año está patrocinado por Quanter, una de las primeras herramientas que integra inteligencia artificial en el proceso de estimación.
Desde tu punto de vista, como experto en métricas, ¿cómo debería integrar un profesional las métricas en su trabajo diario? ¿Qué consejos darías, más allá, por supuesto, del uso de Quanter Smart AI Estimation?
L.B.: ¡Obviamente! Tener una buena práctica de prompt engineering es fundamental.
Hoy, aunque no se escucha en esta entrevista, hemos generado canciones con inteligencia artificial. De hecho, hicimos varias versiones usando prompts de menos de 10 palabras, con un efecto que, según el público, fue simpático, agradable y eficaz.
La generación y estructuración de requisitos se está convirtiendo en un activo muy importante para un business analyst que, si tiene o adquiere competencias métricas, podrá usar la inteligencia artificial para acelerar los tiempos, siempre que entienda bien cómo interactuar con la máquina.
Como se dijo en una de las presentaciones de hoy: interacción hombre-IA, no interacción hombre-máquina. Y ese, sin duda, es el camino.
J.G.: Sí, podemos decir que la inteligencia artificial no va a sustituir, sino que va a potenciar a las personas. Gracias.
En este contexto, ¿cómo ves el impacto de la inteligencia artificial en el desarrollo de software? Por ejemplo, el uso de asistentes para generar código y automatizar los tests. ¿Qué impacto crees que tendrá sobre las métricas tradicionales como los Function Points de IFPUG o SNAP?
L.B.: Como se ha dicho también en muchas presentaciones de hoy y de otros eventos, es necesario mantener la conciencia sobre las alucinaciones (de la IA).
Un hashtag que hemos propuesto en ISBSG es #datahallucination.
Para empezar a distinguir también en licitaciones, pliegos técnicos o contratos, que no se incluyan valores no verificados de productividad, tamaño o esfuerzo, si luego no hay una correspondencia con el mundo real.
Generar modelos de aprendizaje automático también tiene un coste. Por eso, lo que debe revisarse en un ciclo de vida completo es desplazar hacia las fases iniciales los mayores costes, que se reducirán en las fases de elaboración y realización.
Hablamos, por tanto, de una redistribución de costes, no de pequeños ahorros: eso es indudable.
El otro punto es que, como con todas las herramientas, no hay que ver la IA como un sustituto del ser humano, sino como una herramienta que debe permanecer bajo el control del ser humano.
J.G.: Gracias Luigi. ¿Crees que estas métricas seguirán siendo aplicables tal como están o será necesario adaptarlas a este nuevo contexto dominado por la IA?
L.B.: La parte funcional nace en 1979 con Albrecht y sigue siendo una métrica de proceso, por lo tanto, independiente de la tecnología.
La creencia errónea es pensar que la productividad está ligada únicamente a las cantidades, cuando en realidad es la relación entre cantidad y tiempo. Así que medir funcionalidades seguirá siendo un proceso estable.
Lo que cambiará será la técnica: IFPUG, COSMIC, NESMA, FISMA, Mark II…, pero el enfoque se mantendrá estable.
Lo que sí cambiará, incluso dentro de IFPUG, es que, al crear y actualizar SNAP, deberemos tener cada vez más en cuenta, junto con Fabrizio Di Cola y el grupo de trabajo no funcional, la calidad de los datos, como define la norma ISO 25012, actualmente no contemplada de forma estricta en el modelo, y también la ISO 25059.
Por lo tanto, lo que veremos serán probablemente evoluciones dentro del modelo SNAP.
J.G.: Ok, perfecto, gracias, Luigi. Ahora están surgiendo nuevos enfoques para la programación, como el Vibe Coding, donde la IA genera el código a partir de descripciones en lenguaje natural. ¿Crees que llegaremos también a una Vibe Estimation, en la que el experto en métricas coordinará asistentes de IA para hacer las estimaciones?
L.B.: Dependerá siempre de los costes y de la relación coste-beneficio.
Inicialmente habrá empresas que invertirán más para tener productos que, de algún modo, serán asistentes para otros stakeholders.
Y dependerá sustancialmente de la cantidad de datos y del coste para entrenar un sistema que se pueda revender al precio adecuado.
El problema será siempre la verificación previa de la corrección de los datos introducidos, lo cual no tiene que ver ni con la calidad del código, ni con la calidad de la IA (que al fin y al cabo es software), sino con la calidad de los datos, que de todos modos siempre serán verificados de alguna manera manualmente.
J.G.: Ok, perfecto, ¡y la última pregunta es la más difícil de todas para terminar!
¿Inter o Milan?
L.B.: Inter. 31 de mayo, Mónaco.
J.G.: ¡Gracias Luigi, un placer!
L.B.: Gracias a vosotros.
Sobre el autor
Agile | Eficiencia | Estimación | inteligencia artificial | Puntos Función
