Curioseando en el blog del sitio SitePoint (www.sitepoint.com/blogs) me he topado con un tópico avanzado del que se ha venido hablando desde que surgió la creación del software. En este caso, son las diez razones digamos «principales» por las cuales las estimaciones de los proyectos de software han venido fallando, y la taza de mejora registrada en los últimos años, aunque presenta avances, estos parecen desarrollarse de forma muy lenta.

En el año 1994, un estudio llevado acabo por el Grupo de Standish CHAOS Report [1], un grupo muy respetado en la industria del software y con una base de datos de 50.000 proyectos, demuestra que solo el 16,2% de los proyectos de software en empresas grandes fueron culminados con éxito, es decir, produjeron resultados aceptables que fueron entregados en tiempo y presupuesto estimado; El 52,7% fueron un «reto», es decir se sobrepasaron significativamente en tiempo y presupuesto estimado; y por último 31,1% restante no ofreció ningún resultado de valor.

Diez años mas tarde, para el 2004, un estudio más reciente ofrecido por el mismo Grupo de Standish CHAOS Report [2], reveló un 34% de proyectos culminados con éxito, un 51% de proyectos que fueron un «reto» y un 15% de proyectos que no ofrecieron valor y fallaron. Los resultados en diez años se pueden apreciar en la siguiente figura:

El análisis que arroja estos datos sugiere una mejora en cuento a mayor cantidad de proyectos con éxito (18% más), aumento de proyectos «reto» en un 2% y una significativa reducción en proyectos totalmente errados y de poco valor (16% menos). Sin duda alguna, hemos aprendido de nuestros errores pasados y esto se ha reflejado en los resultados, aunque con un progreso significativamente lento.Las causas detalladas de todas estas situaciones se pueden leer sin desperdicio alguno en los excelentes trabajos [1] y [2] del Grupo Standish.

Volviendo a la idea inicial, veamos cuales son las diez razones que nos exponen en SitePoint:

1 – DEFINICIÓN MALA Y POBRE DEL ALCANCE:

El principal planteamiento en este punto estriba en: ¿Cómo podemos estimar el tiempo de un proyecto cuando no conocemos en que consiste completamente?. Es muy raro encontrarnos con un cliente que sabe exactamente de inicio a fin que es lo que quiere exactamente que el sistema realize. En la mayoría de los grandes proyectos se ha intentado negociar como requisito «la flexibilidad». Los clientes tienen como exigencia la flexibilidad para incorporar en el futuro características que ni siquiera ellos conocen aún. Por tanto, ¡la flexibilidad no debería ser un requisito!

2 – LOS TIEMPOS DE DESARROLLO NO LO ESTIMAN LOS DESARROLLADORES

Existe una fuerte tendencia por parte de los administradores de proyecto de estimar por su cuenta las actividades de desarrollo, de las cuales no tienen control ni conocimiento. Esto es un claro error. Las estimaciones se deben realizar conducidas por el equipo de trabajo en su totalidad.

3 – ESTIMACIONES DEMASIADAS OPTIMISTAS POR PARTE DE LOS DESARROLLADORES

Muchos de los desarrolladores piensan en términos de codificación de horas, sin embargo el tiempo en realidad pasa volando, y es muy difícil obtener promedios en base a nuestra propia velocidad y ritmo de trabajo. Otro error muy común es considerar las horas de desarrollo de otros equipos, cada equipo es único y tiene su propia velocidad.

Muchos desarrolladores además son demasiado optimistas, se tiende a generar planes basados en escenarios de total éxito, dejando de considerar problemas por ausencias, fallos técnicos de software y hardware, gestión del proyecto, gestión de requisitos, debates y discusiones, etc.. etc.

4 – PROYECTO INCORRECTAMENTE SEGMENTADO

Hay que tener mucho cuidado con la estructura detallada de trabajo seleccionada para enfrentar las complejidades del proyecto. Independientemente de los artefactos seleccionados, de acuerdo a la metodología seleccionada (bien sea historias de usuario o casos de uso) , estas deben tener un tamaño acorde, del mas grano fino posible, de manera que el desarrollador pueda tratarla de manera mas realista. Un error común es tratar con elementos de más de una semana de duración que resultan más complejos de estimar.

5 – EL SÍNDROME DEL ESTUDIANTE

Muchos de nosotros, durante nuestros períodos de estudio podemos recordar facilmente este síndrome. Cuando se nos asigna una tarea para entregar en una semana que en realidad puede cumplirse en dos días, la mayoría de las personas terminamos la tarea en exactamente una semana y casi a destiempo. Esto es lo que exactamente sucede en los proyectos de software, cuando se realizan sobre-estimaciones de las actividades y se terminan antes, en realidad no es tiempo ganado para el proyecto, por lo general los desarrolladores se quedan el tiempo que falta acomodando cosas, o en el peor de los casos se va dejando las actividades para después por tener espacio holgado de tiempo y se terminan realizando a última hora.

6 – EL MITO DE MÁS DESARROLLADORES ES IGUAL A DESARROLLO MÁS RÁPIDO

Por lo general, se tiende a pensar que aumentado el número de desarrolladores para realizar un proyecto, se consigue realizarlo de forma más rápida. Esto es Falso, a medida que se aumenta el grupo de desarrollo se aumenta exponencialmente la complejidad. Así, tanto como 9 mujeres no pueden tener un hijo en un mes; Un proyecto de 100 días, no se completará en 1 día por 1oo desarrolladores. Existe un muy buen artículo en SitePoint explicando esto (Why Larger Teams Do Not Result in Faster Development…).

7 – EL ALCANCE DEL PROYECTO CAMBIA

Este es quizás, uno de los problemas que mas molesta a los desarrolladores. Debido a la naturaleza de los negocios, los proyectos se ven envueltos en constantes cambios de funcionalidades y características de negocio; o bien son cambios de alcance muchas veces por capricho de los directores funcionales, la pregunta acá es: ¿Es documentado el impacto del cambio en el sistema?.

8 – LAS ESTIMACIONES NO SON ACTUALIZADAS

Las estimaciones deben ser constantemente evaluadas y actualizadas a medida que el proyecto avanza. Muchos desarrolladores consideran que se puede recuperar el tiempo perdido, cosa que rara vez sucede.

9 – LAS PRUEBAS DEL CÓDIGO SON OLVIDADAS

Resulta bastante difícil que un desarrollador pruebe su código. A medida que se desarrolla la aplicación y se dejan las pruebas para después, los desarrolladores tienden a realizarlas de forma viciada, traicionados por sus subconscientes. Existen marcos como TDD(Test Driven Development) que aportan significativas ayudas a este problema. Las pruebas de funcionalidades de negocio complejas, deberían escribirse antes que el código.

10 – LAS ESTIMACIONES SE TOMAN MUY LITERALMENTE

A menudo los administradores de proyectos tienden a tomar literalmente las estimaciones de los desarrolladores, sin evaluar contratiempos y riesgos. Cuando una actividad no se cumple en el tiempo que un desarrollador estimó los administradores tienden a culparlos y adjudicarles la culpa de la situación, generando inconvenientes graves de cara al futuro, donde los desarrolladores comienzan a realizar estimaciones exageradas para «cuidarse las espaldas» afectando gravemente el avance y calendario del proyecto.

ANÁLISIS

Estas son las diez razones que exponen en SitePoint, aunque seguramente hay muchas más. Todas estas razones del fallo de las estimaciones se vienen denunciando desde hace mucho tiempo y en general como se vio anteriormente en los resultados a diez años del Grupo Standish CHAOS, no se han dado mejoras significativas en tiempo rápido. Con el auge de la filosofía ágil, sin duda mucho de estos problemas enunciados parecen tener solución(Véase http://agilemanifesto.org/), sin embargo, es importante destacar que las metodologías ágiles no son válidas para abordar todos los proyectos de software existentes.

Uno de los principales problemas en este tópico, bajo mi humilde opinión es que quizá tanto el equipo del proyecto como los clientes no tienen claro el concepto de ESTIMACIÓN. Las estimaciones y las predicciones no se tratan de adivinar un futuro incierto, tienen un caracter más humilde: Reducir la incertidumbre. Bajo esta premisa cuando ambas partes de los proyectos tenga esto en claro, se lograrán mejores resultados en un ambiente de negocios veloz, donde lo que hoy es verdad, mañana pudiera dejar de serlo.

Quizá, como explica Martin Flower en [3], el verdadero problema estriba en que las técnicas de estimación predictivas sólo funcionan con problemas predictivos, predecibles, deterministas. ¿Son todos los problemas de softwares predictivos? La respuesta seguramente en un rotundo NO. Existe una gama de proyectos adaptativos que pueden ser manejados con filosofías ágiles. Para finalizar, existe un artículo muy interesante donde se demuestra matemáticamente que no es posible predecir la duración de los proyectos de Software, de forma objetiva y a priori (descargar artículo).

En los próximos POST de este blog, seguiremos ampliando y discutiendo estos interesantes temas.