Cascada o Scrum: cómo elegir la forma de ejecutar su proyecto

En casi todas las primeras pláticas aparece la misma pregunta, a veces dicha y a veces no: ¿esto lo van a hacer en cascada o ágil? Detrás suele haber una experiencia previa. O un proyecto en cascada que entregó, un año después, algo que ya no servía; o un proyecto «ágil» que nunca terminó porque cada sprint cambiaba de rumbo.

Las dos funcionan; lo que falla es pedirle a una integración con el sistema central que se descubra en el camino, o a un canal digital que se firme por fases. La elección depende de tres cosas: qué tan definido está el alcance, quién puede priorizar y cómo se va a aceptar cada entrega. Este artículo es para elegir bien.

La pregunta que decide

Antes de hablar de etapas o ceremonias, conteste esto: ¿puede escribir hoy, con suficiente precisión, qué tiene que hacer el sistema cuando esté terminado?

• Si sí —porque lo dicta una norma, un contrato, un proceso que ya existe o un sistema que se va a reemplazar—, conviene avanzar por etapas. El valor está en no equivocarse, y cada etapa reduce el riesgo de la siguiente.
• Si no —porque es un producto nuevo, un canal digital o una idea que hay que probar con usuarios—, conviene avanzar por ciclos cortos. El valor está en aprender rápido, y cada ciclo corrige el rumbo con lo que ya se vio.

Hay otras señales que empujan hacia un lado:

Por etapas: modelo en V

Es una cascada: seis etapas, una tras otra, cada una con un entregable que se revisa antes de pasar a la siguiente. Lo que lo convierte en un modelo en V es cuándo se definen las pruebas: no al final, sino desde el principio.

Son seis etapas:

1. Origen. Se escribe la necesidad de negocio como una historia: qué se quiere lograr, por qué, sus límites y quién decide. Parece trámite y es lo más barato del proyecto: aquí un malentendido cuesta una conversación; más adelante, el mismo malentendido cuesta retrabajo.
2. Análisis. Se mide lo que existe: procesos, sistemas, datos y reglas, incluidas las que solo conoce una persona del equipo. En los sistemas viejos esta etapa es la que más sorprende, porque suelen aparecer reglas que nadie había escrito.
3. Diseño. Primero se modela el negocio y después la tecnología. A eso se le llama diseño guiado por el dominio (DDD): las piezas del sistema llevan los nombres y las fronteras del negocio, no las de la base de datos. De aquí salen la arquitectura, las matrices de reglas y los casos de prueba con su resultado esperado. Ese es el punto que más le importa a quien paga: desde el diseño ya sabe contra qué va a aceptar.
4. Construcción. Se programa contra esa matriz. Cada pieza llega con sus pruebas unitarias y, cuando se conecta con otro sistema, con pruebas de esa conexión que cualquiera puede volver a correr, como colecciones de Postman o scripts, sin depender de nosotros. Esas pruebas se quedan con el cliente.
5. Pruebas. Dos pasadas distintas. En la de calidad (QA), una revisión independiente de quien programó corre la matriz completa. En la de aceptación (UAT), la gente del cliente valida en su propio ambiente, con sus casos reales. Que no lo pruebe quien lo hizo no es desconfianza: quien programó ya decidió qué era importante, y por eso no ve lo que dejó fuera.
6. Liberación. Puesta en operación con un plan de regreso acordado, manual de uso y de operación, y acompañamiento en los primeros días.

Por qué se llama «en V»

En una cascada llevada de forma lineal, las pruebas suelen concentrarse después de construir, cuando un error ya es caro. En el modelo en V, cada prueba se define en la etapa que la origina y se ejecuta más adelante: las unitarias y las de integración durante la construcción; la matriz de calidad y la aceptación, en la etapa de pruebas, antes de liberar. La V es por la forma de la letra, no un número:

Dibujado, la ida (origen, análisis, diseño, construcción) baja por un lado de la letra V y las pruebas suben por el otro, cada una frente a la etapa que comprueba. Es el modelo que preferimos donde un error cuesta caro, porque cada requisito queda ligado a las pruebas que lo comprueban. Lo usamos en versión ligera: sin documentación que no aporta.

Lo que pide de usted: tiempo en el origen y en el análisis, y la firma de la matriz de pruebas en el diseño. Si eso se hace bien, la construcción requiere menos de su tiempo, salvo decisiones o cambios relevantes.

Su riesgo: que el negocio cambie mientras se construye. Se mitiga con etapas cortas: es mejor entregar en tramos de semanas que un solo bloque de un año.

Por ciclos: Scrum

Scrum organiza el trabajo en sprints de una a cuatro semanas; nosotros preferimos dos o tres. En cada uno se entrega un incremento terminado y probado, no avances en una presentación.

Las ceremonias son pocas y cada una tiene un para qué:

• Planeación del sprint. Todo el equipo acuerda el objetivo del ciclo, y quienes construyen eligen, de la lista priorizada, lo que pueden terminar para cumplirlo.
• Reunión diaria. Quince minutos del equipo para revisar cómo va contra el objetivo del sprint y ajustar el plan del día. Sirve para destrabar, no para informar a un jefe.
• Revisión del sprint. Una sesión de trabajo con lo construido funcionando, junto a quien lo va a usar; con lo que se aprende, el responsable de producto ajusta la lista.
• Retrospectiva. El equipo revisa cómo trabajó y cambia una o dos cosas para el siguiente ciclo.

Y dos cosas que hay que cuidar: la lista priorizada (backlog), cuyo orden decide el responsable de producto y que está a la vista de todos, y la definición de terminado, que describe la calidad que debe cumplir cada incremento para darlo por terminado; cada historia, además, entra con sus propios criterios de aceptación.

Lo que pide de usted: un responsable de producto con tiempo y con autoridad para decidir. Es el requisito que más se subestima. Sin esa persona, Scrum se convierte en un equipo que entrega cada dos semanas cosas que nadie revisa.

Su riesgo: confundir ágil con improvisado. Ágil no quita las pruebas ni los criterios de aceptación: cada historia entra con los suyos y sale con sus pruebas, igual que por etapas.

Cuando conviene usar las dos

En la práctica, muchos proyectos grandes tienen las dos naturalezas. Una aseguradora que lanza un canal digital de venta necesita por etapas la integración con su core de pólizas y con el ERP, donde un error cuesta dinero y regulación. Y necesita por ciclos la experiencia del cliente en el canal, que sólo se acierta probando con usuarios.

Se pueden combinar sin caos con tres reglas:

1. Una frontera clara. Las interfaces entre las dos partes se diseñan y se congelan por etapas; detrás de esa frontera, cada lado avanza a su ritmo.
2. Un solo responsable que vea las dos partes y las ponga en el mismo calendario.
3. La misma vara de calidad. Las dos partes se aceptan contra pruebas escritas antes de construir cada pieza.

El espacio compartido

Una metodología rinde poco si las preguntas tardan una semana en llegar a quien las resuelve. Por eso, sea por etapas o por ciclos, conviene trabajar en espacios compartidos desde el primer día: un canal de conversación directa con el equipo que construye (Slack, Microsoft Teams o el que ya use su empresa) y un tablero donde se vean las tareas, sus responsables y su estado (ClickUp, Jira u otro). Así el cliente ve el proyecto en vivo, no en un informe al final, y las decisiones quedan escritas con fecha y con quién las aprobó.

Cómo decidir en su caso

Una regla práctica: repase la tabla del principio. Si la mayoría de sus respuestas cae en una columna, empiece por esa forma; si se reparten, probablemente le conviene combinarlas. Y si todavía no sabe cuál le conviene, es normal: la respuesta depende de qué parte de su proyecto pesa más. En una primera plática lo revisamos con usted y le decimos cómo lo ejecutaríamos, tramo por tramo.