Estimación - El bello arte de estimar el software

El bello arte de estimar el software

Pocos proyectos tan difíciles de estimar como los proyectos de software. ¿Por que?. Porque contrario a lo que muchos creen, la construcción del software es un arte y por lo tanto no puede concebirse una fabrica que automatice su construcción. La construcción de un producto de software es un reflejo directo del conocimiento de quien construye. Dos personas pueden llegar a un mismo resultado con diseños totalmente diferentes con el agravante de que ambos pueden considerarse buenos diseños en contextos diferentes. Entonces. ¿Como ser certeros en las estimaciones que entregamos?.

la respuesta es muy simple. NO SE PUEDE SER CERTERO. Es absolutamente imposible. Es mas, las certeza va en contra de la definición de estimación "Aprecio y valor que se da y en que se tasa y considera algo. RAE". Máximo podríamos llegar a un valor aproximado que permita calcular la fecha de finalización del proyecto. Pero mas allá no tiene sentido. ¿Y como lograr esa aproximación?

Lo mas importante a la hora de estimar radica en entender lo que debemos lograr y que debemos hacer para lograrlo. 

A continuación describo una serie de actividades que suelo realizar cada vez que debo estimar. No son nada del otro mundo, incluso pueden verse como tareas derivadas de la aplicación del sentido común (El menos común de los sentidos).

El proceso se puede dividir en 4 fases.:Entender la necesidad, entender como vamos a satisfacer la necesidad, identificar las actividades que se requiere ejecutar para lograr el objetivo y estimar cuanto tiempo tardaremos para lograrlo.

ENTENDER QUE ES LO QUE SE NECESITA

• Entender el contexto de la necesidad: Se sugiere leer toda la documentación sin preocuparse por conocer cada aspecto de forma detallada, el contexto es suficiente para orientar la forma como se solucionarán las inquietudes.

• Break: Dependiendo del tamaño y cantidad de in formación que deba revisar para entender el contexto, es preferible se tome un descanso y preferiblemente cambie de actividad. Esto le permitirá cuando retome el tema tener la mente mucho mas despejada.

• Estructurar los objetivos, necesidades y requerimientos: La documentación que recibimos normalmente viene dispersa o agrupada por diferentes temas que no tienen sentido para nosotros. Ordenarla y estructurarla será la base para entender en detalle lo que nos solicitan.

Figura 1. Objetivos, necesidades, y requerimientos estructurados

Es importante durante la estructuración, escribir todas las inquietudes que tengamos sobre la definición, de modo que podamos reunirnos con el experto para aclararlas.

Durante esta actividad podríamos empezar a identificar ciertas tareas que deben realizarse y que servirán como insumo a la estimación. Aunque el siguiente paso será precisamente el de identificarlas, se puede hacer a lo largo del ejercicio de modo que no sean olvidadas.

• Reunión con el usuario: Es importante tener una reunión con la persona que tiene la necesidad que estamos analizando. Se sugiere que el experto empiece contando una visión global de lo que requiere y las razones por las que lo solicita. Esto permitirá aclarar mas el contexto. Luego se puede entrar en el detalle y empezar a discutir puntualmente las inquietudes descubiertas en el paso anterior.

ENTENDER COMO VAMOS A LOGRAR LO QUE NOS SOLICITAN.

• Realizar un diseño conceptual: Es imposible estimar si no tenemos una idea medianamente clara de como vamos a lograr lo que nos están pidiendo. El éxito de este paso depende de la experiencia que tengamos solucionando problemáticas o necesidades similares. Si nos piden construir una carretera, probablemente un zootecnista no sea la persona mas adecuada para hacer un diseño de la forma como se va a construir. En el mundo del software es muy conveniente cubrir este paso con un diseño de arquitectura, teniendo en cuenta los drivers arquitectónicos (Restricciones técnicas, de negocio, atributos de calidad, necesidades funcionales) que estén disponibles al momento de su realización. El nivel de detalle que se logre dependerá del grado de incertidumbre y del nivel de riesgo que se está dispuesto a asumir.

Diseño

IDENTIFICAR QUE ACTIVIDADES DEBEMOS EJECUTAR PARA HACERLO POSIBLE.

• Construir el WBS o EDT (Work Break Down Structure o Estructura de Desglose de Trabajo): Se puede tomar como insumo el artefacto descrito en la figura 1. La idea es que sea estructurado de manera realista teniendo en cuenta la información entregada por el usuario en la reunión. 

El objetivo de realizar el WBS es principalmente identificar las actividades que deben realizarse para completar el producto, por esta razón es importante equilibrar el nivel de detalle al que se quiere llegar y esto depende de dos aspectos principalmente: El nivel de confianza que se requiere de la estimación y el tiempo disponible para realizarla. 

Si realizamos un desglose muy detallado, es posible que logremos un nivel de confianza mayor (Aunque esto hará que se extienda mucho el tiempo de planeación y aún así lo mas probable es que se realicen asunciones que en el transcurso del proyecto se desvirtúen e invaliden la estimación.), pero también es posible que sobre estimemos (Podríamos desglosar actividades muy pequeñas que realmente requieren menos tiempo del planteado). 

Si realizamos un desglose de muy alto nivel lo mas probable es que subestimemos (Podríamos perder de vista actividades importantes que harán que el esfuerzo requerido sea mayor).

Siempre es importante tener en cuenta el grado de incertidumbre con el que se debe convivir en el momento de la estimación (Conforme avanza el tiempo esta se va reduciendo hasta llegar a 0 en el momento de la entrega del producto). Este será el factor que nos permitirá determinar que tanto esfuerzo invertir en el desglose. A mayor grado de incertidumbre, menor debe ser el esfuerzo invertido.

Figura 2. Cono de la incertidumbre

• Retroalimentar el WBS con lecciones aprendidas: Es importante revisar algún repositorio en el que se encuentren tareas que son repetitivas en todos los proyectos tales como planeación, aseguramiento de la calidad, arquitectura de software, gestión del proyecto (Reuniones de seguimiento, gestión de riesgos, gestión de la calidad, control, cierre), despliegues, pruebas o actividades que hace el cliente en cada entrega y que puedan afectar la fecha de finalización del proyecto. Todo esto con el fin de no perderles de vista y tener en cuenta el esfuerzo que requieren en la estimación. Este repositorio debería actualizarse constantemente cada vez que se cierren los proyectos con el fin de aprender de experiencias previas.

ESTIMAR CUANTO TIEMPO TARDAREMOS PARA LOGRARLO.

Solo resta colocar un número. Esta es la tarea mas sencilla de todas ¿Por que?. Porque cualquier número que se coloque será solo una percepción aún si viene de un repositorio de datos históricos, o si lo estimó mas grande sabio del planeta. Una percepción que jamás será acertada.

Es muy recomendable en este punto diferenciar estos tres términos: Tamaño, Esfuerzo, Tiempo. 

El tamaño como su nombre lo indica pretende dimensionar que tan grande es el software que vamos a construir. Se puede dar en las siguientes medidas: Function points, Story points, o cualquier otra unidad que quiera utilizar. Lo realmente importante es que el valor obtenido tenga algún significado para usted. 

El esfuerzo dependerá de quien ejecute las tareas. Una persona puede tardar 4 Horas realizando un CRUD a una tabla de una base de datos, mientras que otra menos experimentada tardará 8 Horas. El esfuerzo es la cantidad de horas que una persona invierte para completar una unidad de tamaño. SCRUM por ejemplo traslada el esfuerzo al Sprint. ¿Cuantos puntos de historia podemos completar en este Sprint?, las metodologías tradicionales asignan el esfuerzo a la tarea misma.

Los valores de tamaño y esfuerzo podrían ser obtenidos a través de ciertas técnicas:: Function points, Planning poker, Deal and Slide, Mark II function points, analogía, Wideband delphi, entre otras. Ninguna ofrecerá un valor mas acertado que la otra pues al final en cualquier caso se terminará usando Juicio Experto dado que los valores que reciben como insumo estas técnicas serán subjetivos.

Otra alternativa es utilizar datos históricos pero esto tampoco le dará mas precisión a la estimación. Es mas. Una simple suma puede ser mas efectiva que la aplicación de una gran formula matemática muy compleja. En cualquier caso seguirá siendo una estimación.

El tiempo dependerá de otros factores como los días festivos, las vacaciones, la cantidad de personas involucradas en la realización de una tarea, etc. En estos casos es útil utilizar técnicas como la ruta crítica, o Gantt para tomar en consideración estos factores.

Recomendaciones:

• No utilizar la unidad de medida Horas en todos los casos. A mayor incertidumbre mayor debe ser la unidad de tiempo utilizada. Por ejemplo. En etapa comercial la unidad mínima de medida deben ser meses, semanas o días  A medida que reduce la incertidumbre puede reducir la unidad de media usada pero mínimo debe darse en Horas. Los minutos o medias Horas dan una falsa sensación de precisión. Si una funcionalidad es tan pequeña que no se demora al menos una hora, entonces agrúpela con otras tareas que pueden realizarse en esa unidad de tiempo.

• Utilice la analogía: Es muy útil siempre comparar actividades que se han llevado a cabo de forma similar en otros proyectos para comparar la estimación. Esto permitirá identificar trabajo adicional o ciertos riesgos para los cuales debe realizarse reservas de gestión. Por ejemplo. Si se está estimando la integración con un sistema externo y previamente otros proyectos lo hicieron, revise que pasó y cuanto tardaron realmente.

Conclusión: Es mejor ser fiel al Décimo primer mandamiento "No estimarás"