<\/u>Cada vez que he estado involucrado en un proceso de adopci\u00f3n de pr\u00e1cticas de Direcci\u00f3n de Proyectos, surge la pregunta: \u00bfy por qu\u00e9 no usamos m\u00e9todos \u00e1giles? Aun considerando que, la mayor\u00eda de las veces, solo estamos tratando de implantar las pr\u00e1cticas m\u00e1s b\u00e1sicas y elementales.<\/p>\n
Ciertamente el uso de m\u00e9todos predictivos, esto es suponer que es posible definir completa y anticipadamente la soluci\u00f3n a desarrollar, y de esta forma generar un plan detallado del proyecto, que despu\u00e9s se vaya ejecutando rigurosamente, no ha dado los resultados esperados en el desarrollo de software. Dentro de las principales causas, podemos se\u00f1alar que el cliente y los usuarios conocen perfectamente el problema, pero no est\u00e1n en condiciones de definir en detalle la soluci\u00f3n.<\/p>\n
Frente a ello surgen como respuesta los m\u00e9todos adaptativos (o \u00e1giles), que ponen \u00e9nfasis en el trabajo en equipo y la creatividad, para ir desarrollando la mejor soluci\u00f3n. Esto se va haciendo con entregas parciales y frecuentes de software funcionando, en lugar de tener que \u201ccrear\u201d un producto completo en papel, generando como consecuencia una voluminosa documentaci\u00f3n , lo cual permite mejor interacci\u00f3n con el cliente y una mejor medici\u00f3n del estado de avance del proyecto. Ello va permitiendo adaptarse al cambio en forma mucho m\u00e1s natural que los m\u00e9todos predictivos.<\/p>\n
Pero los principios generales de la Direcci\u00f3n de Proyectos siguen presentes. Por citar algunos elementos b\u00e1sicos, sigue siendo necesario ponerse de acuerdo al principio del proyecto acerca de los objetivos, alcances, plazos y costos. En lugar de hacer una planificaci\u00f3n detallada, se hace una planificaci\u00f3n general que se va detallando a lo largo del tiempo (lo que el PMBOK llama planificaci\u00f3n incremental). Un factor central de esta planificaci\u00f3n es la priorizaci\u00f3n de los requisitos, que se basa en el valor, costo y riesgo de cada requisito.<\/p>\n
Se equivoca quien cree que \u201cm\u00e9todo \u00e1gil\u201d es comenzar a desarrollar software sin un proceso previo de entendimiento del problema y de planificaci\u00f3n. Ciertamente el concepto \u201c\u00e1gil\u201d prioriza \u201cSoftware funcionando, sobre documentaci\u00f3n exhaustiva\u201d, pero esa afirmaci\u00f3n se hace en un contexto de procesos con mucha documentaci\u00f3n. En ning\u00fan caso debe entenderse que \u201c\u00e1gil\u201d significa la ausencia de toda formalidad.<\/p>\n