Computación en la Nube — Unidad 4

Metodologías Ágiles y Ciclo de Vida del Software

Las tres unidades anteriores describieron qué es la nube, cómo se construye por debajo y qué leyes la gobiernan. Esta unidad cambia el foco: en vez de hablar de la tecnología, hablamos del proceso con el que los equipos producen software para correr en esa tecnología. Vamos a recorrer los modelos clásicos del ciclo de vida del software, entender por qué la industria los abandonó casi en masa a favor del enfoque ágil, y ver cómo esa transición prácticamente coincide con la adopción de la nube.

1. ¿Por qué hablar de metodologías en un curso de nube?

Podría parecer que el ciclo de vida del software es un tema aparte, pertenece a una materia distinta. Pero en la Unidad 3 vimos la Ley de Conway: la arquitectura del sistema refleja la estructura de comunicación del equipo que lo construye. Esa ley tiene un corolario directo y poco discutido: la arquitectura también refleja el proceso con el que el equipo trabaja. Un equipo que despliega una vez por trimestre no produce microservicios independientes; los necesita acoplados para poder coordinarlos. Un equipo que despliega varias veces por día casi inevitablemente termina con componentes pequeños y autónomos.

La nube y las metodologías ágiles crecieron juntas durante las últimas dos décadas porque resuelven, en planos distintos, el mismo problema: cómo construir y operar software complejo sin colapsar bajo su propio peso. La nube aporta la infraestructura elástica; el agilismo aporta la forma de trabajo capaz de aprovecharla. Sin una metodología iterativa, una arquitectura cloud-native termina desperdiciada; sin nube, una metodología ágil choca contra los tiempos de aprovisionamiento de hardware.

2. El ciclo de vida del software, brevemente

Construir software no es una actividad puntual sino un proceso continuo que arranca antes de la primera línea de código y termina (si es que termina) bastante después de la última. La industria llama ciclo de vida del software (SDLC, Software Development Life Cycle) al conjunto de fases que recorre una pieza de software desde su concepción hasta su retiro: definición de requisitos, análisis, diseño, implementación, prueba, despliegue, operación y mantenimiento, y eventualmente decomisado.

Lo que varía entre metodologías no son las fases en sí —cualquier proyecto real las atraviesa todas, le guste o no— sino cómo se ordenan y cuán rígida es la frontera entre ellas. Las metodologías tradicionales tratan al ciclo como una secuencia: terminada una fase, se pasa a la siguiente y no se vuelve atrás. Las metodologías modernas tratan al ciclo como un bucle: cada fase informa a las demás, y se atraviesan todas muchas veces en pequeñas iteraciones.

3. Los modelos clásicos

Cascada

El modelo cascada (waterfall) fue formalizado por Winston Royce en 1970, aunque, dato curioso, su paper original lo presentaba como un anti-patrón, no como una recomendación. Royce describía el modelo lineal —requisitos, diseño, implementación, prueba, despliegue— y explicaba inmediatamente por qué casi nunca funciona en proyectos reales. La industria, sin embargo, leyó la primera mitad del paper y adoptó la cascada como buena práctica durante las siguientes tres décadas.

La promesa de la cascada es seductora: si planificamos todo bien al principio, la ejecución se vuelve previsible. La realidad demostró que los requisitos del software cambian constantemente, que el diseño no se puede pensar completamente sin codificar, y que los errores detectados al final cuestan exponencialmente más que los detectados al principio. La cascada sigue siendo razonable en proyectos donde los requisitos son verdaderamente estables y conocidos —construir un compilador para un estándar publicado, por ejemplo, o software embebido con certificación regulatoria— pero esos casos son la excepción, no la regla.

Modelo V

El modelo V es esencialmente una cascada plegada por la mitad. A cada fase de desarrollo (requisitos, diseño de sistema, diseño detallado, código) le corresponde una fase de validación simétrica (pruebas de aceptación, integración, unitarias). Su mérito fue institucionalizar la idea de que cada decisión de diseño implica un nivel correspondiente de pruebas. Sigue siendo común en industrias con requisitos de certificación estricta —aeroespacial, médica, ferroviaria— donde la trazabilidad entre requisito y prueba es un requerimiento legal.

Modelo iterativo e incremental

Los modelos iterativo e incremental ya rompen con la linealidad: en lugar de construir todo el sistema de una vez, se construyen versiones sucesivas, cada una más completa o más refinada que la anterior. Boehm propuso en 1986 el modelo espiral, que combina iteraciones con análisis de riesgo: cada vuelta de la espiral identifica y mitiga los riesgos más graves antes de avanzar. Estas ideas fueron la base intelectual del movimiento ágil, aunque tomaron veinte años en volverse mainstream.

4. El cambio: el Manifiesto Ágil

En febrero de 2001, diecisiete profesionales del desarrollo de software se reunieron en una estación de esquí en Snowbird, Utah. Venían de metodologías distintas —algunos de Extreme Programming, otros de Scrum, otros de Crystal o DSDM— pero compartían el diagnóstico: las metodologías pesadas y documentadas heredadas de los 80 estaban produciendo software malo, tarde y caro. Tres días después salieron de ahí con un texto breve que cambió la industria: el Manifiesto por el Desarrollo Ágil de Software.

Concepto clave

Los cuatro valores del Manifiesto Ágil (Snowbird, 2001).

El Manifiesto declara que, aunque hay valor en los elementos de la derecha, los firmantes valoran más los de la izquierda:

Valor 1Individuos e interacciones sobre procesos y herramientas.

Valor 2Software funcionando sobre documentación extensiva.

Valor 3Colaboración con el cliente sobre negociación contractual.

Valor 4Respuesta ante el cambio sobre seguir un plan.

Para tener en cuenta

• La frase "aunque hay valor en los elementos de la derecha" suele olvidarse: el manifiesto no dice que la documentación o los contratos sean malos, sino que cuando haya conflicto, gana lo de la izquierda.

El Manifiesto va acompañado de doce principios que lo explicitan. Sin enumerarlos todos, los más influyentes para el desarrollo en la nube son: la satisfacción del cliente mediante entregas tempranas y continuas; la bienvenida a cambios en los requisitos, incluso tarde en el desarrollo; la entrega frecuente de software funcionando en escalas de semanas, no meses; y la simplicidad —entendida como el arte de maximizar la cantidad de trabajo no hecho— como esencial. Si esa última frase suena a la Ley de Gall de la unidad anterior, no es coincidencia: el agilismo bebe directamente de esa tradición.

Es importante separar el agilismo como filosofía de los frameworks concretos que se inspiran en él. El Manifiesto no menciona Sprints, ni standups, ni Product Owners, ni story points. Esos son artefactos de Scrum, no del agilismo. Muchos equipos "hacen Scrum" sin entender el Manifiesto, lo que produce un teatro ceremonial sin ganancia real.

5. Scrum

Scrum es, por amplio margen, el framework ágil más adoptado de la historia. Fue formalizado a comienzos de los 90 por Ken Schwaber y Jeff Sutherland, inspirado en un paper de Takeuchi y Nonaka de 1986 ("The New New Product Development Game") que comparaba a los equipos de producto eficientes con un equipo de rugby avanzando en formación —de ahí el nombre, que significa "melé". La Scrum Guide oficial, mantenida por Schwaber y Sutherland, se reescribe cada pocos años y es notablemente breve: la última versión cabe en quince páginas.

Scrum organiza el trabajo en Sprints: iteraciones de duración fija, típicamente de dos semanas, durante las cuales el equipo produce un incremento de producto potencialmente entregable. La duración es fija para crear ritmo y predictibilidad; el contenido es variable, se ajusta a la realidad. Cada Sprint atraviesa las cuatro fases del ciclo de vida en miniatura: planificación, ejecución (que incluye diseño, código y prueba simultáneamente), entrega e inspección.

Roles

Scrum define tres roles, ni más ni menos. El Product Owner es responsable de maximizar el valor del producto: prioriza el backlog, decide qué se hace y qué no, y es la única persona con autoridad para cambiar prioridades durante la planificación. El Scrum Master no es un gerente ni un coordinador: es un facilitador que se encarga de que el proceso se respete, que el equipo no se distraiga y que los impedimentos se resuelvan. Los Developers (en la guía actual, sin más jerarquía) son las personas que construyen el incremento; el equipo es auto-organizado y multidisciplinario.

Eventos

Los rituales de Scrum son pocos y específicos. Cada uno tiene un propósito bien definido y un timebox máximo; cuando se respetan, sostienen el ritmo, cuando se relajan, el framework se desmorona en reuniones interminables.

Los cinco eventos de un Sprint

1. Sprint Planning. Al inicio del Sprint, el equipo decide qué entrega y cómo. Timebox: hasta 8 h para Sprints de un mes; proporcionalmente menos para Sprints más cortos.
2. Daily Scrum. 15 minutos diarios, mismo lugar y hora. El equipo sincroniza, identifica impedimentos y ajusta el plan del día. No es un reporte de status: es coordinación entre pares.
3. Sprint. El bloque de trabajo en sí, donde se construye el incremento. No es un evento, es el contenedor de todos los demás.
4. Sprint Review. Al final del Sprint, se muestra el incremento a stakeholders y se recibe feedback. Es una conversación, no una presentación.
5. Sprint Retrospective. El último evento del Sprint, antes del próximo Planning. El equipo inspecciona cómo trabajó, no qué construyó, y acuerda mejoras concretas.

Artefactos

Scrum tiene tres artefactos. El Product Backlog es la lista priorizada de todo lo que podría hacerse en el producto, propiedad del Product Owner. El Sprint Backlog es el subconjunto que el equipo se compromete a hacer en el Sprint actual. El Incremento es la suma de todos los elementos completados en el Sprint, sumados a los anteriores, que cumplen la Definition of Done (DoD): el conjunto de criterios que determinan cuándo algo se considera realmente terminado, no solo "funcionando en mi máquina".

6. Kanban

Si Scrum nació en la industria del software, Kanban nació en una fábrica. Toyota lo desarrolló en los 50 como parte de su sistema de producción (Toyota Production System) para visualizar el flujo de trabajo y limitar el inventario en curso. David Anderson lo adaptó al desarrollo de software a fines de los 2000, manteniendo sus principios centrales: visualizar el trabajo, limitar el trabajo en progreso y gestionar el flujo.

A diferencia de Scrum, Kanban no impone iteraciones de duración fija ni roles especiales. El equipo mantiene un tablero (físico o digital) con columnas que representan los estados del trabajo —típicamente "por hacer", "en progreso", "en revisión", "hecho"— y mueve las tareas de izquierda a derecha. La regla central es el WIP limit (work in progress): cada columna tiene un máximo de tareas que puede contener. Si la columna está llena, no se puede empezar nada nuevo hasta que algo termine. Suena trivial pero es profundamente transformador: obliga al equipo a terminar antes que empezar, lo que reduce drásticamente el tiempo de ciclo y expone los cuellos de botella.

Scrum y Kanban no son alternativas excluyentes. Muchos equipos usan Kanban dentro de un Sprint de Scrum (a veces se le llama "Scrumban"), o Scrum para producto y Kanban para soporte y operaciones. La elección suele depender del tipo de trabajo: cuando el trabajo es predecible y se puede planificar en bloques, Scrum funciona bien; cuando llega de forma continua e impredecible —incidentes, bugs, pedidos de stakeholders— Kanban es más natural.

Scrum vs Kanban

Scrum

• Cadencia fija (Sprints), buena para trabajo planificable.
• Roles y ceremonias definidas: framework prescriptivo.
• Rígido frente a interrupciones no planificadas.
• Curva de adopción mayor: hay que aprender el framework.

Kanban

• Flujo continuo, ideal para soporte y trabajo reactivo.
• Curva plana: tres reglas (visualizar, limitar WIP, gestionar flujo).
• Sin ritmo natural: requiere disciplina para no postergar entregas.
• Menos estructura para coordinar equipos grandes.

7. Más allá de Scrum y Kanban

El ecosistema ágil tiene más actores que vale conocer aunque sea superficialmente. Extreme Programming (XP), creado por Kent Beck a fines de los 90, se enfoca en prácticas técnicas concretas —programación en pares, desarrollo guiado por pruebas (TDD), integración continua, refactoring constante— y es históricamente la fuente de muchas de las prácticas de ingeniería que hoy damos por sentadas. Mientras Scrum se ocupa del proceso, XP se ocupa de cómo escribir el código.

Lean Software Development, popularizado por Mary y Tom Poppendieck, traduce los principios del Lean manufacturing al software: eliminar desperdicio, amplificar el aprendizaje, decidir lo más tarde posible, entregar lo más rápido posible, empoderar al equipo, construir integridad, ver el todo. Es menos un framework y más una filosofía transversal.

SAFe (Scaled Agile Framework) intenta escalar el agilismo a organizaciones grandes con muchos equipos. Es controvertido: sus detractores argumentan que reintroduce la jerarquía y la documentación pesada que el Manifiesto rechazaba, vestidas con vocabulario ágil. Si te cruzás con él en un trabajo, vale la pena leerlo con espíritu crítico antes de comprarlo entero.

8. Cascada frente a Ágil

Después de recorrer ambos mundos vale resumir el contraste central. Ninguno es universalmente mejor: cada uno encaja en contextos distintos. Lo que pasó en la práctica es que los contextos donde encaja la cascada se redujeron a un puñado de nichos, mientras que los contextos donde encaja el agilismo crecieron hasta cubrir prácticamente todo el desarrollo web, móvil y cloud-native.

9. Ágil y la nube: por qué se necesitan mutuamente

La adopción masiva del agilismo durante los 2000 y la adopción masiva de la nube durante los 2010 no son eventos independientes: cada uno alimentó al otro. El agilismo prometió entregas frecuentes; sin nube, "frecuente" significaba cada pocos meses, limitado por los tiempos de aprovisionamiento de hardware en data centers propios. Con nube, esos tiempos se redujeron a minutos, lo que permitió cumplir la promesa original: entregar software funcionando "frecuentemente, de un par de semanas a un par de meses, con preferencia por la escala más corta", como dice el segundo principio del Manifiesto.

A su vez, la nube necesita del agilismo para no desperdiciar su potencial. Una arquitectura de microservicios elásticos operada por un equipo que despliega una vez por trimestre es un mal uso de la infraestructura: paga la complejidad de los microservicios sin cobrar el beneficio de la independencia de despliegue. La cultura de DevOps —que en su núcleo es la fusión de desarrollo y operaciones en equipos autónomos, con automatización fuerte de la cadena de despliegue— es el puente entre ambas realidades: arquitectura cloud-native + proceso ágil + automatización operacional.

Las prácticas concretas que hicieron esto posible son hoy estándar de la industria: integración continua (CI), donde cada cambio se integra al tronco principal varias veces al día y se valida automáticamente; despliegue continuo (CD), donde cada cambio que pasa CI se despliega automáticamente a producción; infraestructura como código (IaC), donde la infraestructura se define en archivos versionados como cualquier otro código; y observabilidad, donde se mide el comportamiento del sistema en producción y los datos retroalimentan las próximas iteraciones. La trazabilidad de esas decisiones suele apoyarse en diagram as code (Mermaid, PlantUML, D2), para que los diagramas que documentan la arquitectura cambien junto con el código que documentan en lugar de quedar congelados en un PNG colgado en algún wiki. Cada una de estas prácticas, por separado, era difícil antes de la nube; con nube, son lo normal.

10. Errores comunes

El agilismo es probablemente el conjunto de ideas más malentendido de la industria del software. Estos son los tres errores que se repiten en proyectos reales con mayor consistencia, y los que más vale anticipar.

11. Buenas prácticas

12. Glosario rápido

13. Para profundizar

14. Cierre

Esta unidad cierra el bloque fundamental del curso. Empezamos con qué es la nube como modelo económico, bajamos a las dos capas técnicas que la sostienen, subimos a los principios que moldean la arquitectura, y terminamos con el proceso humano que produce el software que corre sobre todo eso. Las cuatro unidades no son temas independientes sino capas de un mismo edificio: ninguna funciona sin las demás.

Lo que sigue es el bloque aplicado: la Unidad 5 entra al gran consumidor actual de esa infraestructura —la IA generativa— y la Unidad 6 muestra cómo se combinan todas las piezas vistas para armar un producto real, como puente directo al challenge final.