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.

Llave en mano

Al menos en mi experiencia y entorno, los proyectos llave en mano son comunes. Me refiero por proyectos llave en mano a esos donde se compromete un precio y calendario con el cliente, y luego de ganar algo así como una compulsa de precios, comienza el desarrollo del software.

Estimar correctamente es un punto clave en este tipo de proyectos: una mala estimación hace perder dinero, tiempo, enojar al cliente por problemas de calendario y todo eso lleva a una caída en la calidad que aumenta los costos y hace enojar aún más al cliente.

Scott Ambler tiene una opinión bastante clara y razonada sobre los proyectos llave en mano. Ambler dice cosas ciertas: este tipo de proyectos te lleva a escribir todos los requerimientos de entrada, a pensar un diseño y una arquitectura y a implementar un mecanismo bastante restrictivo de gestión del cambio. Todo eso herético desde el punto de vista del desarrollo ágil. Yendo un poco más allá de mi último comentario, algo improcedente y sarcástico, se puede argumentar con razonable facilidad que intentar elucidar todos los requerimientos y pensar una arquitectura de un software que no existe antes de hacer siquiera una parte es una estrategia que traerá problemas, más temprano que tarde.

Por otra parte, no es un secreto que las estimaciones hechas a priori suelen diferir bastante del esfuerzo finalmente necesario.

Por eso, puedo estar de acuerdo con que la idea del proyecto cerrado es una idea perniciosa (puedo pensar en más de un ejemplo donde todos pierden: el cliente queda disconforme y el proveedor gastó más de lo que había proyectado).

Mirando desde el otro lado, si pensamos como el cliente, no es difícil entender por qué se desea saber por adelantado cuanto va a salir la joda: vamos, quien contrataría a un arquitecto (de casas y edificios) que dijera 'bueno, a medida que me vas pidiendo que construya algo en la casa, que agregue algo, te voy diciendo el precio'?. No vale argumentar que una casa es diferente al software, estoy hablando de dinero, que es bastante parecido en todos los ámbitos: quien se embarcaría en un proyecto sin tener idea de cuanto saldría y sin tener al menos la expectativa de tener dinero suficiente para no ahogarse a la mitad del río?. Yo no.

Aunque, como comenta Ambler, los proyectos cerrados puedan ser caros para el cliente porque el proveedor no tiene más remedio que cotizarle el riesgo e implementar algún mecanismo de control de cambio (efectivamente, como él dice, son mecanismos que tratan de impedir el cambio y no controlarlo). Más aún, con un mecanismo eficaz para impedir el cambio es altamente probable que el sistema construido diverja de las necesidades del usuario. Pero aún así, la previsibilidad financiera ( saber de antemano cuanto me va a costar) es terriblemente atractiva. Lo que se está pagando (lo que tanto cliente como proveedor están pagando), es la falta de información.

Se podría contra-argumentar que la idea de una metodología con foco en el control de cambios no es impedir el cambio, sino cobrarle al cliente por el mismo. No está mal, en definitiva, y eso nos acercaría a una estrategia ágil, donde ante cada cambio cobraríamos el diferencial de implementarlo ( costo de implementar lo nuevo menos el costo de no implementar lo que ya es necesario y no está implementado), lo que, incluso, penalizaría el cambio en etapas tardías del proyecto. Estaría incluso mejor si pudiéramos definir claramente, y por adelantado, qué es un cambio: no se puede cambiar lo que no se definió y el problema, muchas veces, no es que se haya definido un aspecto de un desarrollo en forma errónea, sino que no se lo ha definido de ninguna manera.

Claramente, necesitamos una solución. La solución ideal: que la industria se aleje de los proyectos cerrados, que el cliente nos contrate un equipo determinado por un tiempo pre-acordado y que adoptando el ciclo de vida de XP trabajemos haciendo lo que el cliente pide: pide más, hay más iteraciones. El problema es que parece demasiado bueno para nosotros, los informáticos, como para que se transforme en una práctica muy extendida.

A mitad de camino, tenemos la 'gestión de aplicaciones', o el servicio donde uno como proveedor implementa requerimiento a requerimiento. Es una buena idea, pero se necesita una confianza importante en la performance del equipo del proveedor. No es algo que un cliente le contrataría a un proveedor que recién conoce, me parece. Tampoco es, entiendo, demasiado común para desarrollos desde cero, sino que se adapta mejor a mantenimientos evolutivos y correctivos, donde, en definitiva, es más fácil estimar el esfuerzo de cada modificación.

Yo me imagino que la solución debería venir por alguna forma estándar en la industria de medir la performance de los grupos de trabajo en algo así como unidades estándares de software (que no sean lineas de código, por supuesto) producidas por unidad de tiempo. Volviendo al ejemplo del arquitecto ágil (el de casas y edificios) citado más arriba, creo que tal vez lo contrataríamos si pudiéramos acordar entre ambos, antes de comenzar el proyecto, una forma transparente de estimar los costos: nos aseguraremos que el arquitecto no se va a aprovechar de nuestra situación cuando sea muy caro abandonar el proyecto o cambiar de caballo. Que forma tendrían esas 'unidades estándares de software' (no de trabajo, sino de software)? Ni idea.