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 tardarnunca 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ónnetamente 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:

1.
Identificar la lista de casos de uso (si el cliente no proporciona la lista;hay que armarla mediante un análisis inicial, cualquier cosa por fuera de esa lista va a mover los tiempos estimados).
2.
Clasificarlos en tres grandes grupos: fáciles, medianos y difíciles. (Algunos usan chicos, medianos y grandes; es similar siempre y cuando se categorice cuanto esfuerzo implica implementarlos). Para saber cual es chico, cual no, etc., lo que se suele hacer esagarrar un caso de uso conocido en tiempo (por ejemplo un ABM; que probablemente sepa cuanto me lleva hacer) y tomarlo como patrón. Los más fáciles que ese son fáciles, los más difíciles son difíciles y todos los otros medianos.
3.
Agarrar uno o dos representativos de cada grupo (si son muchos tal vez convenga tomar más cantidad) y analizarlo en bastante detalle.
4.
Con el caso deuso escrito, reunir a dos o tres desarrolladores (los que mejor estimen o sean expertos en el negocio o tecnología) y pedirles que estimen el esfuerzo de implementar estos casos de uso. Para estimar un sólo caso de uso se puede utilizar Planning Póker o cualquier otro mecanismo ágil (desde ya utilizando horas y no puntos de complejidad ya que se necesita obtener el esfuerzo). Siempre se debeademás, ajustar la estimación de tareas con información histórica (por ejemplo: me dio 1 día en hacer un ABM, pero en el proyecto anterior tardábamos 3 días por ABM; analizar por qué y de ser necesario modificar la estimación original)

5.
Multiplicar este esfuerzo (en horas) por la cantidad de casos de uso de cada grupo.
6.
Este número final, es el esfuerzo en horas del proyecto(sin decir nada por supuesto de la duración estimada del mismo dentro de un calendario). Con este número debemos:
1. Estimar armado inicial de ambientes. Todo lo que debe hacerse antes de poder comenzar el proyecto. Esta tarea (o grupo de tareas) las realiza en general una sola persona y suele ser similar el tiempo de start-up en todos los proyectos de una misma compañía.
2.Estimar la sobrecarga de proyecto (reuniones, demos, entregas, etc.). Yo suelo considerar entre 1 y 2 días equipo al inicio de cada iteración y luego las reuniones pactadas con el cliente.
3. Estimar el esfuerzo de análisis detallado de los casos de uso: Ya se tiene la información de cuanto se tardo en detallar los 3 que se usaron en la estimación. Con esta información se pueden estimar...