Evaluando un proyecto bajo presion (Respaldo del blog)


(ChileAgil) #1

Este es un artículo del viejo blog de chileagil, publicado el 23 de Abril de 2008 por @agustinvillena

Ayer, un amigo me llamó porque su nuevo jefe le pidió evaluar el costo en horas hombres de un proyecto para el cual ya existía un levantamiento de requerimientos. Creo que lo que conversamos ayer merece ser compartido, así que lo dejo aquí para la discusión pública.

Una evaluación de proyectos de software debe basarse, según mi experiencia, en algunas claves:

  • Las incertidumbres pueden ser de dos tipos: de NEGOCIO o TÉCNICAS: Las de negocio se refieren a qué necesita el cliente, y las técnicas son sobre cómo de implementará la solución. Solemos preocuparnos de las últimas, pero son las primeras son tan importantes como las otras. Aquí tenemos el típico caso de evaluar el desarrollo de un reporte: un noviio diría: “2 días”, debido a que las herramientas disponibles lo hacen simple, pero sin claridad acerca de qué se desea reflejar en el reporte, el desarrollo puede durar meses. Es labor del evaluador determinar si el grado de riesgos en ambas dimensiones hace que el proyecto se salga del grado de riesgo aceptable para tomar el proyecto.

  • Una evaluación depende en gran medida de quién va a realizar la tarea del desarrollo: Dicho de otra forma, los conocimientos y habilidades específicas de la(s) persona(s) que van a participar de un proyecto impactan directamente en los montos de tiempo y recursos humanos que se evalúen. Es una ilusión pensar que un proyecto se puede evaluar en forma abstracta.
  • Un levantamiento de requerimientos previo no asegura una mejor evaluación: Muchos de los documentos de requerimientos que he visto plantean un conjunto que diagramas de casos de uso UML que fallan en recoger el porqué el sistema debe implementar tal o cual funcionalidad. Un buen entendimiento del problema de negocios a resolver es mucho mejor punto de partida. Y en caso de contar con casos de uso, estos sólo serán un buen aporte si tienen definidos claramente cuáles son los criterios de validación con los cuales el cliente se compromete a dar su aprobación a la implementación del caso en cuestión. Sin esos criterios claros, es muy dificil poder estimar con algún grado de certeza.
  • Y desde la perspectiva ágil: no olvidar que lo que realmente se puede estimar es aquello con baja incertidumbre. Es por esto que es posible hacer planes de corto plazo detallados, pero sólo estimativos de largo plazo. Para más detalle, les recomiendo la presentacion “Estimation in Agile Projects”, desde donde extraje el esquema de incertidumbres usado en este artículo.