Antes de responder directamente a la pregunta del título, siempre es bueno dejar claro cuál es el objetivo final del proyecto que quiere alcanzar
Cómo será el producto dentro de un mes, de medio año o de un año. Pero descríbalo ahora. Esto le dará cierta perspectiva y establecerá las expectativas básicas sobre el nivel de su previsibilidad, flexibilidad, agilidad, velocidad de comercialización y fijación de costes en el tiempo.
Sí, hoy en día, poner en marcha los proyectos en cascada parece una idea ridícula. Sobre todo si ya se ha demostrado innumerables veces que si quiere reaccionar con rapidez a los cambios en los mercados, no tiene otra opción que volverse ágil. Pero si su objetivo es entregar un producto dentro de un año con características que ya están bastante claras y restringidas desde el principio, y cuenta con equipos de personas sin experiencia previa con la metodología ágil, entonces claro, siga siendo conservador y opte por la cascada.
No todos los casos son tan sencillos de concluir. Echemos un vistazo a cómo evaluar mejor qué metodología es mejor para su proyecto.
¿Qué aspecto tiene una cascada?
En lugar de entrar en algunas definiciones que todo el mundo conoce desde hace ya un par de décadas, el resultado práctico de un proyecto en cascada suele ser el siguiente:
- En primer lugar, planifique lo que quiere hacer como resultado/producto final y cuánto puede costar aproximadamente.
- Inicie el proceso de recopilación de requisitos. Discuta a fondo todos los detalles del producto final, objete, cuestione, acuerde, vuelva a discutir y, por último, confirme.
- Estime el conjunto y confirme la previsión presupuestaria.
- Diseñe la solución. Celebre varias reuniones con las partes interesadas. Cree varios documentos y deje que las partes interesadas los revisen. Confirme y apruebe el diseño funcional y técnico final.
- Implemente la solución basándose en el diseño. Aquí es donde se desarrolla el producto final completo.
- Entre en la fase de pruebas y ejecute varios tipos de pruebas. Pruebas unitarias, pruebas del sistema, pruebas funcionales, pruebas de integración, pruebas de rendimiento, pruebas de regresión, pruebas de aceptación del usuario y potencialmente muchas más (dependiendo de la cultura de la empresa). Documéntelo todo y deje que las partes interesadas lo revisen y aprueben.
- Despliegue la solución en el entorno de producción. Aquí es donde los usuarios objetivo empiezan a utilizar el producto final y completo.
- Programe alguna fase de soporte durante la cual el equipo de desarrollo corrija los posibles errores de la solución.
Todo este proceso puede durar de unos meses a unos años. Como puede predecir, los usuarios no verán los resultados hasta el final de ese proceso. Así pues, tras una larga espera llega el momento de la verdad (o del fracaso).
Si algo cambia durante ese largo tiempo y el producto final debe tener un aspecto algo diferente, es una situación que se denomina solicitud de cambio. El diseño debe reabrirse, reelaborarse y volver a aprobarse. Esto prolonga todo el calendario en otra parte. Cada cambio requiere reiniciar todo el proceso anterior.
En el otro lado, tiene una definición de fases sólida como una roca, un presupuesto fijo para cada fase y un tiempo fijo. Aunque tenga que esperar mucho para obtener el primer resultado, si las posibilidades de que se produzcan cambios por el camino son mínimas, puede seguir siendo una opción preferible.
¿Qué aspecto tiene un proyecto ágil?
Así es como puede funcionar el proyecto bajo una configuración Ágil:
- Defina la visión empresarial del producto final. A grandes rasgos, pero con requisitos empresariales claros y expectativas de lo que el producto deberá cumplir para los usuarios.
- Cree una lista de Epics funcionales y Enablers técnicos que cubran la visión.
- Haga una estimación de alto nivel de las epopeyas y los habilitadores para establecer unas expectativas presupuestarias ajustadas y un calendario de entrega. Defina qué es el Producto Mínimo Viable (PMV) y cuáles son el resto de características que forman el producto final.
- Establezca un equipo scrum y programe los sprints dentro del plazo previsto. Desglose las épicas en características e historias con el equipo. Estime las historias y planifíquelas para los próximos sprints en función de la prioridad que tengan las características y las historias.
- Trabaje en las historias en cada sprint. Incluya todas las actividades en los sprints, es decir, diseño, desarrollo, prueba y despliegue. Al final de cada sprint, presente el resultado del incremento a los usuarios y solicite su opinión.
- Si algo se sale de lo previsto o del resultado deseado, modifique las características o las historias para adaptarlas a la realidad actualizada. Refléjelo inmediatamente a partir de los siguientes sprints.
- Justo después de completar el alcance del MVP, libérelo a los usuarios finales para recabar rápidamente sus comentarios de producción.
- Continúe desarrollando el resto de las características reflejando los resultados de los comentarios de los usuarios de la parte del sistema ya liberada.
Esto es sólo un resumen rápido, pero la diferencia con la cascada ya está clara. Retroalimentación rápida, adaptación, reflejo de las necesidades actuales que cambian con el tiempo, primer producto valioso entregado en el menor tiempo posible. Todas esas son propiedades que no tiene oportunidad de conseguir en un proyecto en cascada.
Ágil frente a cascada
Un proyecto no puede tener éxito sin una metodología de gestión de proyectos adecuada. Esto significa definir procesos, métricas, evaluaciones y formas generales de trabajar para los equipos que forman el proyecto.
Los equipos necesitan saber qué reglas seguir, qué definirá los hitos, cuándo alcanzarlos y cómo medir y evaluar el éxito. Al mismo tiempo, las partes interesadas necesitan entender qué pueden esperar del proyecto y cuándo podrán ver los primeros resultados del trabajo.
Generalizando un poco, podemos decir que los proyectos que funcionan en entornos de nube tienen muchas más probabilidades de inclinarse por las metodologías ágiles (o deberían, al menos). Los proyectos que trabajan con infraestructuras locales siguen prefiriendo muy a menudo los procesos en cascada. Esto es una conclusión natural.
El entorno en nube se construye desde cero para adaptarse a un entorno en constante cambio. Se adapta lo más rápidamente posible (con diversos servicios «elásticos») a la nueva realidad. El entorno on-premise suele estar predefinido al principio. Es difícil cambiarlo con el tiempo, por lo que los equipos trabajan con variables deterministas durante toda la duración del proyecto.
Resumen del enfoque ágil frente al enfoque en cascada.
| Característica | Enfoque en cascada | Enfoque Ágil |
|---|---|---|
| Gestión de los requisitos de los usuarios | El cambio se trata como un proceso formal (solicitud de cambio). Puede ser necesario rehacer el trabajo, lo que repercute en los costes y los plazos. | Acepta los cambios como parte del proceso estándar, sin un impacto significativo en los costes ni en los plazos. |
| Planificación y alcance del proyecto | Define el alcance al principio y se ciñe a él. Las fases son rígidas y se ciñen al plan original. | Tiene una visión clara del producto final pero permite cambios. El trabajo se organiza en sprints con flexibilidad en la forma de completar las tareas. |
| Seguimiento del progreso del proyecto | Realiza un seguimiento del progreso dentro de cada fase. Los retrasos en una fase pueden afectar a todo el calendario del proyecto. | Realiza un seguimiento del progreso mediante sesiones de demostración al final de cada sprint. Se centra en el producto viable. |
| Colaboración en equipo | Diferentes personas en diferentes fases del proyecto, interacción limitada. | Equipo interfuncional con comunicación constante entre los miembros del equipo y las partes interesadas. |
| Gestión de riesgos | Seguimiento del estado en función del avance de las fases. Responde a los riesgos de forma retrospectiva al tiempo que se ciñe al plan. | Se centra en resolver las dependencias entre equipos y actividades de forma proactiva. Adapta el plan para eliminar los riesgos previstos. |
| Marco de ejecución | Metodología tradicional. | Requiere prácticas de transformación para adaptarse al enfoque ágil. Implica cambiar hábitos y mentalidades. |
Sin embargo, esta elección definirá varios aspectos de las propiedades de ejecución del proyecto.
#1. Requisitos del proyecto y gestión del cambio
Uno de los aspectos más importantes que definen la elección es cómo se gestionarán los requisitos del usuario. Y también, ¿cuál es el proceso si más adelante es necesario modificar los requisitos ya acordados?
En un proyecto en cascada, todos los requisitos están definidos y firmados por las partes interesadas al principio; si surge algún cambio en ese estado, el proyecto lo trata como una solicitud de cambio. Tiene que ser de nuevo validada, acordada y confirmada.
Cualquier trabajo ya realizado hasta ese momento debe ser revisado y comenzado de nuevo. Hay que reajustar los costes (ya que se trata de trabajo adicional no cubierto por el contrato original). En el peor de los casos, incluso hay que prolongar todo el calendario del proyecto.
Con una configuración ágil, los cambios son bienvenidos. Usted trata los cambios como algo normal del día a día. Usted acuerda con las partes interesadas (probablemente como resultado de la última demostración del sprint) que los cambios son cruciales para mantener la visión del proyecto. Entonces, usted programa esos cambios inmediatamente para los siguientes sprints.
El contenido anterior cambiará con ello, y los equipos seguirán trabajando con los nuevos requisitos a partir de ese día. No hay pérdida de tiempo ni de costes. Simplemente se adapta a la nueva realidad de inmediato y sustituye el plan original por el nuevo. No es necesaria en absoluto una gestión especial de las solicitudes de cambio. Todo forma parte de las iniciativas de planificación de sprints.
#2. Planificación y alcance del proyecto
Como cabría esperar, el proyecto en cascada establece y fija todo el alcance al principio. Usted genera el plan del proyecto en torno a este alcance. A continuación, divide la duración del proyecto en fases específicas (normalmente análisis, diseño, desarrollo, pruebas, despliegue, soporte y mantenimiento) y fija los equipos y recursos en torno a esas fases. Durante la mayor parte del calendario del proyecto, su principal objetivo es ceñirse lo más posible a este plan original en cuanto a costes y plazos.
Un proyecto ágil tiene una visión del producto final en lugar de un plan rígido. El estado final está claro, pero el camino para llegar a ese estado es libre de cambiar. Además, el calendario del proyecto sigue estando definido y acordado sobre la base de una estimación preliminar de la demanda y la experiencia de carga de capacidad de los equipos que trabajan en el proyecto. El plan no tiene fases separadas. En su lugar, cada sprint es una pequeña fase en sí misma que contiene todas las actividades que el equipo necesita para lanzar con éxito el producto incremental.
En resumen, el proyecto en cascada trata los cambios como una complicación a resolver (y una oportunidad para que los proveedores adquieran dinero adicional). Por el contrario, el proyecto ágil trata el cambio como algo habitual sin consecuencias adicionales (aparte de un producto final más adecuado).
#3. Seguimiento del progreso del proyecto
El proyecto en cascada realiza un seguimiento del progreso del plan dentro de las fases del proyecto. La fase de diseño no puede comenzar antes de que se complete la fase de análisis, las pruebas no pueden comenzar antes de que se complete toda la construcción, y así sucesivamente.
Si alguna de las fases sufre un retraso, afectará al progreso de las fases restantes del proyecto. Por eso es importante controlar las actividades dentro de cada fase y asegurarse de que progresan linealmente en el tiempo. De lo contrario, aumentará el riesgo de retrasar esa fase concreta y, en consecuencia, todo el proyecto.
El proyecto ágil realiza un seguimiento del progreso, principalmente con sesiones de demostración que tienen lugar al final de cada sprint. El producto viable es la principal medida del progreso. Naturalmente, hay que asegurarse de que cada sprint termine con su contenido completo. Ninguna historia o sólo las mínimas se trasladan a los siguientes sprints.
En última instancia, es mucho más fácil ver el progreso general del proyecto si se puede probar directamente el incremento de producto actual y volver al equipo con comentarios muy concretos de inmediato.
#4. Colaboración en equipo
Se trata de las actividades estrictamente separadas de la cascada frente a la colaboración continua con todas las partes de un equipo ágil.
Un proyecto en cascada suele tener a distintas personas trabajando en distintas fases del proyecto. Puede que se desborden unos a otros hasta cierto punto, pero siguen siendo grupos de personas diferentes. Podría decirse que son casi silos.
La definición de equipo ágil reside en la comunicación y el valor. También será un equipo interfuncional capaz de ejecutar todas las actividades del ciclo de vida del producto. Los silos de los equipos es algo que no se desea que exista. La comunicación constante de ida y vuelta entre el equipo y las partes interesadas externas es una definición básica del éxito de un proyecto ágil.
#5. Gestión de riesgos
Obviamente, querrá contar con un proceso para hacer un seguimiento de los riesgos, problemas o cualquier tipo de obstáculo que el proyecto pueda acarrear durante su cronograma.
En el caso de un proyecto en cascada, esto se traduce en un seguimiento del estado de la fase actual del proyecto. El informe de estado estándar tipo semáforo mostrará verde (todo va bien y conforme al plan), amarillo (existen algunos problemas importantes, pero aún se sabe cómo resolverlos) o rojo (significa que el proyecto tiene serios problemas que pueden afectar a los plazos o al presupuesto originales).
El proyecto ágil también es diferente en este caso. En realidad no se hace un seguimiento del progreso hacia el objetivo. Más bien, usted resuelve las dependencias entre los diferentes equipos y tipos de actividades. El objetivo es asegurarse de que ningún equipo esté esperando a otro con las actividades en progreso.
Naturalmente, pueden aparecer riesgos, pero entonces la solución debe cambiar el plan de avance para que el riesgo desaparezca, en lugar de encontrar la solución al riesgo conservando el plan original.
En otras palabras, una configuración ágil del proyecto utiliza todas las formas posibles de cambiar el plan para no enfrentarse a los riesgos previstos, lo que significa que la gestión de riesgos es proactiva. En el caso de un proyecto en cascada, se responde a los riesgos retrospectivamente y se intenta resolverlos en el menor tiempo posible mientras se mantiene el plan original.
#6. Marco de ejecución
La táctica de implementación de los proyectos en cascada es obviamente menos problemática que la de los proyectos ágiles. Normalmente, la metodología en cascada es el statu quo que la gente ya ha practicado durante muchos años.
En cambio, los proyectos requieren prácticas de transformación ágiles para cambiar sus hábitos, su mentalidad y su forma de trabajar. Se trata de un proceso difícil y a menudo también bastante duradero. Las empresas invierten grandes cantidades de tiempo y recursos para enseñar a las personas a adaptarse a los procesos ágiles.
Los beneficios en forma de adaptación rápida a las necesidades cambiantes del cliente son significativos, pero cambiar la mentalidad de la gente y el entorno de trabajo en general es la parte más difícil.
La mayoría de las veces, también es la única forma de seguir siendo competente en el mercado, por lo que las compensaciones se ven recompensadas con un gran éxito para aquellos que lo consiguen.
Palabras finales
Digámoslo claramente. A menos que tenga un cliente muy conservador sin gran motivación para entregar resultados a la producción rápidamente (por las razones que pueda tener para ello), su mejor apuesta es empezar a modelar los equipos ágiles desde el principio. Esto es literalmente una obviedad en el mundo actual. Esto es cierto incluso en el caso de la configuración tradicional de sistemas locales. Especialmente si el equipo es nuevo o empieza de cero con gente original, sigue teniendo sentido transformar los procesos para alinearlos con las metodologías ágiles.
Dicho esto, sigo viendo proyectos en los que la gente simplemente se niega a seguir este tipo de proceso ágil o cualquier otra configuración que no sea la organización estricta del trabajo por fases. Siguen el camino habitual de contratar el trabajo por un tiempo y un presupuesto determinados. Entonces, esperan que el proyecto siga esta configuración sin desviaciones respecto al plan y al dinero (con diversos resultados, normalmente no buenos).
Es una decisión que tienen derecho a tomar, pero en última instancia, con tal decisión, también deciden quedarse en el pasado. Puede que les funcione durante algún tiempo, pero es sólo cuestión de tiempo que deje de funcionar.
A continuación, consulte el artículo detallado sobre el ciclo de vida de las pruebas ágiles.