Estimaciones y futurología

Either estimate from a spec of provide data on prior work and let the customer judge the range. If the customers then wanted detailed estimates, they would have to pay for the specification and design work required to make them. Unfortunately, it will take the software community some time to build the skills and credibility to work in this way. Until we do, however, we will continue to have estimating and planning problems

Watts Humphrey, Estimating with objetcs.


Con los otros galeotes estuvimos discutiendo el tema de las estimaciones estos últimos días. El post anterior es un poco deudor de esas discusiones. Como toda discusión estuvo motivada por un problema, y un problema grave, o como se diría ahora, en una enorme oportunidad de mejora: la oportunidad de mejorar las estimaciones de nuestros trabajos y mejorar, a niveles aceptables, acota la desagradable voz que escucho y de la que ya hablé, la planificación de nuestros proyectos.

Fatigando la ignorancia, creo haber llegado a la conclusión de que todos los métodos de estimación se basan en los siguientes pasos:
1. Una descripción del objetivo (en términos propios y de su contexto, que el sistema es él y su circunstancia)
2. Una descripción de como implementar o llegar al objetivo
3. Una descripción de tamaño de los componentes o pasos para llegar al objetivo
4. Una relación entre el tamaño y esfuerzo

PROBE, COCOMO II, Puntos de Función, historias del usuario, todos, de una manera u otra siguen estos mismos pasos.

Primero, nos hacemos una idea del problema a solucionar, y una descripción somera de las capacidades del software que debemos construir. El desarrollo de requerimientos no es mi tema, por lo que hablaré del asunto aquí.

Luego, hacemos un diseño conceptual. Decidimos que objetos o componentes integrarán las solución, cuales reutilizaremos (con o sin modificaciones), y que construiremos desde cero. De acá sacamos una lista de componentes, objetos, tablas, archivos, interfaces, y demás que debemos construir.

Luego hacemos una una estimación del tamaño. Es difícil argumentar que el tamaño de un software se mide en el tiempo que se tarda en desarrollarlo, casi tanto como es difícil argumentar que la distancia entre dos ciudadades se mide por el tiempo que yo tardo en llegar desde una a la otra: el tamaño es una medida objetiva relacionada, sí, con el esfuerzo de desarrollo, pero en definitiva distinta. Si la analogía entre distancia y tiempo de viaje no resulta adecuada, se puede pensar en otra: masa y peso. La masa es la cantidad de materia (el tamaño en nuestro software), independiente de la gravedad (la performance del equipo), mientras que el peso es una medida que tiene en cuenta la masa y la gravedad (el tiempo que tardamos en hacerlo)

Una buena medida, según mucha gente son las líneas de código estandarizadas. El problema está resuelto: estimamos la cantidad de lineas de código que tendrá el software que implementará unos requerimientos poco claros con un diseño aún no decidido y listo, no?. Bueno, no. Entre otras cosas por lo ridículo que sería sostener que para calcular el tiempo que tardaremos en desarrollar algo, primero debemos saber cuantas líneas de código tiene ese algo, Humphrey propone objetos como 'apoderados' o 'representantes' de las líneas de código (proxies, los llama).

Una disgresión con respecto a las lineas de código: es probable que haya una correlación entre las líneas de código escritas y el esfuerzo insumido, y tal vez sea posible defender su utilidad como métrica post-mortem de los proyectos,para comparar la performance de proyectos entre sí, si mantenemos igual las demás variables (lenguajes, entornos operativos, frameworks, y alguna más que ahora se me escapa). Sospecho, de todas maneras, que esta métrica post-mortem era más certera antes de los lenguajes con introspección.

Es claro como la estimación de tamaño ocurre si usamos puntos de función o puntos de caso de uso, pero diría que aún las historias del usuario tienen una etapa de estimación de tamaño: Kent Beck propone en Planning Extreme Programming, basar la estimación de historias de usuario en historias de usuario que hayamos implementado en el pasado, que sería algo así como lo que hicimos con mis compañeros galeotes, pero intuitivamente: pensar el tamaño de un componente, o de una historia de usuario, en términos de historias ya realizados. Esto es, decir, por ejemplo que una historia X que acabamos de recibir tiene un tamaño que cumple cierta relación con el tamaño de una historia anterior. Si bien se mira, las medidas no son más que eso: la relación entre una magnitud actual y una magnitud elegida por algún tipo de convención (cuando decimos que algo mide un metro treinta centímetros, decimos que se trata de una distancia igual a la distancia recorrida por la luz en el vacío durante algo así como 4,33nano segundos )

En el último paso, relacionamos el tamaño con el esfuerzo necesario, con una medida que podemos llamar de varias maneras, pero que en definitiva no es sino una expresión de nuestra performance de desarrollo. Acá, como en el resto, la estadística es fundamental y depende de cuan bien hayamos medido nuestra experiencia.

En definitiva, la clave para mejorar está en capitalizar nuestra experiencia, de una manera sistemática que nos sirva para formar juicios en el futuro, como en cualquier práctica que tenga que ver con la tecnología y la ingeniería.