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:

  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 es agarrar 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 de uso 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 debe ademá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 los demás.
    4. Estimar esfuerzo para QA: En general siempre me ha quedado un porcentaje entre el 10-20%. El armado de los casos de prueba va en paralelo con el proyecto por lo que no suele ser necesario estimar cuando demora en esta etapa.
    5. Estimar el esfuerzo para el armado de documentación extra: Como ser diagramas o documentos de arquitectura, manual de usuario, etc.
    6. Dependiendo los riesgo del proyecto (por ej.: se comunica con sistemas externos, es tecnología, etc.) le suelo agregar un porcentaje extra que principalmente lo determino por experiencia previa o a veces esfuerzo fijo también (Por ej.: 20 horas extras para instalar y configurar correctamente X framework que nunca utilicé).

  7. Sumando todo llegamos al esfuerzo estimado total del proyecto en horas.

Los pasos siguientes (fuera del alcance de este post y sin duda mucho más difícil que estimar esfuerzo) es meter el esfuerzo dentro de un calendario considerando:

  • Equipo con el que se cuenta
  • Paralización de tareas
  • Feriados y vacaciones
  • Eventos de la empresa (cursos, jornadas, etc.)
  • Tiempos del cliente (Ejemplo: el usuario principal no está disponible durante Marzo y no se puede avanzar con el análisis, etc.)
  • Historia cultural de la empresa (Ejemplos: todos los viernes se trabaja menos horas; un 10% del tiempo se gasta en reuniones por fuera de las del proyecto; un 20% del tiempo el equipo va a tener que atender bugs de otros sistemas, etc.)

Una vez que tengamos el proyecto en un calendario (desde ya es tentativo); se debe considerar lo monetario:

  • Valor hora de cada persona del equipo
  • Costos fijos de la empresa prorrateados
  • Viáticos o gastos de traslados
  • Impuestos o bonificaciones
  • Margen de ganancia esperada por el proyecto

Finalmente, vamos a tener un calendario tentativo para todo el proyecto y también un valor tentativo del mismo. Nunca olvidarse que es una estimación y que siempre va a ser necesario ir ajustando los números a medida que avance el proyecto.

Espero que les sea útil, aunque mas no sea para sacar alguna idea e incorporarla en su propio proceso o técnica de estimación.

Anuncios

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

  1. Pablo, tu respuesta a la pregunta que se hace todo desarrollador, ¿Como estimar software?, me parece la más acertada de todas las que leí hasta el momento. Te felicito por la simpleza con la que explicás el concepto. La red está inundada de artículos que hacen referencia a cocomo y puntos de función pero ninguna de ellas aporta una solución práctica al asunto.
    Por mi parte publique un post sobre el tema que sin haber leido este artículo tiene algunos aspectos en común y te invito a leerlo en http://www.desarrollodesw.blogspot.com/.
    ¡Gracias por compartir tus conocimientos!

    • Interesante! Actualmente estoy usando esta misma tecnica de puntos de casos de uso para estimar. Las estimaciones resultantes suelen ser un poco grandes y generalmente termino ajustando a mano algunas cosas. Vos la utilizaste? Que resultados encontraste?

      Gracias!!!

      • Actualmente utilizo el metodo PROBE de PSP(Personal Software Process), donde estimo lo que tardaria desarrollando un modulo de software, sin embargo esa la utilizo solo para estimaciones personales, ahora si se trata de estimaciones en donde trabajarán un grupo de personas utilizaria el wideband delphi, en donde se realiza una sumatoria de todas las estimaciones (personales) de cada una de las personas y se promedian, la tecnica de use case points actualmente la estoy estudiando ya que que llevo la asignatura de “Administracion de Proyectos”, pero en lo personal la utilizaria en proyectos grandes y algo importante seria tener los requerimientos del sistema (ERS), de donde se obtendran los use case, soy estudiante de Ingenieria de Software de la Facultad de Matemáticas de la Universidad Autonoma de Yucatan de México. Saludos y espero te haya servido el articulo, alli explican claramente la tecnica.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s