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)