Guías · Metodologías · Gestión de proyectos
Metodologías de desarrollo de software: ventajas y desventajas
CookiesJar SRL ·
Una metodología de desarrollo responde a tres preguntas: en qué orden se hace el trabajo, cada cuánto se entrega algo, y qué pasa cuando el cliente cambia de opinión.
Todas las demás diferencias salen de ahí. Esta guía recorre las que se usan, con sus ventajas y sus desventajas reales, y termina con el criterio para elegir.
El eje que las separa
Conviene entender el mapa antes que los nombres. Las metodologías se ordenan sobre una sola pregunta: ¿cuánto cuesta cambiar de opinión?
En un extremo están las predictivas: el alcance se define completo al principio, y cambiarlo después es caro. En el otro, las adaptativas o ágiles: el alcance se descubre trabajando, y el cambio es parte del método.
Ninguna es superior. Son respuestas a situaciones distintas.
Cascada (waterfall)
Las fases van en secuencia: requerimientos, diseño, construcción, pruebas, despliegue. Cada una termina antes de que empiece la siguiente.
| Ventajas | Desventajas |
|---|---|
| Alcance, costo y plazo definidos desde el inicio | El cliente no ve nada funcionando hasta el final |
| Documentación completa y trazable | Un error de requerimientos se descubre tardísimo |
| Se audita y se contrata por hitos sin fricción | Cambiar el alcance es costoso y lento |
| Funciona con equipos grandes y distribuidos | Asume que el cliente sabe lo que quiere desde el día uno |
Cuándo sirve: cuando el alcance está genuinamente definido y no se va a mover. Migraciones con especificación cerrada, integraciones con un contrato técnico fijo, proyectos con requisitos regulatorios que no admiten interpretación.
Modelo en V
Es cascada con las pruebas emparejadas a cada fase: a cada nivel de diseño le corresponde un nivel de verificación definido desde el principio.
| Ventajas | Desventajas |
|---|---|
| La calidad se planifica desde el inicio, no al final | Hereda la rigidez de cascada |
| Trazabilidad entre requisito y prueba | Costoso de mantener si los requisitos cambian |
| Muy usado en sistemas críticos | No entrega valor parcial |
Cuándo sirve: software donde una falla tiene consecuencias graves —dispositivos médicos, control industrial, sistemas embebidos.
Incremental e iterativo
Se construye por partes. En el modelo incremental cada entrega suma funcionalidad nueva; en el iterativo se refina lo mismo varias veces hasta que está bien.
| Ventajas | Desventajas |
|---|---|
| Hay algo utilizable desde temprano | Requiere una arquitectura que soporte crecer |
| El riesgo se reparte entre entregas | Puede degenerar en rehacer lo mismo sin avanzar |
| Se puede corregir el rumbo | El costo total es más difícil de fijar al principio |
Espiral
Organiza el proyecto en ciclos y cada ciclo empieza analizando riesgos. Solo se avanza a la siguiente vuelta si el riesgo evaluado lo justifica.
| Ventajas | Desventajas |
|---|---|
| Los riesgos se atacan primero, no al final | Pesado para proyectos pequeños |
| Sirve cuando hay incertidumbre técnica alta | Exige experiencia real en análisis de riesgo |
| Permite abandonar temprano si no es viable | Difícil de presupuestar de forma cerrada |
Cuándo sirve: cuando existe una duda técnica que puede hundir el proyecto y conviene resolverla antes de construir alrededor de ella.
Scrum
El marco ágil más extendido. El trabajo se organiza en sprints de duración fija, con una lista priorizada de pendientes, una reunión diaria corta, y una revisión y una retrospectiva al cerrar cada sprint.
| Ventajas | Desventajas |
|---|---|
| Al final de cada sprint hay algo que se puede usar | El costo total no queda fijo desde el inicio |
| El cliente reprioriza en cada ciclo | Exige disponibilidad real del cliente, no una firma inicial |
| Los problemas salen a la superficie temprano | Sin disciplina, degenera en reuniones sin entrega |
| La estimación mejora con la historia del equipo | Difícil de aplicar con equipos que rotan constantemente |
El malentendido más común: ágil no significa sin plan ni sin documentación. Significa que el plan se revisa con evidencia en la mano en vez de defenderlo contra la realidad.
Kanban
No tiene iteraciones fijas. Se visualiza el flujo de trabajo en un tablero y se limita el trabajo en curso: no se empieza algo nuevo hasta que se termina lo que está en progreso.
| Ventajas | Desventajas |
|---|---|
| Se adapta a trabajo que llega sin previsión | Sin fechas de corte, cuesta comprometer plazos |
| Hace visibles los cuellos de botella | Poca estructura para planificar a largo plazo |
| Se implanta sobre el proceso actual, sin reorganizar | Requiere disciplina para respetar los límites |
Cuándo sirve: mantenimiento, soporte, mesas de servicio. Todo lo que es un flujo continuo y no un proyecto con final.
Programación extrema (XP)
Se centra en prácticas técnicas: programación en pareja, pruebas antes que el código, integración continua, refactorización constante, entregas muy frecuentes.
| Ventajas | Desventajas |
|---|---|
| Calidad técnica alta y deuda técnica baja | Exige un nivel de disciplina que no todo equipo tiene |
| Cambios baratos gracias a la cobertura de pruebas | La programación en pareja es difícil de vender al cliente |
| Retroalimentación casi inmediata | Poco adecuado para equipos muy grandes |
Comparación rápida
| Metodología | Alcance | Entregas | Costo del cambio | Mejor para |
|---|---|---|---|---|
| Cascada | Cerrado | Una, al final | Alto | Requisitos fijos y auditables |
| Modelo en V | Cerrado | Una, verificada por fase | Alto | Sistemas críticos |
| Incremental | Abierto por partes | Por incremento | Medio | Productos que crecen |
| Espiral | Guiado por riesgo | Por ciclo | Medio | Incertidumbre técnica alta |
| Scrum | Abierto | Por sprint | Bajo | Producto en evolución |
| Kanban | Continuo | Continua | Bajo | Soporte y mantenimiento |
| XP | Abierto | Muy frecuente | Muy bajo | Equipos técnicos maduros |
Cómo se elige de verdad
En la práctica, la elección se reduce a una pregunta: ¿el alcance está definido o se está descubriendo?
Si está definido, un método predictivo entrega por hito, cada hito tiene un resultado comprobable, y el precio puede cerrarse por alcance con un proceso de control de cambios —de forma que cualquier agregado se cotice y se apruebe antes de construirlo.
Si se está descubriendo, un método ágil con sprints de dos a cuatro semanas deja algo utilizable al final de cada uno, y la prioridad se revisa con el sistema delante.
Así lo decidimos nosotros: la metodología se elige en el diagnóstico, según el proyecto, y no al revés.
Ese criterio da un reparto bastante desigual. Cerca del 80% de nuestros proyectos terminan en ágil. Conviene decir de qué depende y de qué no: no depende del tipo de cliente —no existen clientes «de cascada» y clientes «de Scrum»— sino del tipo de proyecto y de cuánta información hay sobre él al empezar. Y esa información suele ser menos de la que parece, porque casi nadie llega describiendo un problema: llegan describiendo la solución que creen que necesitan. Ahí es donde un alcance cerrado por adelantado se vuelve una apuesta.
Lo que no cambia en ninguno de los dos casos es que el cliente vea avances desde temprano. Un proyecto donde nadie ve nada hasta el final es un proyecto que va a terminar mal, con cualquier metodología del cuadro de arriba.
Errores que se repiten
Elegir la metodología por moda. Ágil en un proyecto con alcance fijo y presupuesto público añade ceremonia sin beneficio.
Usar cascada para descubrir. Si nadie sabe todavía cómo debe funcionar el proceso, escribir cien páginas de requerimientos solo documenta suposiciones.
Adoptar el vocabulario sin las prácticas. Llamar «sprint» a dos semanas de trabajo sin entrega, sin revisión y sin retrospectiva es cascada con nombres nuevos.
Cambiar de metodología a mitad de proyecto. Casi siempre es síntoma de otro problema, y rara vez lo resuelve.
Y después de elegir el método
Falta lo demás: quién lo ejecuta —con equipo propio o con desarrolladores externos— y, antes que eso, qué se construye primero, que es una decisión de estrategia y no de calendario.
Datos clave de este análisis
- Las metodologías de desarrollo se ordenan según cuánto cuesta cambiar el alcance: predictivas en un extremo, adaptativas o ágiles en el otro.
- Cascada define alcance, costo y plazo desde el inicio, a cambio de que el cliente no vea software funcionando hasta el final.
- El modelo en V empareja cada fase de diseño con un nivel de prueba y se usa en sistemas críticos.
- El modelo en espiral organiza el proyecto en ciclos que empiezan por el análisis de riesgos.
- Scrum entrega en sprints de duración fija con algo utilizable al cierre de cada uno; Kanban trabaja en flujo continuo limitando el trabajo en curso.
- La programación extrema se apoya en prácticas técnicas —pruebas primero, integración continua, refactorización— para abaratar el cambio.
- El criterio práctico de elección es si el alcance está definido o se está descubriendo; en CookiesJar la metodología se decide en el diagnóstico, con sprints de dos a cuatro semanas en ágil y entregas por hito en predictivo.
- Cerca del 80% de los proyectos de CookiesJar se ejecutan con metodología ágil.
- La metodología se elige por el tipo de proyecto y por cuánta información se tiene de él al empezar, no por el tipo de cliente.