_________________________________

Copyright© 2007-2010 TenStep Latinoamérica S.A. de C.V. Todos los derechos reservados.

 Hay clases de 5 días que se enfocan en enseñar a la gente buenas técnicas de estimación. Algunas de éstas técnicas se basan en estadística avanzada y fórmulas científicas, las cuales están muy lejos del alcance del Proceso TenStep. Muchas de las técnicas de estimación básicas son más familiares y fáciles de entender.

Las siguientes técnicas pueden ser usadas en el ámbito de proyecto o de actividad o bien para cualquier paquete de trabajo entre ambos. Por ejemplo, la opinión de un experto puede ser usada para ayudar a guiar las estimaciones de un proyecto completo o de solo una porción del trabajo.

Las estimaciones de alto nivel típicamente se conocen como técnicas descendentes (de arriba hacia abajo). Las técnicas descendentes incluyen información histórica, analogía y proporción.  En general las estimaciones que confían más en la división del trabajo detallada son conocidas como ascendentes (o de abajo hacia arriba). Por ejemplo el WBS es una técnica descendente.

Las técnicas descendentes son típicamente más rápidas y fáciles de integrar ya que estamos estimando a nivel de todo el proyecto. También resultan menos precisas, con excepción de las estimaciones que se basan en información histórica o bien en la analogía de proyectos similares. De ser posible, se deben usar diversas técnicas de estimación para un proyecto, específicamente si se está confiando en un rápido estimado de alto nivel (de arriba hacia abajo).

• Registros Históricos: Esta es por mucho, la mejor forma de estimar el trabajo. Si la organización guarda el registro de las horas reales de esfuerzo de proyectos anteriores, se puede tener información que ayudará a estimar el trabajo por venir. En este método, las características del trabajo previo, así como las horas reales de esfuerzo son almacenadas en una hoja de cálculo, base de datos, o cualquier otro método que pueda ser usado para búsquedas de futuros proyectos. La persona que está encargada de realizar la estimación, para averiguar si anteriormente se ha hecho trabajo similar. Si así ha sido, se tendrá una buena idea del esfuerzo requerido para concluir el proyecto.

Analogía: Aun cuando no se guarden registros reales de las horas de esfuerzo de proyectos anteriores, aun es posible apalancar la experiencia previa. Analogía se refiere a la búsqueda de proyectos similares aún cuando el equipo del proyecto no haya acumulado horas de esfuerzo reales trabajadas. El gerente de proyecto anterior debió al menos haber tenido un estimado original del esfuerzo y duración. Aunque él no haya dado seguimiento al esfuerzo real, debe de saber cuál fue la duración real de cada tarea. Si la duración actual fue igual a la estimada, se puede asumir que las horas de esfuerzo fueron muy aproximadas también. Por otra parte, si el proyecto concluyó con un 20% por arriba de la duración estimada, se puede asumir que las horas de esfuerzo requeridas también fueron un 20% adicional. Por ejemplo, si un proyecto anterior fue estimado para durar seis meses, hay una gran probabilidad de que proyecto también requiera de aproximadamente 2,000 horas de esfuerzo.  Por otra parte, si el equipo de trabajo del proyecto estaba totalmente integrado y el proyecto tomó siete meses para ser concluido, entonces se puede estimar que el proyecto tomó alrededor de 2,300 horas para concluir.

Esta es probablemente la técnica más común para estimar el trabajo. Usted estima el trabajo futuro basado en su conocimiento de haber hecho un trabajo similar en el pasado.

• Proporción: Esta técnica es similar a la anterior, excepto porque se tienen algunas bases para comparar trabajo que tenga características similares, aunque en una escala mayor o menor. Por ejemplo, se puede descubrir que el esfuerzo requerido para terminar una auditoría financiera en una oficina determinada es de 500 horas y una de las directrices principales es el número de personas que se ubican en las localidades remotas. Si se tiene una oficina con el doble de gente que la anterior, entonces se puede inferir que esta actividad tomará el doble de horas de esfuerzo, es decir 1000 horas.
• Juicio Experto: En muchos casos, se puede recurrir a un experto interno o externo para solicitar ayuda en la estimación del trabajo. Por ejemplo, si esta es la primera vez que se usa nueva tecnología, se puede necesitar la ayuda de una firma externa de investigación para que proporcione información de estimaciones. Muchas veces, estas estimaciones están basadas en las experiencias de otras empresas en la industria. Quizás exista un experto interno que pueda ayudar. Aunque esta puede ser la primera vez que se está estimando este tipo de trabajo, quizás alguien más ya lo ha hecho muchas veces.
  • Técnica Delphi: Esta técnica es similar al Juicio Experto, excepto que se usan múltiples expertos para tratar de alcanzar un consenso acerca de la estimación del trabajo. Primero es necesario identificar quien debe ser considerado como experto en el tipo de trabajo que se requiere estimar. Después, se debe enviar a los participantes la información relevante y que sea necesaria para entender el trabajo. A vuelta de esta información, deberán enviar su estimación del esfuerzo, así como cualquier suposición, riesgos, etc. que hayan identificado.

Si el número resultante de cada experto está relativamente cercano, se puede usar un promedio de las respuestas como estimación final sin mayor problema. Si éste no es el caso, se deben regresar las estimaciones y toda la información asociada para que sea revisada. Se debe pedir a los expertos que consideren la información proporcionada por sus colegas. Entonces se debe solicitar a cada participante que proporcione una segunda estimación del trabajo. Con suerte, ahora se tendrán varias estimaciones muy cercanas dado que los expertos han tenido oportunidad de dar un vistazo al trabajo de sus colegas. Con base en un conjunto de suposiciones y riesgos, los expertos deberían llegar a un consenso en cuanto a la estimación. En caso contrario, se debe validar si los expertos tienen números similares y se debe usar esa estimación. También se debe tomar en consideración un factor de riesgo derivado de las observaciones de aquellos expertos que no pudieron llegar a consenso. Por ejemplo, si tres expertos estiman el trabajo alrededor de 1000 horas, pero uno de ellos sostiene la creencia de que el esfuerzo es de 2000 horas, se tiene que ir con el consenso de 1000 horas, asentando un riesgo de que el esfuerzo puede incrementarse hasta por el doble del monto estimado, basándose en la opinión de al menos un experto.

Una segunda opción, si se tiene el tiempo y la inclinación es solicitar la opinión de más de un experto. Si la estimación del nuevo experto es cercana al número consensuado proporcionaría mayor confianza, mientras que por el contrario generaría menos confianza (y mayor riesgo) si la nueva estimación no está cercana al número consensuado.

Los escenarios que se acaban de describir son ejemplos de lo que puede suceder cuando solicitamos a varios expertos su opinión. La Técnica Delphi utiliza múltiples expertos y entonces proporciona orientación de cómo darle sentido a las estimaciones si los expertos no están de acuerdo.

• Estructura de Desglose del Trabajo: Una de las razones para hacer esto es tener la capacidad de estimar el trabajo con mayor facilidad. Se puede observar un gran paquete de trabajo y encontrar dificultades para estimar el esfuerzo requerido. Sin embargo, en la medida en que el trabajo se descomponen en piezas menores, los componentes serán más fáciles de estimar. Cuando se han estimado cada uno de los paquetes de trabajo, simplemente hay que integrarlos de modo que se pueda conocer el esfuerzo general. Si se tiene tiempo para crear un buen WBS, es muy probable que al final se tenga una buena estimación de todo el esfuerzo requerido. Debemos tratar de usar la técnica WBS en el proyecto si es posible.
• PERT (Técnica de revisión y evaluación de programa, por sus siglas en inglés): El término PERT se usa muy comúnmente para referirse a diagramas de red. Sin embargo, en realidad se trata del nombre de una técnica de estimación formal, que usa el promedio ponderado de tres activos para obtener la estimación final. Usando la técnica PERT, si alguien nos solicita la estimación de un proyecto o actividad, iniciamos con tres estimaciones — el caso más pesimista (P), en donde todo sale mal; la situación optimista (O) en la que todo sale bien y, la situación más probable (M) en la que se presentan situaciones a favor y problemas normales. La estimación resultante usando PERT se calcula con la fórmula (O + 4(M) + P)/6. Por ejemplo, digamos que se estima un paquete de trabajo en donde (M) es igual a 10 horas, el mejor caso (O) es igual a 6. El caso pesimista (P) se estima en 26 horas. El cálculo de la estimación usando PERT sería: (6+4(10)+26)/6, la respuesta es 72/6 o 12 horas. Debe notarse que el resultado está un poco sesgado hacia el lado pesimista, aunque no mucho debido a que el resultado contempla la ponderación de activos hacia el caso más probable.
• Modelado Paramétrico: En esta técnica, existe un patrón en el trabajo, que permite usar un algoritmo para dirigir la estimación general. Por ejemplo, si se puede estimar el costo de un kilómetro lineal para una carretera, se podrá estimar fácilmente el costo de 10 kilómetros. O si se solicita crear 40 reportes, primero se puede estimar el esfuerzo asociado a un reporte promedio (quizás el promedio de un reporte pequeño, mediano y grande). Entonces multiplicando el esfuerzo promedio por 40 reportes se tendrá la estimación final.
  • Técnica Caja de tiempo. Con esta técnica establecemos una de las estimaciones dentro de un parámetro determinado. Esto puede llevarse a cabo enfocándonos en uno o dos de los otros aspectos de la “restricción triple”. Normalmente, cuando aplicamos la técnica de caja de tiempo estamos forzando el proyecto para que se concluya en una fecha compromiso determinada. Entonces nos enfocamos en el costo y alcance de aspectos de la restricción triple de manera que la fecha de caja de tiempo pueda ser cumplida.

Por ejemplo, supongamos que creamos un cronograma que muestra la forma en que vamos a completar el proyecto en nueve meses. Sin embargo, el patrocinador nos indica que el proyecto debe ser completado en siete meses. La fecha compromiso de siete meses se convierte en nuestra “caja de tiempo” dentro de la cual el proyecto debe ser completado. Para cumplir con esa fecha vamos a tener que aplicar recursos más rápido de lo anticipado. Puede que también necesitemos más recursos de manera que algunas actividades se programan para ser completadas de manera secuencial para que entonces puedan ser programadas y completadas de manera paralela. Estos son ejemplos de situaciones que nos pueden elevar el costo del proyecto. Si no podemos gastar suficiente dinero para alcanzar la fecha límite, vamos a tener que eliminar algo de trabajo (alcance). Podemos aumentar costos, disminuir el alcance o quizás una combinación de ambos para cumplir con las fechas.

• Puntos de función: Algunas organizaciones de desarrollo de Tecnologías de la Información usan los puntos de función como un medio para tener estimaciones que tengan sustento respecto al trabajo requerido para llevar a cabo un proyecto de desarrollo de sistemas.  Los puntos de función son un mecanismo para determinar la complejidad relativa de una aplicación. La complejidad puede ser expresada como un conteo de los puntos de función. De esta manera, una aplicación de 1,000 puntos de función es generalmente 10 veces más grande y más compleja, que una más compleja de 100 puntos.

Sin entrar en mucho detalle, los puntos de función toman el tamaño de una aplicación desde la perspectiva del usuario. Los usuarios ven reportes, pantallas, quizás archivos de datos. También ven funcionalidad del negocio, interfaces con otras aplicaciones, bases de datos, tablas, etc. Tiene sentido que una aplicación con 80 pantallas y 20 reportes sea probablemente más grande que una con 20 pantallas y 5 reportes. Esta manera de mirar el tamaño es independiente de la tecnología y el lenguaje de programación subyacente. De hecho, la aplicación con menor número de pantallas puede requerir más líneas de código, pero eso no es relevante para los cálculos de tamaño de la aplicación.

No se puede llevar a cabo la estimación con puntos de función de manera anticipada en el proceso de planificación. Sin embargo, una vez que se conozca el número de pantallas, reportes, archivos de interface, transacciones, etcétera; se puede crear una estimación de alto nivel de los puntos de función totales. Una vez que se han contado los puntos de función para algunos proyectos, se podrá ver el esfuerzo promedio requerido para realizar un punto de función. Después de eso, es solo una cuestión matemática el determinar el esfuerzo total necesario, seguido de la duración y el costo.

_________________________________________________________________________ 

© Todos los derechos reservados, TenStep Latinoamérica S.A. de C.V.

Comentarios

comentarios