Metodologías de desarrollo de software: cuál conviene según tu proyecto

Si vas a contratar un desarrollo de software, tarde o temprano alguien te va a decir que trabaja «con metodologías ágiles». Casi todos lo dicen. La frase, por sí sola, no te dice mucho.

Lo que de verdad importa de una metodología, desde el lado de quien paga, es otra cosa: cuándo vas a ver algo funcionando, quién decide cuando hay que cambiar algo y en qué momento te enteras de que el proyecto va mal. Este artículo explica las metodologías más usadas con esa mirada, no con la de un examen.

Las etapas que tiene cualquier proyecto

Todas las metodologías recorren las mismas etapas. Lo que cambia es el orden y cuántas veces se repiten.

1. Descubrimiento. Entender el problema, a los usuarios, el proceso actual, los datos y las restricciones.
2. Diseño y arquitectura. Definir módulos, roles, reglas, integraciones y cómo se va a comprobar que algo funciona.
3. Construcción. Diseñar las pantallas y escribir el código.
4. Pruebas. Verificar que el sistema hace lo que debe, incluidas las excepciones.
5. Despliegue. Ponerlo a funcionar con la operación real.
6. Mantenimiento y evolución. Corregir, ajustar y agregar lo que el uso real vaya mostrando.

Una metodología secuencial pasa por estas etapas una sola vez, en orden. Una iterativa las recorre muchas veces, en ciclos cortos, con un pedazo del sistema cada vez.

Cascada: todo definido antes de empezar

En cascada cada etapa termina antes de que empiece la siguiente. Primero se escriben todos los requisitos, luego se diseña todo, luego se construye todo y al final se prueba.

Cuándo conviene. Cuando los requisitos son estables y verificables desde el inicio: una migración con origen y destino claros, un cambio exigido por una norma, una integración con una especificación cerrada.

El riesgo. Ves el sistema completo hasta el final. Si un requisito estaba mal entendido, lo descubres cuando ya está construido, y corregirlo cuesta caro.

Ágil: una forma de trabajar, no un método

«Ágil» no es una metodología concreta. Es una familia de métodos que comparten los principios del Manifiesto Ágil, publicado en 2001. Sus cuatro valoraciones son: individuos e interacciones sobre procesos y herramientas; software funcionando sobre documentación extensiva; colaboración con el cliente sobre negociación contractual; y respuesta ante el cambio sobre seguir un plan. El propio manifiesto aclara que valora los elementos de la derecha, pero más los de la izquierda (Manifiesto por el Desarrollo Ágil de Software).

Ese matiz se olvida seguido. Ágil no significa «sin documentación» ni «sin plan». Significa que, cuando hay que elegir, gana el software que funciona y la capacidad de corregir el rumbo.

Scrum

Es el método ágil más conocido. El trabajo se divide en iteraciones cortas, de pocas semanas, y al final de cada una se revisa algo que funciona. Hay un responsable del producto que decide qué se construye primero.

Cuándo conviene. Proyectos nuevos donde el alcance se va a ir aclarando con el uso, y donde tienes a alguien de tu lado con tiempo y autoridad para decidir en cada revisión.

El riesgo. Si nadie de tu empresa puede participar en las revisiones, Scrum se convierte en una serie de demos que nadie valida.

Kanban

No trabaja por iteraciones sino por flujo. Las tareas pasan por columnas —pendiente, en curso, en revisión, terminado— y se limita cuántas puede haber en curso a la vez.

Cuándo conviene. Mantenimiento, soporte y evolución de un sistema que ya existe, donde las peticiones llegan de forma continua y con prioridades que cambian.

El riesgo. Sin una dirección clara, el sistema crece por acumulación de pedidos sueltos y no por decisiones.

Lean y producto mínimo

La idea es construir la versión más pequeña que permita probar la parte más importante del sistema, medir y decidir con datos qué sigue.

Cuándo conviene. Cuando no está claro que la solución vaya a funcionar o a adoptarse, y prefieres averiguarlo con poco antes de invertir mucho.

En la práctica, casi todo es híbrido

Pocos proyectos serios usan un método puro. Lo más común, y lo que nosotros hacemos, es combinar: una parte inicial más ordenada para entender el problema y definir la arquitectura, y después construcción por incrementos que se prueban con la operación real.

Nuestro proceso en software a medida tiene siete pasos: descubrimiento; arquitectura; alcance inicial; construcción con diseño, desarrollo, QA y demostraciones sobre entregables verificables; integración y datos; prueba con operación real; y despliegue y evolución. Los dos primeros reducen incertidumbre antes de gastar en código. Los siguientes se repiten por incrementos. La regla de fondo es simple: reducir incertidumbre antes de ampliar alcance.

Una metodología no se elige por su nombre. Se elige por dónde está el riesgo de tu proyecto.

Cuál conviene según tu proyecto

Una forma rápida de orientarte:

• El alcance está cerrado y no va a cambiar. Cascada, o una secuencia muy parecida.
• Es un sistema nuevo y el alcance se va a ir aclarando. Iterativo, con revisiones frecuentes y alguien de tu lado que decida.
• No sabes si la solución va a funcionar o a adoptarse. Empieza por el incremento mínimo que lo compruebe.
• El sistema ya existe y llegan peticiones continuas. Flujo tipo Kanban, con prioridades explícitas.
• El proceso todavía no está claro ni para tu equipo. Ninguna metodología lo arregla. Primero hay que ordenar el proceso.

Lo que ninguna metodología resuelve

Hay problemas que no dependen del método. Si nadie en tu empresa puede validar decisiones, si el alcance cambia cada semana sin que nadie lo decida o si el proceso que se quiere digitalizar no está descrito, el proyecto se va a complicar con cascada, con Scrum o con cualquier otra cosa. En esos casos el trabajo previo es de operación, no de tecnología.

Qué preguntarle a un proveedor

Antes de firmar, estas preguntas dicen más que el nombre de la metodología:

1. ¿Cada cuánto voy a ver algo funcionando? Y si es verificable, o sólo una presentación.
2. ¿Quién de mi lado tiene que participar, y cuánto tiempo? Un proyecto iterativo sin tu tiempo no funciona.
3. ¿Cómo se manejan los cambios de alcance? Quién los aprueba y cómo afectan costo y fecha.
4. ¿Cómo se prueba con usuarios reales? No sólo si el código funciona, sino si la operación lo adopta.
5. ¿Qué entregables recibo al final? Documentación, accesos, criterios de aceptación y soporte.
6. ¿De quién es el código y de quién son los datos? Debe quedar escrito en la propuesta y en el contrato, no supuesto.

Si un proveedor puede contestar las seis con claridad, la metodología que use importa menos. Si no puede, ninguna metodología lo va a salvar.

Si quieres revisar tu caso antes de cotizar, empieza por una evaluación operativa: sirve para decidir si conviene construir, integrar o configurar, y por dónde empezar.