Hace unos meses, un cliente me dijo algo que todavía sigo pensando. "Quiero darle la especificación, desaparecer tres meses, y volver a buscar un producto terminado. ¿Por qué tenemos que hablar cada dos semanas?"

Es una pregunta válida, y rara vez se explica bien desde el principio. La mayoría se imagina el software como la construcción de una casa: uno acuerda el plano, el contratista construye, y uno aparece al final a buscar las llaves. Por eso, cuando un desarrollador pide una llamada cada dos semanas para revisar trabajo sin terminar, puede sentirse como si el equipo estuviera desorganizado, o como si estirara el plazo a propósito.

La razón real tiene un nombre: metodología de desarrollo, el ritmo que usa un equipo para llevar un proyecto desde la idea hasta el producto terminado. Los dos ritmos más comunes, Agile y Waterfall, generan experiencias muy distintas para usted como cliente. Veamos qué significa cada uno realmente, y por qué su proyecto probablemente terminó usando el que usa.

Qué Significa Realmente Waterfall

Waterfall coincide con la imagen de construir una casa. Se planifica todo el proyecto por adelantado: cada pantalla, cada función, cada regla. Una vez que todos aprueban ese plan, el equipo avanza en orden, una etapa a la vez: requisitos, diseño, construcción, pruebas, y al final una sola entrega. Cada etapa tiene que terminar antes de que empiece la siguiente, igual que no se pueden pintar paredes que todavía no se construyeron.

El atractivo es obvio: un precio claro, un cronograma claro, una fecha de entrega. Pero tiene una contrapartida. Una vez que el plan queda cerrado, cambiar de opinión sale caro. Si en el cuarto mes uno se da cuenta de que los clientes necesitan un proceso de pago distinto al de la especificación original, eso suele significar reabrir trabajo que ya estaba terminado y aprobado.

Qué Significan Realmente Agile y los "Sprints"

Agile invierte el orden. En lugar de planificar todo por adelantado y construirlo de una sola vez, el equipo divide el proyecto en partes pequeñas, generalmente períodos de dos semanas llamados sprints, y construye una porción funcional del producto en cada uno. Al final de cada sprint, usted ve algo real: una pantalla que puede recorrer, una función que puede probar. Da su opinión, el equipo ajusta, y empieza el siguiente sprint.

Eso son realmente esas llamadas cada dos semanas: no actualizaciones de estado porque sí, sino el momento en el que usted puede decir "en realidad no era eso lo que quería decir" mientras el ajuste todavía cuesta unos días de trabajo, en vez de descubrirlo al final, cuando hay que rehacer todo.

Agile también asume algo que Waterfall no asume: que nadie, ni usted tampoco, conoce cada requisito a la perfección el primer día. Las necesidades del negocio cambian, aparece un competidor con algo nuevo, y una función que sonaba esencial en la reunión de planificación termina sin importar tanto una vez que los usuarios reales la prueban. Agile deja espacio para esa realidad dentro del proceso mismo, en lugar de tratarla como un problema.

Por Qué la Mayoría de los Proyectos Modernos Se Inclinan Hacia Agile

La mayoría de las aplicaciones web y móviles de hoy se construyen con alguna versión de Agile, y no es solo una moda. El software es inusualmente fácil de modificar comparado con un edificio físico, así que los equipos naturalmente prefieren un enfoque que aproveche esa flexibilidad. Las revisiones frecuentes detectan una suposición equivocada en la segunda semana en lugar del cuarto mes, cuando todavía es barato corregirla.

También hay un beneficio de confianza. Con Waterfall, básicamente se apuesta todo el presupuesto a un plan escrito antes de que existiera una sola línea de código, y después se espera meses para ver si era correcto. Con Agile, usted ve partes funcionales desde temprano y con frecuencia, así que siempre sabe en qué punto está realmente el proyecto.

Cuándo Waterfall Todavía Tiene Sentido

Waterfall no está obsoleto, y todavía lo recomiendo en situaciones puntuales. Funciona bien cuando los requisitos son genuinamente fijos, como software construido para cumplir con una norma regulatoria definida por alguien externo al proyecto. También funciona cuando un proyecto depende mucho de hardware, instalación física, u otros proveedores con cronogramas propios muy rígidos, donde cambiar de rumbo a mitad de camino sale caro sin importar la metodología. Y algunos clientes prefieren genuinamente un alcance y un precio fijos por sobre la flexibilidad, una decisión razonable si se toma con los ojos abiertos.

Muchos proyectos reales terminan siendo una mezcla de los dos. Yo suelo usar un enfoque estilo Waterfall para fijar el alcance, el presupuesto, y un cronograma aproximado al principio, y después entrego la construcción en sí mediante sprints de Agile, porque ahí es donde más importa la flexibilidad. Esto se relaciona con lo que explico sobre la etapa de descubrimiento de un proyecto de software — esa conversación inicial es donde decidimos juntos qué ritmo le conviene a su proyecto, antes de empezar a construir nada.

Qué Significa Esto Para Cuánto Tendrá Que Involucrarse

Acá está la contrapartida honesta. Waterfall exige menos tiempo durante la construcción, pero más atención al principio, porque cada requisito tiene que quedar definido antes de empezar, y cualquier vacío en esa planificación se convierte después en una sorpresa costosa. Agile exige menos al principio, pero más atención continua, porque esas revisiones cada dos semanas solo funcionan si alguien de su lado realmente participa con una opinión real.

Ninguno de los dos representa más trabajo en total, solo distribuido de manera distinta a lo largo del cronograma. Si alguna vez probó una versión más pequeña de una idea antes de comprometerse con la construcción completa, ya vio este patrón; es la misma lógica detrás de qué es realmente un MVP, donde la opinión temprana ahorra dinero más adelante.

Un Ejemplo Real

Trabajé con un cliente de una pequeña empresa de logística que quería un portal para que sus choferes registraran entregas. Al principio, estaban seguros de saber exactamente qué necesitaban los choferes. Igual usamos Agile, y para el tercer sprint, los choferes que probaban el portal dijeron que la pantalla de confirmación necesitaba una opción para subir una foto, algo que nadie había mencionado antes, porque los recibos de papel se perdían dentro del camión. Como ya revisábamos software funcional cada dos semanas, agregamos esa opción en el siguiente sprint por unos pocos cientos de dólares extra. Con Waterfall, ese vacío recién habría salido a la luz en las pruebas finales, meses después, con todo el flujo de confirmación ya construido y aprobado.

La Conclusión

Esas llamadas cada dos semanas no son una señal de que su proyecto se está alargando ni de que su desarrollador no puede comprometerse con un plan. Están integradas en el proceso para detectar malentendidos pequeños mientras todavía son baratos de corregir. Si su proyecto usa Agile, presentarse a esas revisiones con una opinión real es una de las cosas más valiosas que puede hacer por el resultado final.

Si está planificando un proyecto y no está seguro de qué enfoque le conviene, es exactamente el tipo de cosa que vale la pena conversar antes de empezar a trabajar. Hablemos de su situación.