close
TecnologíaTransformación Digital

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

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.

1 comentario

  1. Estimado Rubén, algunas precisiones. El PMBOK no es una metodología, ni menos en cascada y no solo está enfocada para proyectos de Software. Por el contrario es una guía de buenas prácticas, marco de conocmiento, que un Jefe de proyecto puede utilizar, según sea pertinente, para alcanzar el éxito de un proyecto. La versión 6 del PMBOK ya incorpora formalmente prácticas ágiles, aunque con anterioridad ya existía una certificación para prácticantes de estas (ACP).

    Con respecto a los criterios, en general hacen sentido y están de acuerdo a las convenciones que incluye la Agile Practice Cuide (PMI y Ágiles Alliance). Proyectos complejos en lo tecnológico (técnica, conocimiento) y/o requerimientos complejos (cuyo alcance pueden mutar, cambiar, picotear, o no es claro) entonces las metodologías ágiles podrían ser más útiles por si esencia de (iterativo e incremental). El tema de los proyectosde software es otro, y como bien lo explica Javier Garzas en sus blog, es que el paradigma heredado de otras ramas de la ingenierías, como la construcción (cascada) o perder el foco solo en el plazo de los proyectos de software, atentan contra las calidad y el valor esperado por el cliente. Según este nuevo paradigma, el desarrollo de software hace más sentido que sea como un continuo, proceso permanente, en donde cómo es difícil de predecir sus plazos (por eso los cronogramas no se cumplen), cumplir con las expectativas de los clientes y/o negocio (porque van madurando o son difíciles de entender y manejar o cambian, ejemplo del columpio, además de que la ingeniería de requisitos es desgastante y puede hacerse mal o interpretarse mal). Por su parte proyectos atrasados y con plazos por cumplir atentan contra la calidad de software y la deuda técnica. Luego, hace sentido revisiones y feeback del cliente, más frecuentes (iterativo) y entregas más pequeñas, escalables, que se puedan refinar y que aportan valor al negocio (incremental y en producción). Además de poner foco en los equipos de desarrollo, que sean permanentes durante este proceso de desarrollo de software, para que se vaya afiatando en los técnico, polivante, autogestión y conocimiento del software (curva de experiencia). Proyectos con inicio y fin atentan contra los equipos (disolución) y la calidad de software (deuda técnica). Proyectos atrasados,en donde se incorporan más recursos, en general se atrasan más ( se pierde tiempo valioso en explicaciones e inducción). Por su parte, el agilismo provienente de la cultura Lean, busca eliminar los desperdicios, que muchas veces existe por doquier en proyectos con metodologías en cascada. Proyectos en donde se tiene experiencia en lo técnico y el requisito no sufrirá mayor cambio de alcance y/o la metodologia en cascada ha funcionado entonces un proyecto ágil, podría requerir tiempo innecesario del cliente y/o product owner. Las metodologias ágiles no acortan el tiempo de los proyectos, sino que minimizan el riesgo de que el entregable se ajuste más a las necesidades del cliente o negocio y que se trabaje en lo prioritario y de mayor valor. Creo que la clave está en los equipos de trabajo permanentes, integrados o multifuncionalde desarrollo, testing y producción (para eliminar desperdicios). También, creo que la metodología que decimos “cascada” se ha desprestigiado y en general la del desarrollo de software, porque problemas relacionados con la multitarea, por no limitar el trabajo en progreso (Kanban, WIP, concepto de Pull ) (el que mucho abarca, poco aprieta), además, porque se dejan de usar el sentido común, o no se aplican bien las metodologías, o no existen existen prácticas, o se utilizan mal. Misma cuestión podría pasar perfectamente con el mal uso, abuso, o mala aplicación de las metodologías ágiles, que terminen por desprestigiarla, porque ejemplo subestimando , en Scrum, el rol del product owner o reemplazandolo o ocupándolo por el mismo Scrum Master. Otro aspecto a precisar, es el de la programación XP, que pone foco en el desarrollo de software propiamente tal ( y no como gestionar un proyecto relacionado, que sería como Scrum, están en diferentes niveles de abstracción) y a las necesidades de cambio siendo su principal fortaleza o beneficio combatir y minimizar la deuda técnica, así como entregar piezas de software de valor.

Deja una repuesta

%d bloggers like this: