close
TecnologíaTransformación Digital

Siete criterios para definir cuándo usar metodología ágil y cuándo cascada, por Rubén Lazarte

Siete criterios para definir cuándo usar metodología ágil y cuándo cascada

Las metodologías ágiles son la última tendencia en el desarrollo de software, sin embargo una metodología ágil no siempre es la mejor opción, aunque no esté de moda decirlo. Las metodologías ágiles hay que ponerlas en contexto y utilizarlas en su justa medida, cuando sean la mejor opción, que no es siempre.

Las metodologías ágiles están basados en el desarrollo iterativo e incremental, a través de equipos auto-organizados y multidisciplinarios, donde los requisitos y soluciones evolucionan con el tiempo. Las metodologías agiles más extendidas son Scrum, Kanban y Programación Extrema (XP).

Las metodologías cascada o waterfall, en cambio, están basados en un desarrollo secuencial que ordena rigurosamente las etapas del proceso, cada etapa de esperar la finalización de la etapa anterior. Cómo ejemplos representativos de las metodologías cascada podemos mencionar PMBOK, Prince 2, RUP entre otros.

Lo ideal es que tu organización cuente con una Oficina de Gestión Proyectos (PMO) híbrida, que proporcione procesos adaptados para la gestión de proyectos tanto bajo metodología ágil como bajo metodología cascada, se deben establecer los criterios para definir si un proyecto determinado, debe ser desarrollado utilizando una u otra metodología.

A continuación presentamos siete criterios a tomar en cuenta para definir si un determinado proyecto debe utilizar metodología ágil o metodología cascada.

  1. Solución técnica desconocida. Saber qué se quiere hacer es diferente a saber cómo, quizás el usuario tenga un concepto de producto claro pero no sepa cómo implementarlo. La metodología ágil agrega más valor cuando la solución técnica es desconocida, es decir si es de un alto grado de complejidad, distinto de lo que el equipo de desarrollo ha trabajado y si es una solución innovadora que el equipo nunca ha realizado. Cuando la solución técnica es conocida, es decir el entorno de la organización es estable, los cambios son infrecuentes y se está desarrollando un producto que ya ha desarrollado varias veces, es preferible la utilizar metodología cascada, por ejemplo los mantenimiento o actualización a aplicaciones existentes.
  2. Requisitos dinámicos.Si se trata de un proyecto en un ámbito donde los puntos de vista de análisis están constantemente cambiando, como podría ser un datamart de fuerza de ventas, entonces la metodología ágil te ayudará a responder a esa variabilidad. Si se trata de un proyecto en un ámbito de poco dinamismo como por ejemplo un sistema de estados financieros y contables en donde los KPI casi siempre los mismos para todas empresas, la metodología cascada te ayudaría más.
  3. Sistema no es crítico. Si te encuentras con un proyecto de un sistema crítico, en el que cualquier falla involucre grandes pérdidas humanas o grandes cantidades de dinero, no debes utilizar metodologías ágiles. Por ejemplo si el sistema involucra creación de un Business Activity Monitoring es  mejor asegurar el éxito usando metodología cascada.
  4. Nivel del equipo de desarrollo maduro. Las metodologías ágiles requieren de gran madurez, experiencia y dosis de talento; deben ser equipos con gente senior o semi-senior. Si tu equipo lo integran principalmente juniors y novatos es mejor que no intentes utilizar metodologías ágiles.
  5. Cliente con suficiente tiempo para el proyecto.El cliente debe disponer de suficiente tiempopara dedicarlo al proyecto, es decir brindar recursos humanos calificados para que acompañe al proyecto en toda su extensión, si la respuesta es no, entonces mejor utilizar metodología cascada.
  6. La forma de contratación no es Precio Fijo. Las metodologías ágilesparten de la premisa que el alcance debe ser modificado de iteración en iteración según las necesidades y prioridades del negocio, pero si de entrada el contrato exige que el alcance del proyecto y sus presupuesto estén definidos desde el proncipio y que al final el proyecto se entregue exactamente con ese alcance, no debe utilizar metodologías ágiles sino más bien metodología cascada.
  7. El proveedor de la solución es interno o si es externo tiene una relación de largo plazo. Si está desarrollando la solución con un proveedor externo con una relación de corto plazo, la organización, al no existir suficiente grado de confianza, tenderá a favorecer un esquema de alcance y precio fijo cerrado para la contratación, por lo cual no sería recomendable para este proveedor proponer utilizar metodologías ágiles y más bien debería utilizarse metodología cascada.
Tags : cienciatecnología
Ruben Lazarte

El Autor Ruben Lazarte

Experto en desarrollo de software y operación de tecnología de la información para el sector bancario, servicios y retail.

Deja una repuesta

%d bloggers like this: