No hace mucho tiempo, se aceptaba ampliamente que la planificaci\u00f3n es una parte muy cr\u00edtica de todo el proyecto.\u00a0Si bien la planificaci\u00f3n adecuada sigue siendo muy importante y dar\u00e1 como resultado una mejor ejecuci\u00f3n, el marco de tiempo para el plan del proyecto se est\u00e1 reduciendo.\u00a0En el entorno actual, es muy dif\u00edcil planificar todo el ciclo de vida del proyecto al inicio del mismo.\u00a0Hay una necesidad de hacer visitas frecuentes a la mesa de dibujo.<\/p>\n
Es muy posible que el alcance del proyecto cambie por completo durante las diversas iteraciones de la planificaci\u00f3n del proyecto;\u00a0sin embargo, este proyecto a\u00fan puede clasificarse como exitoso, mientras que el proyecto que entrega lo que se plane\u00f3 pero se volvi\u00f3 obsoleto durante la ejecuci\u00f3n del proyecto puede clasificarse como redundante o fallido.<\/p>\n
El desarrollo de software basado en planes es un enfoque m\u00e1s formal y espec\u00edfico para crear una aplicaci\u00f3n.\u00a0Todas las metodolog\u00edas basadas en planes incorporan: repetibilidad y previsibilidad, un proceso incremental definido, documentaci\u00f3n extensa, arquitectura de sistema inicial, planes detallados, monitoreo, control y educaci\u00f3n de procesos, gesti\u00f3n de riesgos, verificaci\u00f3n y validaci\u00f3n.<\/em><\/p><\/blockquote>\n
Los planes generalmente se generan por lo siguiente:<\/p>\n
\n
- Proyecto desglosado en etapas\/tareas<\/li>\n
- Cada tarea dividida en sus actividades compuestas<\/li>\n
- Cada tarea individual estimada (quiz\u00e1s usando m\u00e9tricas)<\/li>\n
- Estimaciones agregadas para dar el esfuerzo total<\/li>\n
- Lista de tareas analizada en busca de concurrencias y dependencias para proporcionar un cronograma<\/li>\n
- El cronograma y la fecha de entrega ayudan a proporcionar el tama\u00f1o y la composici\u00f3n del equipo<\/li>\n
- Equipo ensamblado y proyecto comienza<\/li>\n
- Seguimiento y control a lo largo del desarrollo<\/li>\n
- \u00a1Entrega!<\/li>\n<\/ul>\n
[Fuente: Coleman, Gerry.\u00a0Gesti\u00f3n de procesos de software, Dundalk IT \/ IT Tralee (2008)]<\/p>\n
\u00bfEst\u00e1 obsoleto \u201cPlanificar el trabajo y trabajar el plan\u201d?<\/span><\/h3>\n
En el entorno actual, puede que no est\u00e9 mal decir que todos los productos y servicios son perecederos.\u00a0Si el tiempo de comercializaci\u00f3n es demasiado largo, el producto o servicio puede volverse in\u00fatil incluso si no ha perecido f\u00edsicamente.\u00a0De la misma manera, un proyecto puede perecer muy f\u00e1cilmente si para el momento en que se completa, las demandas de las partes interesadas han cambiado.\u00a0Las empresas han comenzado a darse cuenta de que las personas y no los procesos son los verdaderos lubricantes para cualquier proyecto y, por lo tanto, el compromiso y la participaci\u00f3n de las partes interesadas son muy necesarios para el \u00e9xito de los proyectos.\u00a0Para que las partes interesadas se comprometan con el proyecto, deben ser capaces de ver su utilidad en su entorno y vida actual.<\/p>\n
Como resultado, en el mundo actual, din\u00e1mico e incierto, los m\u00e9todos tradicionales de gesti\u00f3n de proyectos son cada vez menos efectivos y esto requiere m\u00e9todos mucho m\u00e1s din\u00e1micos, adaptables, flexibles…\u00a0en otras palabras, \u00e1gil.<\/p>\n
Referencias<\/span><\/h3>\n