Una técnica de estimación de proyectos basada en Casos de Uso

Si bien el movimiento ágil (tan de moda últimamente) dice claramente que no se debe ni puede estimar un proyecto completo al momento de iniciarlo y que cualquier técnica que intente hacerlo va a terminar mal; no son pocas las veces que se necesita conocer de ante mano la duración estimada del mismo. Hay que tener muy en claro que esta estimación suele ser de mínima (el proyecto no va a tardar nunca menos de esto) pero la duración real puede incrementarse mucho; a menos que sean sumamente estrictos y acotarse a hacer únicamente lo que se escribió dentro de los casos de uso utilizados en la estimación.

A partir de un mail, donde alguien preguntaba como estimar un proyecto; se me ocurrió postear una forma a mi me da resultados aceptables. No tiene conceptos teóricos, es una solución netamente empírica que a mí me funciona (si utiliza algunos conceptos teóricos “blandos”, pero nada más). Algunas ideas están tomadas prestadas del libro “Software Estimation” de Steve McConnell (muy recomendado).

Disclaimer: Desde ya que la estimación y planificación de proyectos es una tarea muy compleja y única. Cada proyecto tiene sus detalles, sus compromisos, sus equipos, tiempos, costos, etc. Cada proyecto es un mundo y como tal, esta técnica que yo utilizo debe ajustarse y modificarse con criterio (y hasta puede no servir). Sea cual sea la técnica final a utilizar, siempre tener cuenta de no cometer errores conocidos.

Terminada ya la introducción pertinente al tema, les comento la técnica:

El Remero que podria ser programador

En 1994 se celebro una competición de remo entre dos equipos:

• Uno compuesto por trabajadores de una reconocida empresa argentina
• El otro por sus colegas de una similar japonesa.

Apenas fue dada la orden de partida, los remeros japoneses comenzaron a destacarse. Llegaron a la meta prontamente. El equipo argentino lo hizo una hora después. De regreso a nuestro país, la Dirección se reunió para analizar las causas del desconcertante e imprevisto resultado. Se llego a esta conclusión: En el equipo japonés había un jefe de equipo y diez remeros, mientras que en el argentino había un remero y diez jefes de equipo.

La soja del software en la Argentina

Hace rato que le vengo dando vueltas al tema, pensando y pensando sobre la situación actual y perspectivas del mercado laboral. Han pasado varias etapas (al menos yo he pasado), momentos de poco trabajo, no existían las “punto com” e internet era algo impensado. Luego, de a poco el sector fue creciendo, se fue ubicando, fue ganando su lugar hasta llegar hasta lo que es hoy; un mercado muy dinámico, de alta rotación, buenos sueldos (en general) y baja calidad profesional (también en general). De a poco nos estamos convirtiendo en un mercado orientado a testers y no a ingenieros.