Enfoque cascada o Agile Project Management? Cual de estos es correcto para ti?

Si usted es un gerente de proyecto con experiencia, no se puede permitirse el lujo de expresar su opinión acerca de las metodologías ágiles versus gestión de proyectos conocido como “cascada”.

Bastante a menudo a uno le preguntan "¿Cuál es el modelo de gestión de proyectos usas"; Y sabemos que la persona que hace esta pregunta se espera sea de 'tradicional' o 'ágil' como respuesta.
Para aquellos que son “Ya estuve allí y ya lo he realizado con mucho éxito en infinidad de ocasiones" , sugiero que seáis menos pelmazos y mas honestos. 

Tanto ágil o cascada no son modelos de gestión de proyectos más bien es un enfoque o estilo de la planificación, organización y ejecución de proyectos. 

Hay ciertos principios aplicables a cada estilo, ciertas diferencias entre ellas y encontrar partidario apoyando firmemente cualquiera de estos estilos. Echemos un vistazo a lo que son estos enfoques y sus méritos y desventajas:

Entender el enfoque - ¿Qué es en realidad?

• Paso a paso, donde se sabe que cada paso de la ejecución de proyectos y detalló a cabo.
• El enfoque flexible y rápido para gestionar y entregar proyectos sin necesidad de una amplia planificación.
• Todas las “dependencies” están supuestamente conocidos, analizadas al detalle y el proyecto se mueve al paso siguiente sólo cuando se haya completado su paso anterior.
• Lo más importante, todos los requisitos deberán estar claramente establecidos y bien documentados.

Méritos

• Un proyecto basado en la metodología “Cascada” tiene énfasis en la gestión de requisito meticulosa, planificación de proyectos y la documentación. Se hace mucho más fácil para trabajar en proyecto similar/existente entregado en el pasado.
• Enfoque de gestión de proyectos Ágiles se centra en la entrega rápida de trabajo producto/servicio. De ahí que la gestión de proyectos ágiles puede funcionar para proyectos no relacionados sin llevar equipaje histórico.
• Típicamente el enfoque de gestión de proyectos ágiles funciona mejor para la prestación de servicios, no relacionada con la entrega del producto físico (por ejemplo, código, diseño creativo, asesoramiento, etc)
• Gracias a su enfoque flexible, las metodologías ágiles ejecutan el proyecto de manera tal que curso de la ejecución del proyecto se pueden corregir, según la petición, sugerencia o cambios requeridos por el cliente, en resumen, es adaptable a los requerimientos de los clientes.
• Tanto el management como los Stakeholders gozan con la idea de certeza del alcance de un proyecto y cronograma del proyecto, por tanto, puede trabajar con referencias constantes. Esto es en resumen su piedra filosofal por lo cual se esmeran en continuar con el método cascada. Ya que es más fácil medir el resultado.

Desventajas

• El modelo de cascada requiere un esfuerzo sustancial para la gestión de requisitos, proyecto de planificación desde el principio. Es todo un ejercicio que una vez terminado deja menos posibilidades para los cambios de requisitos.
• El modelo de cascada prácticamente no contempla cambios en los requerimientos por tanto Scope change/requirement change se torna un proceso lento y tiene que pasar por múltiples aprobaciones de control y de gestión.
• Ni hablar de cuando el modelo Cascada se cruza con QC/QA de proyectos. Documentación y proceso de control de cambios hacen que todo el proceso que lleva tiempo e inflexible. Si la situación del negocio cambia durante la ejecución del proyecto, el resultado final puede no tener relevancia para el mercado/cliente por lo tanto puede llevar al fracaso de proyecto o impacto negativo en el ROI para el cliente, el método cascada ignora esto completamente, en mi opinión dado que es una metodología ajena al “Factor Humano” (ver posts anteriores).
• En el caso de gestión de proyectos ágiles siempre hay una incertidumbre sobre el alcance del proyecto y los cambios de appproach, es muy probable que el equipo del proyecto sea incapaz de adaptarse a tal enfoque de entrega, puede que no sea capaz de entregar, puede convertirse en pánico (pues donde esta la diversión si estos ingredientes, no?).
• Sin embargo, la gestión de proyectos ágiles, es responsabilidad del director del proyecto para gestionar cuidadosamente cartera de proyectos/productos, decidir entregables en diferentes carreras y el avance del proyecto en términos de resultado final. Es decir, si quieres utilizar metodologías ágiles necesitas un gestor de proyectos cojonudo, de mente abierta, que prioritize el “Factor Humano” y pueda conducir y ser el soporte del equipo de trabajo. Si te habéis liado con un Manager de aquellos que – equivocadamente – creen que su tarea es impartir directrices y verificar que los trabajadores cumplan un horario y un código de vestimenta corporativa, pues lo tienes duro chaval.
• Sentido de la flexibilidad y la aceptación de la solicitud de cambio en casi todas las fases pueden hacer al cliente habitual (con los métodos de prueba de error, pensando que se corregirá en siguiente sprint) y las ocasiones están mal pensamiento (o la falta de bien pensadas) requisitos será entregado al el coste del trabajo duro del equipo del proyecto que resulta en un mayor costo y el resultado no tan deseada.
• Retomemos con la Metodología de Cascada, que tanto veneran los conservadores mas escépticos - y menos exitosos - cualquier error en el requerimiento de eliminación en fase temprana es difícil de rectificar. En ciertos casos, el proyecto es más probable que falle .

-- 

Best Regards · Mit freundlichem Gruß · Cordialmente ·