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:

Estimando con Planning Poker

Planning Poker

Estimar es la tarea más difícil del proceso de desarrollo. Nunca se tiene menos información que al momento de estimar y por otro lado, las decisiones tomadas marcan el futuro del proyecto. Si bien todos sabemos que son estimaciones, usualmente estos números (generados a partir de no conocer el problema) llegan al cliente y vuelven al equipo de desarrollo en forma de deadlines estrictos e inquebrantables. Hace poco, leyendo más que nada sobre la metodología SCRUM, me encontré con un método de estimación llamado “Planning Poker” que parece muy prometedor.

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.

Etapas de un proyecto

1. Optimismo inicial
2. Fase de desorientación
3. Desconcierto generalizado
4. Período de desorden incontrolable
5. Búsqueda implacable de culpables
6. Sálvese el que pueda
7. Castigo ejemplar a los inocentes
8. Recuperación del optimismo perdido
9. Finalización inexplicable del proyecto
10. Condecoraciones y premios a los no participantes