En un contexto como el actual, el creciente ritmo evolutivo de los mercados ha obligado a muchas empresas a entregarse al pragmatismo, acelerando sus procesos y priorizando los resultados. Una muestra de ello es que el Project Management est\u00e1 adoptando una tendencia hacia modelos de gesti\u00f3n cada vez m\u00e1s \u00e1giles frente a los tradicionales. En t\u00e9rminos generales, los modelos \u00e1giles se centran m\u00e1s en el \u2018qu\u00e9\u2019 y no en el \u2018c\u00f3mo\u2019, apostando por una gesti\u00f3n flexible que permite realizar los cambios necesarios para garantizar unos resultados satisfactorios para el cliente.<\/p>\n
Pero, \u00bfsignifica eso que ya no sirvan los modelos m\u00e1s tradicionales? A pesar de que la metodolog\u00eda \u00e1gil ha ganado popularidad en los \u00faltimos a\u00f1os, lo cierto es que ambos modelos tienen sus pros y sus contras, y resulta dif\u00edcil asegurar con rotundidad cu\u00e1l es mejor en cada caso. Para tener alguna clave m\u00e1s, a continuaci\u00f3n comparamos dos modelos de gesti\u00f3n de proyectos: M\u00e9todo \u00c1gil y M\u00e9todo Cascada.<\/p>\n
La metodolog\u00eda \u00e1gil se basa en un desarrollo incremental e iterativo (es decir, el proceso de planificaci\u00f3n es evolutivo y se va detallando a medida que avanza el proyecto). Fue dise\u00f1ada para dotar de m\u00e1s autonom\u00eda a los miembros del equipo de trabajo frente a las limitaciones que presentan los m\u00e9todos tradicionales en este sentido. En un proyecto \u00e1gil, el equipo est\u00e1 facultado para tomar decisiones, mientras que en los proyectos tradicionales se ejerce un mayor control de arriba hacia abajo.<\/p>\n
En el caso de los proyectos de desarrollo de software, el modelo m\u00e1s empleado es el m\u00e9todo Scrum. En \u00e9l, el proceso de dise\u00f1o se divide en modelos individuales en los que trabajan los dise\u00f1adores. Como hemos visto, no existe un plan de acci\u00f3n concreto sino que los desarrolladores son libres de cambiar los requisitos cuando lo consideren conveniente y aplicar las modificaciones necesarias mientras el proyecto avanza.<\/p>\n
En los modelos de gesti\u00f3n de proyectos \u00e1giles, los equipos son multifuncionales y trabajan de manera simult\u00e1nea durante periodos de tiempo fijos. El valor de negocio es prioritario, por lo que si es necesario se pueden cambiar los requisitos para obtener de manera realista el mejor producto final posible sin alterar el tiempo de entrega ni el coste de producci\u00f3n. Esto obliga a mantener un flujo de comunicaci\u00f3n constante entre el equipo, la empresa y los clientes.<\/p>\n
Este m\u00e9todo es especialmente indicado en proyectos cuyos objetivos finales no est\u00e1n claramente definidos o que simplemente prev\u00e9n un final abierto, es decir, que no preconciben la forma del producto final mientras este sea de la mejor calidad posible seg\u00fan los recursos disponibles. Esto ocurre, por ejemplo, en el dise\u00f1o de software experimental y en los proyectos que se desarrollan en entornos de trabajo en equipo: los actores implicados trabajan en m\u00f3dulos diferentes y despu\u00e9s se emplean para integrar dichos m\u00f3dulos en un producto final \u00fanico.<\/p>\n
La metodolog\u00eda en cascada es un modelo tradicional que, como su nombre permite intuir, es un proceso lineal y secuencial: de manera muy definida existe un punto inicial que nos llevar\u00e1 a un punto final en distintas etapas: Concepci\u00f3n, Inicio, An\u00e1lisis, Dise\u00f1o, Construcci\u00f3n, Pruebas, Implementaci\u00f3n y Mantenimiento. Como se puede observar, este m\u00e9todo est\u00e1 m\u00e1s orientado a la planificaci\u00f3n, por lo que es menos flexible pero a la vez m\u00e1s seguro que los m\u00e9todos \u00e1giles. Los posibles contratiempos se pueden prever y arreglar con cierta normalidad a trav\u00e9s del plan de desarrollo y el proyecto puede tomar forma de manera m\u00e1s r\u00e1pida si los plazos y los costes est\u00e1n estimados de manera precisa, lo cual suele gustar bastante a los clientes.<\/p>\n
Para hacernos una idea, el m\u00e9todo cascada ofrece un mayor control de la acci\u00f3n, aunque no es impermeable al cambio, puesto que, como hemos dicho, dedica esfuerzos a prever los problemas. Los m\u00e9todos \u00e1giles cuentan con un margen m\u00e1s amplio para modificar, ampliar o reducir las expectativas que lo hacen m\u00e1s adaptable al cambio.<\/p>\n
Suele ser habitual que los proyectos que empiezan con equipos novicios opten por esta metodolog\u00eda m\u00e1s conservadora, ya sea porque sus miembros no han trabajado de manera conjunta previamente o porque el nivel de experiencia no permite adoptar un m\u00e9todo \u00e1gil que otorgue m\u00e1s poder de decisi\u00f3n de manera individual. En este caso, el m\u00e9todo cascada es m\u00e1s entendible para todas las partes implicadas.<\/p>\n
Como se ha dicho antes, es arriesgado aventurarse a decir que un m\u00e9todo es m\u00e1s v\u00e1lido que el otro, si bien es cierto que la tendencia nos indica que los m\u00e9todos tradicionales est\u00e1n cayendo en desuso. La raz\u00f3n es obvia: sobre todo en el sector tecnol\u00f3gico, la r\u00e1pida evoluci\u00f3n del software est\u00e1 a la orden del d\u00eda y los proyectos son f\u00e1cilmente mutables en el transcurso de su desarrollo, por lo que se necesitan m\u00e9todos \u00e1giles y equipos altamente preparados. Si lo miramos bajo la \u00f3ptica de la productividad, en cambio, ambos modelos tienen sus pros y sus contras. En algunos casos, los proyectos \u00e1giles pueden llevar m\u00e1s tiempo por carecer de una exhaustiva planificaci\u00f3n previa, mientras que en otros casos, la excesiva documentaci\u00f3n de los procesos y la estricta planificaci\u00f3n de los m\u00e9todos tradicionales puede provocar que el proyecto avance m\u00e1s lentamente. En t\u00e9rminos de beneficios, los proyectos \u00e1giles tienen m\u00e1s potencial, aunque tambi\u00e9n tienen m\u00e1s riesgo y probabilidad de fallo si el equipo en su totalidad es inexperto o no est\u00e1 suficientemente implicado.<\/p>\n
Por lo tanto, para saber qu\u00e9 metodolog\u00eda es m\u00e1s apropiada, primero deberemos entender bien qu\u00e9 tipo de proyecto y necesidades tenemos delante. Para proyectos est\u00e1ticos donde es improbable que surjan muchos cambios nos servir\u00e1 el m\u00e9todo cascada, mientras que para proyectos peque\u00f1os donde los cambios son habituales en el proceso de dise\u00f1o ser\u00e1 mejor optar por el m\u00e9todo \u00e1gil.<\/p>\n
Y para terminar, nos hacemos otra pregunta: \u201c\u00bfse pueden implementar de manera complementaria sin ser excluyentes?\u201d<\/p>\n
Algunos expertos dicen que ambos m\u00e9todos pueden coexistir en la gesti\u00f3n de proyectos aunque no exista una f\u00f3rmula definida para ello. El \u00e9xito de probar nuevas f\u00f3rmulas depende del margen de error y de las consecuencias que se est\u00e9 dispuesto a asumir.<\/p>\n
Y a ti, \u00bfqu\u00e9 modelos de gesti\u00f3n de proyectos te parecen mejor? \u00a1Cu\u00e9ntanoslo!<\/p>\n","protected":false},"excerpt":{"rendered":"
En un contexto como el actual, el creciente ritmo evolutivo de los…<\/p>\n","protected":false},"author":135,"featured_media":8251,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[57],"tags":[549,550,474,551],"class_list":["post-8243","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-gestion-de-proyectos","tag-metodo-agil","tag-metodo-cascada","tag-metodologia-scrum","tag-metodologias-gestion-de-proyectos","option-evergreen-es","option-featured-es"],"_links":{"self":[{"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/posts\/8243","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/users\/135"}],"replies":[{"embeddable":true,"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/comments?post=8243"}],"version-history":[{"count":0,"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/posts\/8243\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/media\/8251"}],"wp:attachment":[{"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/media?parent=8243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/categories?post=8243"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redbooth.com\/hub\/es\/wp-json\/wp\/v2\/tags?post=8243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}