El título de este post parafrasea el título de una novela de ciencia ficción que tal vez conoces: « ¿Sueñan los androides con ovejas eléctricas? ».

Esta novela de Philip K. Dick ha sido la base para la película « Blade Runner » de Ridley Scott, en la que un detective del futuro debe encontrar y neutralizar a unos androides que nada puede diferenciar de los humanos.

En el libro, el detective tiene una oveja en carne y hueso, que él sustituye, a su muerte, por una oveja ‘eléctrica’. Él viene a preguntarse si los androides sueñan como él con una mascota, pero en su versión ‘animaloïde’.

Esta obra de K. Dick plantea una reflexión sobre la diferencia entre el humano y el robot, entre lo real y lo automatizado. Me la recordé cuando me pregunté cual es la diferencia entre los puntos de función (Function Points o FP) en su versión manual y los puntos de función automatizados (Automated Function Points o AFP).

Hoy en día, más y más desarrolladores utilizan cada día las métricas de herramientas de análisis de código, estadísticas de pruebas, de seguimiento de correcciones y de cambios, los datos de la deuda técnica, etc. en su proyecto o en un proceso de integración continua.
Pues me pregunté ¿por qué los desarrolladores, cada vez más aficionados a las medidas relativas a su código y sus proyectos, ignoran generalmente todo de los puntos de función? ¿Podría interesarles esta medida?

Puntos de Función

No voy a explicar lo que es un Punto de Función: esto no es el tema de este post y necesitaríamos muchas páginas. Sobre todo porque este término se relaciona con diferentes normas y métodos, por no hablar de diferentes escuelas. Digamos sencillamente que el FP es una medida del tamaño funcional de una aplicación, basada en los flujos transaccionales y las estructuras de datos.

Si, lo sé: no es una definición precisa, pero de nuevo, no quiero entrar en esta discusión, sino recordar cuales son los objetivos principales de los Puntos de Función:

• medir el tamaño funcional de una aplicación existente o futura,
• de manera estandarizada y objetiva, con independencia de las tecnologías y de las organizaciones, permitiendo así comparaciones (benchmarking),
• con el resultado de que esta medida se utiliza a menudo para evaluar la productividad de los desarrolladores.

¿Saben los desarrolladores que es un Punto de función?

No, los desarrolladores no conocen los puntos de función. Tal vez sí, pero yo nunca he conocido a un solo desarrollador que sepa lo que es.

Una de las razones podría ser que, en mi opinión, los desarrolladores no están naturalmente interesados ​​en los aspectos funcionales. No estoy diciendo que les importa poco, muchos desarrolladores se especializan en las áreas de banca, de finanzas, de industria, o en procesos de contabilidad, de logísticas, de recursos humanos, etc. Pero sabemos que es mejor hablarles de las nuevas tecnologías, de nuevos lenguajes de programación, de los últimos frameworks, posiblemente de metodologías de desarrollo o de proyecto si queremos llamar su atención.

Otros motivos por los que no van a mirar naturalmente esta métrica:

• Es complejo de entender: los desarrolladores saben lo que es una transacción o una estructura de datos, pero buena suerte si quieres explicar conceptos tales como ‘boundaries’ (fronteras) de la  aplicación y otros ‘factores de ajuste’.
• Es un proceso manual, por lo general largo y tedioso, no automatizado. Volveremos en una segunda parte con los puntos de función automatizados.

Creo que también hay algunas razones culturales. Los conocimientos anglosajones son bastante orientados a lo cuantitativo, mientras que nosotros europeos del sur, somos más propensos a lo cualitativo. Me recuerdo de mis cursos de sociología del trabajo en la universidad. Cuando un equipo de sociólogos americanos quería estudiar una organización – por ejemplo, un equipo de trabajadores en una fabrica – y ver qué lecciones se pueden aprender o cómo mejorarla, estaban a favor de la observación y la recogida de datos para medir la duración de una operación, el tiempo para que el producto X pasa del punto A al punto B, el número de productos fabricados, el número de defectos, etc.

Un equipo, vamos a decir francesa, empezaba a través de entrevistas con los empleados para evaluar su interés (o no) en el trabajo, sus observaciones sobre el proceso de fabricación y sus defectos, eventuales sugerencias para la organización de la cadena de producción, etc. El enfoque era esencialmente cualitativo, no tanto cuantitativo.
Muchas personas también consideran que no es posible medir cualquier producción inmaterial, y la productividad del trabajo intelectual.

Puntos de función y productividad

Otra razón por la cual los puntos de función despiertan mayor interés en los países anglosajones y en nuestros países latinos: la medición de la productividad. La capacidad de comparar y hacer benchmarking de los equipos y de los proveedores para comprobar que son capaces de producir código (si es posible de calidad) tan pronto como sea posible, es una especie de Santo Grial en la comunidad de los consultores.

Estos aspectos de productividad no ocupan un lugar tan importante en nuestras organizaciones. Recuerdo a un manager inglés a quien le expliqué que unos desarrolladores no querian usar un software de análisis de código, a pesar de todos los incentivos y los esfuerzos de su jerarquía. De inmediato, él me respondió que esto no ocurriría con él porque habría terminado inmediatamente los contratos de los rebeldes. Lo cual sería prácticamente imposible en la mayoría de nuestros países más mediterráneos, si no en Francia, al menos en España.

Obviamente, un desarrollador no puede rechazar una orden directa de su jefe, pero imponer a todo un equipo de proyecto que utiliza una herramienta es impensable, sin levantar todo tipo de objeciones, peligros y riesgos de comprometer el desarrollo de la próxima versión, y finalmente verlos sucumbir a una especie de apatía, rozando la inercia absoluta sobre el tema. Esta es también una de las razones por las que yo siempre digo que la calidad de las aplicaciones proviene de los desarrolladores y no se decreta. Convencer sí, imponer no.

Además, muchos desarrolladores son generalmente muy contentos de descubrir nuevas herramientas, pero serán naturalmente sospechosos si se trata de controlar su trabajo o de medir su productividad.

¿Los desarrolladores necesitan Puntos de Function?

No creo que los desarrolladores hayan necesitado puntos de función.

Ellos, por supuesto, estarían interesados ​​en una medición precisa de las características funcionales que implementar en un software, pero lo que les importa más es que los requisitos no evolucionan constantemente durante la fase de desarrollo. Por otra parte, un jefe de proyecto con experiencia será capaz de estimar la carga de trabajo que representan estas características. Y él sabe que también hay una variedad de factores que pueden obstaculizar al equipo para entregar la aplicación a tiempo y hora: el uso de una nueva tecnología no totalmente depurada, procesos de proyecto inadecuados, herramientas defectuosas o mal integradas, un equipo con una formación insuficiente o sin experiencia, etc.

También creo que los desarrolladores no necesitan Puntos de Función para conocer su productividad. Hoy en día hay muchos indicadores que nos permiten saber quién hace qué en un equipo de proyecto, y como se hace: el número de registro de check-in/check-out, el porcentaje de cobertura de pruebas, el número de defectos encontrados durante la QA, etc. Por no hablar de las métricas de análisis de código: es muy fácil saber quien duplica código con Copiar/Pegar, quien nunca comenta o poco su código, quien hace caso omiso de una mejor práctica, etc.

En una auditoria, si tengo más de una versión, intentaré calcular una medida del esfuerzo de desarrollo entre dos versiones. Si conozco cuántos componentes se han añadido, cambiado, eliminado entre las versiones, y si puedo asignar una carga de trabajo para cada tarea (dependiendo de la Complejidad Cyclomatica de estos componentes, por ejemplo), soy capaz de calcular una estimación del número de días necesarios para la realización de esta nueva versión.

Por supuesto, no voy a obtener resultados muy precisos (1). Sin embargo, prefiero una medida imprecisa pero fácilmente comprensible, a una métrica que se pretende perfecta, pero no sabemos exactamente cómo ha sido calculada. Y mi cliente también: él quisiera saber si el proveedor externo ha pasado realmente los 500 días que le quiere facturar, y que parecen un poco exagerados a la luz del trabajo hecho. Si mi estimación es fácilmente comprensible para que se puede utilizar esta fórmula de una manera bastante objetiva y realista, una diferencia de 10% o 20% en la evaluación no será realmente un problema. Pero si nuestro cálculo resulta en 200 o 300 días de carga estimada en lugar de los 500 facturados, el outsourcer tendrá probablemente que responder a algunas preguntas.

Esto funciona en ambos sentidos: una vez, se me pidió una auditoría «a ciegas» para una aplicación crítica que tenía más de cuatro meses de retraso. Digo «a ciegas» porque no pude conseguir ninguna información sobre el contexto y la historia de este proyecto. Y me encontré con un número muy alto de componentes añadidos y eliminados entre las dos últimas versiones. Eso me parecía característico de evoluciones significativas de los requisitos funcionales entre las dos versiones. Y es lo que había pasado y que reconoció este cliente, basandonos en una estimación imprecisa pero todavía suficientemente objetiva para resolver esta discrepancia con su proveedor.

Este ejemplo muestra que una medida de esfuerzo de este tipo es útil, y entonces lo serían los Puntos de Función, que asuman una precisión mucho más sustancial que mi sencillo cálculo. Ahora imaginamos que la estimación de los puntos de función se puede automatizar: ¿sería suficiente para que los desarrolladores puedan utilizar esta medida?

Esto es lo que veremos en nuestro próximo post.

 

(1) Sin embargo, he notado que las cifras para lenguajes como Cobol o cliente-servidor son un poco más precisos que para los lenguajes OO de nuevas tecnologías.