Estimando Proyectos

Desdel el blog de Ervin Sarkisov encuentro esta entrada la cual puede ser de mucha utilidad para empresas de desarrollo y en especial para aquellas áreas que hacen la estimación de un proyecto, ya que esta es una de las partes mas dificiles dentro de la ingeniería de software ya que a diferencia de otras industrias donde los productos o servicios son mas tangibles el desarrollo de software se torna dificultoso la estimacion dadas las características de este tipo de proyectos.

Defining IT Projects

En RNQ se pública un estudio de Scott Ambler acerca de lo que es el éxito del proyecto el cual resulta interesante porque a decir del autor no coincide con lo que Standish Group da como definición, y en este aspecto dare mi opinión considero que el éxito del proyecto se puede ver desde varios enfoques en específico 2 desde el punto de vista del cliente y desde el punto de vista de la empresa que desarrolla el proyecto (hablando de proyectos de TI). Hay clientes que por ejemplo el tiempo no es tanto problema (claro esta con un margen razonable de desvío) con tal de que se entregue lo pactado en funcionalidades y costo, esto quiere decir que los retrasos los absorverá la empresa que desarrolla pero para esta  es vital que el proyecto se termine en el tiempo establecido por que sino se corre el riesgo de perder rentabilidad en el proyecto.

Los problemas de la estimación

Sin duda alguna basandome en la experiencia una de las actividades mas dificiles es la estimación, esto por muchos factores, sin embargo nombrare los mas importantes recalcando que es en base a mi experiencia:

Estimar en base al desarrollador estrella, muchas veces se obvia que si una funcionalidad de ciertas características las realiza el mejor desarrollador en cierto tiempo todos los desarrolladores tambien la desarrollarían en el mismo tiempo.

No tener un registro de tiempos, Si se tuviera un registro de tiempos se estimaría con mayor exactitud el PSP (Personal Software Process)no miente en ese aspecto y yo lo he constatado.

Siempre inventar el hilo negro, Hay que reusar, si en un proyecto se presenta una situación que previamente se soluciono en otro proyecto lo ideal sería reutilizar clases, componentes etc. pero sino al menos tener una BD de lecciones aprendidas para saber como se soluciono y no se pierda el tiempo en investigacion.

Estimar sin tener bien definidos los requerimientos, se que esto es imposible pero hay que tener lo mas completo posibles los requerimientos.

No tener una metodologia para medir, sugiero puntos de función

 

Encontrarán mas información en el siguiente post.

Planix - Estimar el esfuerzo necesario para un proyecto

Desde el blog whats new leo acerca de esta herramienta Planix para estimar el esfuerzo necesario para un proyecto, no la he probada pero parece muy interesante.

Use Case point...la historia continua...

En Tyner blain estan dispuestos a dar todo un curso de Estimación de Software a través de Use Case Points, aqui la continuaión de esta historia, Use Case Analysis.

Introducción a la estimación de software con Use Case Point

Aunque introductorio este es un buen artículo publicado en Tyner Blain, de estimación de Software con Use Case Point la cual es una metodología que esta teniendo mucho auge dentro del área de estimación de software.

COCOMO y PMBOOK

Excelente entrada desde LegnitaPress Aclarando conceptos de la cual resalto los vínculos de

La guía práctica del PMBook y

20th International Forum on COCOMO