Estimo que...

Como parte de nuestro programa de mejora continua en el proceso de estimación, y dado que aún tenemos la hermosa sensación de desafío que produce el saber que existe una magnífica oportunidad de mejora en este tema (esta forma de decir 'quilombo a resolver' la aprendí en un curso de coaching), estuvimos pensando en que, si el proceso de estimación está tan verde, tal vez mereciera la pena invertir un par de horas en revisar los resultados.

Tuvimos que asumir que era (y es) nuestro punto más débil. Listo, agarramos la definición del proceso y le agregamos un paso más. Y salvado el hombre, hermanos!. Bueno, nada es tan simple: como hacíamos para que las revisiones tuvieran un mínimo de sentido crítico? (no es el sentido crítico una de las cosas que nos salgan naturalmente a los humanos, de hecho, la tendencia a buscar acuerdos es un sesgo cognitivo bien descripto. Motivo para otro post, o simplemenet podría recomendar un libro).

Entonces comenzamos a hacer un checklist de cuestiones a repasar cuando revisamos una estimación. El desafío y la oportunidad de mejora siguen ahí, de modo que la lista sigue abierta (como un recordatorio, esto lo aplicamos al método de estimación por descomposición). En estos momentos,la guía para el revisor se basa en un par de aspectos generales, que explico en los puntos siguientes.


Coherencia con los objetivos y requerimientos

La estimación debe mantener coherencia con los requerimientos no funcionales y los objetivos de rendimiento (*). Por incoherencia entendemos el incluir un objetivo o requerimiento y que las tareas para alcanzarlo o cumplirlo no tengan el foco (esto es, esfuerzo) necesario o directamente brillen por su ausencia.

Las formas más comunes de estas incoherencias son:

• Mencionar en los objetivos de rendimiento que vamos a construir un producto (o un framework) a partir del proyecto, y las tareas de diseño no tienen mayor peso que de costumbre, o las tareas de documentación brillan por su ausencia.
• Hablar de objetivos de performance del producto y no incluir tiempos para tareas de pruebas de carga, ni especialistas en el asunto.
• Incluir cuestiones tecnicamente complicadas ( como por ejemplo, alta disponibilidad) y no estimar el esfuerzo adicional de diseño, y, fundamentalmente, prueba.

Por otra parte, el ciclo de vida seleccionado tiene incidencia en las estimaciones. El riesgo aquí es no estimar el esfuerzo de ciertos roles o actividades que el ciclo de vida que adoptamos incluye.


Identificación y estimación de tamaño de las tareas

Dijimos que adoptábamos un método de descomposición y no uno paramétrico como nuestro método principal porque no teníamos la suficiente madurez para un método paramétrico. Ahora, eso no implica que no podamos identificar algunos patrones de errores comunes en la identificación de tareas:

• Las tareas o componentes identificados son lo suficientemente pequeños como para que su estimación sea posible?. Como regla general, establecimos que cualquier tarea o componente que insuma más de 150 horas es sospechoso de estar pobremente especificado y comprendido (otra regla general: no hay cosas que estén mal por definición, hay luces amarillas)
• Se han identificado las oportunidades de reutilización?
• Se distingue entre lo que se debe modificar, lo que se integra y se prueba en integración y lo que se construye desde cero?

Coherencia histórica

No tenemos una historia especialmente explotable, en un sistema de datamining que nos permita descubrir patrones de esfuerzo en proyectos pasados. Bueno, pero que no tengamos el non plus ultra de los repositorios no implica que no podamos ver como nos fue en el pasado ( en algún caso, junto con algún otro galeote hemos mirado un reporte en excel decidiendo por una descripción a que componente imputar las horas de un proyecto pasado... un trabajo apasionante cuando hay cientos de componentes y miles de entradas de cargas de horas ).

Y aquí la pregunta que terminamos haciendo: si para hacer un ABM tardaste miles de horas, por qué ahora suponés que lo vamos a hacer en veinte?. Resumiendo, este paso implica buscar componentes o tareas parecidos (al menos parecidos en una primera aproximación) en proyecto anteriores y justificar la diferencia si la hubiera. No es que siempre tengamos que tardar lo mismo, pero la diferencia debe tener una buena justificación.


Evaluación de la incidencia del entorno

Este paso, al igual que todos los otros, tiende a buscar incoherencias entre lo que ha escrito y especificado sobre proyecto y su circunstancia y lo que se supone que se hará en virtud de eso. Mencionar una característica del entorno, como por ejemplo un riesgo, y que no haya ninguna característica de la estimación o del plan de proyecto que responda a ésta es wishfull thinking, es creer en la utilidad de un conjuro. Por eso, lo que hacemos aquí es recorrer cada riesgo, cada característica del entorno (capacidad del equipo, motivación, estabilidad de los requerimientos), y preguntar y esto como influyó en la estimación? como hubieses estimado si esta hubiese sido diferente?


Pasos de la estimación

Por último, el aspecto formal, aunque debería haber sido el primero. Si el único repositorio de la estimación y sus motivos está en las conexiones neuronales de un iluminado, dificilmente podrá ser sometido a revisión. Entiendo que los genios tengan esa reticencia a la revisión, pero, queridos genios, entiendan que, nada personal, nosotros los mediocres, nos vemos forzados a actuar como si la regla fuera la mediocridad y no la genialidad, como si ustedes los genios fueran raras avis. No es que dudemos de vuestra genialidad. Y así hemos logrado estructurar al mundo: aún los premios nobeles escriben sus ideas para que los demás las puedan evaluar, juzgar, corregir, ampliar y si las encuentran útiles, usarlas de base para otras ideas. Incluso, para permitir que si los demás las encuentran terriblemente revolucionarias, les den el premio nobel.

Así que acá vamos con los pasos en cuestión:

• Se han establecido, a grandes rasgos, los límites del alcance y los objetivos de rendimiento?
• Se han indentificado los riesgos?
• Se han identificado las tareas y componentes siguiendo la taxonomía que se usa habitualmente o si se la ha ampliado hubo una buena razón?

Resumiendo

Cuando uno tiene un proceso cuyos resultados no han destacado por su fiabilidad en el pasado (esos papers que hablan de cuanto se van de presupuesto y calendario tantos proyectos de software no nos hablan en tercera persona, deberíamos asumirlo ...), y no sabe muy bien como mejorarlo, lo mejor es aumentar las actividades de revisión y rezar porque la coherencia interna de un producto tenga alguna relación con su pertinencia y ajuste a la realidad.

Gran parte de lo que hicimos lo tomamos de un checklist del SEI para revisar estimaciones, como cabe esperar, bastante más formal y estructurado que el nuestro.




(*) Objetivos de rendimiento le llamamos en este barco de esclavos a aquello que se espera que nos aporte el proyecto además, claro, de su rentabilidad (la base para algún producto, conocimiento, entrar en una cuenta)

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.