Clase 1 — Introducción a las Metodologías Ágiles y Contexto de la Ingeniería del Software

Resumen Ejecutivo

Esta sesión introductoria presenta el marco de la asignatura y profundiza en por qué surgen las metodologías ágiles como respuesta a los problemas de la ingeniería del software tradicional (la "crisis del software"). Se analizan los factores que determinan cuándo conviene aplicar agilidad frente a metodologías tradicionales (diagrama de Boehm-Turner), se distingue con rigor entre proceso, modelo de proceso y metodología, y se presentan los cuatro valores y doce principios del Manifiesto Ágil (2001) como base conceptual de toda la asignatura.

Conceptos Clave

Proceso de software: Serie de actividades relacionadas que conducen a la elaboración de un producto de software. ⚠️ EXAMEN
Modelo de proceso: Representación (diagrama) de las actividades del proceso y cómo se relacionan entre sí. No es lo mismo que una metodología. ⚠️ EXAMEN
Metodología: Define roles, responsabilidades, artefactos y reglas concretas sobre un modelo de proceso. Ejemplos: Métrica V2, Scrum, XP. ⚠️ EXAMEN
Waterfall (cascada): Es un modelo de proceso, NO una metodología. Flujo lineal y secuencial de actividades. ⚠️ EXAMEN
Agilidad: Capacidad de adaptación rápida al cambio; no es sinónimo de rapidez en el desarrollo, sino rapidez en la respuesta ante cambios. ⚠️ EXAMEN
Manifiesto Ágil (2001): Documento fundacional que define 4 valores y 12 principios de la agilidad, firmado por autores como Kent Beck, Jeff Sutherland y Alistair Cockburn. ⚠️ EXAMEN
Crisis del software (1968): Problemas históricos del desarrollo de software: presupuestos superados, plazos incumplidos, baja fiabilidad y baja calidad, derivados de aplicar al software métodos de ingeniería pensados para productos físicos.
Time to Market (TTM): Tiempo que se tarda en poner producto funcional en el mercado o en manos del cliente.
Return of Investment (ROI): Retorno de la inversión; cuanto antes se entrega valor, antes se recupera la inversión.
Diagrama de Boehm-Turner: Herramienta con 5 ejes para evaluar si un proyecto se sitúa en territorio ágil o tradicional. ⚠️ EXAMEN
Cliente vs. Usuario: El cliente es quien contrata/paga; el usuario es quien utiliza el producto. No siempre coinciden. ⚠️ EXAMEN

Desarrollo del Temario

1. Origen de la agilidad: la crisis del software

El software tiene una naturaleza distinta a los productos de otras ingenierías (arquitectura, aeronáutica, automoción). En las ingenierías tradicionales es relativamente sencillo trabajar por etapas secuenciales porque el producto es más predecible y mensurable.

Ejemplo: Un arquitecto diseña un rascacielos: tiene la idea, hace la maqueta, genera los planos. No puedes llegar al piso 50 y pedir que en vez de 80 pisos sean 120. En software, sin embargo, es habitual que el cliente proponga cambios a mitad del desarrollo.

El software es más manipulable (son caracteres en un archivo de texto que se compilan y recompilan), lo que invita a cambios constantes, pero esa misma manipulación puede corromper la estructura del código, generar bugs y degradar la calidad.

En los años 60-70, las metodologías de construcción de producto industrial se trasladaron directamente al software. Esto generó los problemas de la crisis del software: proyectos "llave en mano" donde el cliente veía el producto solo al final y frecuentemente quedaba insatisfecho.

Ejemplo: El dueño de una empresa en los años 70 pedía una aplicación de gestión de inventario. No tenía conocimientos informáticos, simplemente decía "quiero esto rojo, esto verde, que imprima así". El equipo desarrollaba durante meses y al final: "Vaya, esto no es lo que yo quería". Proyecto comprometido.

2. Metodologías tradicionales (pesadas) vs. ágiles

Metodologías tradicionales (pesadas): - Muy rígidas: si falla una fase, se compromete todo el proyecto - Difícil introducir cambios sobre la marcha; los cambios son muy costosos - Poca retroalimentación del cliente - Gran peso burocrático (aprobaciones de documentos, reuniones excesivas) - Orientadas al proceso

Metodologías ágiles: - Modelos de proceso iterativos: el proyecto se parte en "cachitos" pequeños ⚠️ EXAMEN - Cada iteración es un microproyecto (análisis, diseño, implementación, pruebas, demostración) - Si fallas en una iteración, no se compromete el proyecto completo - Retroalimentación frecuente del cliente - Enfoques más informales, con menos carga burocrática - Orientadas a las personas ⚠️ EXAMEN

Criterio clave de elección: Si el futuro del proyecto es predecible y los requisitos estables → metodologías tradicionales. Si hay mucha incertidumbre y cambios frecuentes → metodologías ágiles. ⚠️ EXAMEN

Ejemplo: Si quiero hacer un clon exacto de Twitter, sé perfectamente lo que necesito → metodología tradicional viable. Si quiero competir contra Twitter con funcionalidades nuevas e innovadoras, hay mucha incertidumbre (¿funcionarán? ¿gustarán? ¿cómo responderá la competencia?) → metodología ágil.

Ejemplo: El software de control de navegación de un avión comercial: los requisitos son estables (la física del avión no cambia), el sistema es crítico → más apropiado un enfoque tradicional.

3. Diagrama de Boehm-Turner: factores para elegir metodología

El diagrama define 5 ejes que ayudan a evaluar si un proyecto es más apto para agilidad o para enfoque tradicional. Cuanto más pequeña sea el área del pentágono resultante, más cerca del territorio ágil: ⚠️ EXAMEN

Dinamismo (eje fundamental): Porcentaje de modificación en requisitos por mes. Más cambios → más ágil.
Personal: Ratio de juniors vs. seniors. Cuidado: equipos muy junior dificultan la agilidad, porque requiere experiencia para estimar compromisos y adaptarse. ⚠️ EXAMEN
Criticidad: Si el fallo causa pérdida de vidas → menos apropiado para agilidad. Niveles: pérdida de vidas > daño ambiental > pérdida de datos > pérdida reputacional.
Tamaño del equipo: Equipos grandes (>20-30 personas) dificultan la comunicación ágil. La agilidad funciona mejor con equipos pequeños (3-8 personas). ⚠️ EXAMEN
Cultura organizacional: Capacidad de la organización para abrazar el cambio y adoptar nuevas formas de trabajo.

Extensiones del diagrama añaden ejes adicionales: - Tiempo de entrega: ¿Cada cuánto quiere el cliente una nueva versión? - Involucración del cliente: ¿Es posible tener acceso frecuente al cliente para obtener retroalimentación?

Ejemplo: Si el cliente es un "borde" que no quiere reunirse cada 15 días para una revisión de sprint, ¿para qué usar Scrum? No tiene sentido aplicar una metodología cuya base es la retroalimentación frecuente si no hay acceso al cliente.

4. Modelos de proceso: prescriptivos vs. ágiles

Modelo en cascada (prescriptivo lineal): - Flujo secuencial: análisis → diseño → implementación → pruebas → despliegue - Cada actividad se cierra antes de pasar a la siguiente - Apropiado cuando los requisitos son claros y estables - No usar cuando hay mucha incertidumbre ⚠️ EXAMEN

Modelo incremental: - Se descompone el proyecto en versiones incrementales - En cada incremento se implementa un subconjunto de funcionalidades - Mejora el Time to Market y el ROI: el cliente recibe valor antes ⚠️ EXAMEN - Problema: puede degradar la arquitectura si no se gestiona bien (refactorizaciones constantes)

Modelo evolutivo: - Similar al incremental pero con más incertidumbre - En cada iteración se mejora la comprensión del sistema, del mercado y de las necesidades del cliente - Los cambios en la especificación surgen naturalmente en cada iteración y se acomodan en la siguiente

5. El coste del cambio

Con procesos convencionales, el coste de corregir un error crece de manera exponencial a medida que avanza el proyecto. Descubrir un error en la fase de despliegue puede obligar a rehacer el 60% del producto.

Con procesos ágiles, el objetivo es mantener el coste del cambio acotado y constante en el tiempo. En la práctica, la curva se suaviza significativamente gracias a la retroalimentación frecuente. ⚠️ EXAMEN

Ejemplo: Un coche autónomo a 200 km/h: si los sensores toman medidas cada 5 segundos, es fácil estrellarse. Si las medidas correctoras se toman cada 10 milisegundos, se puede corregir la trayectoria. Lo mismo pasa en proyectos: no es igual tomar el pulso del cliente cada 6 meses que cada 2 semanas.

6. El Manifiesto Ágil (2001): valores y principios

En 2001, un grupo de profesionales del software (Kent Beck, Jeff Sutherland, Alistair Cockburn, Martin Fowler, entre otros) se reunieron y definieron los fundamentos de la agilidad. Todas las metodologías ágiles beben de estos valores y principios. ⚠️ EXAMEN

Los 4 valores del Manifiesto Ágil ⚠️ EXAMEN

Se valora más...	Sobre...
Individuos e interacciones	Procesos y herramientas
Software funcionando	Documentación extensiva
Colaboración con el cliente	Negociación contractual
Respuesta ante el cambio	Seguimiento de un plan

Corolario fundamental: "Aunque reconocemos valor en los elementos de la derecha, valoramos más los de la izquierda." No se niega el valor de procesos, documentación, contratos o planes; simplemente se priorizan las personas, el software funcional, la colaboración y la adaptabilidad. ⚠️ EXAMEN

Desglose de cada valor:

Individuos e interacciones: El éxito depende del equipo. La tecnología se ha democratizado (herramientas gratuitas, código abierto); lo que diferencia es cómo trabajan las personas, cómo se comunican, cómo colaboran. Las herramientas las elige el equipo.
Software funcionando: La documentación es importante pero aporta menos valor que código funcional. Lo prioritario es que el cliente esté satisfecho con algo que funciona.
Colaboración con el cliente: Frente a la negociación contractual puntual (firmar requisitos al inicio), se busca colaboración continua. En XP existe la práctica de cliente in situ: el cliente forma parte del equipo de desarrollo.
Respuesta al cambio: El cambio es inevitable (mercado, competencia, tecnología, presupuesto). Si planificas todo al inicio y a mitad hay que cambiar, es un desastre. Mejor planificar poco a poco.

Principios destacados del Manifiesto

No existe la figura del Project Manager en metodologías ágiles puras (ni en Scrum ni en XP). La responsabilidad de organización y planificación está distribuida en el equipo (jerarquías horizontales). ⚠️ EXAMEN
Equipos multidisciplinares y autoorganizados.
Comunicación oral como medio principal.
Bienestar del programador: en XP, la práctica de la "jornada de 40 horas" (no sobrecargar al equipo).
Propiedad del código compartida (XP): todo el equipo es responsable y propietario de todo el código. Requiere equipo senior.

7. Distinción crítica: modelo ≠ metodología ≠ paradigma

"Metodología Waterfall" no existe. Waterfall es un modelo de proceso. Sobre él se apoyan metodologías concretas (ej.: Métrica V2). ⚠️ EXAMEN
"Metodología Agile" no existe. La agilidad es un paradigma. Las metodologías ágiles concretas son: Scrum, XP, Crystal, Feature-Driven Development, etc. ⚠️ EXAMEN
Una metodología define roles, responsabilidades, artefactos y reglas concretas sobre un modelo de proceso.

Ejemplo: Métrica V2 es una metodología tradicional concreta utilizada en proyectos con la administración pública española, donde a veces es obligatorio utilizarla. A veces es el propio cliente quien te marca la metodología.

8. Visión general de la asignatura

La asignatura se estructura en tres bloques:

Metodologías ágiles (Temas 1-3): Manifiesto Ágil, Scrum (eventos, artefactos, roles), Programación Extrema (XP) y sus 12 prácticas de ingeniería.
Reutilización y patrones (Temas 4-7): Reutilización del software, patrones arquitectónicos generales, patrones de arquitectura cloud (CQRS, etc.), patrones de diseño GoF (creacionales, estructurales, comportamiento).
Calidad del software (Temas 8-9): Test-Driven Development (TDD), Acceptance TDD (ATDD), Behavior-Driven Development (BDD) con Cucumber/Gherkin, e introducción a DevOps (CI/CD).

Preguntas de Autoevaluación

¿Cuál es la diferencia entre un modelo de proceso y una metodología? ¿Por qué es incorrecto hablar de "metodología Waterfall"?
Enumera los 4 valores del Manifiesto Ágil y explica qué significa el corolario "aunque reconocemos valor en los elementos de la derecha, valoramos más los de la izquierda".
¿Cuáles son los 5 ejes del diagrama de Boehm-Turner? ¿Por qué un equipo muy junior puede dificultar la aplicación de metodologías ágiles?
Explica con un ejemplo por qué el coste del cambio crece exponencialmente en metodologías tradicionales y cómo la agilidad intenta acotar ese coste.
¿Cuándo sería más apropiado utilizar una metodología tradicional en lugar de una ágil? Pon un ejemplo concreto.
¿Qué diferencia hay entre un modelo incremental y un modelo evolutivo?
¿Por qué el tamaño del equipo y la involucración del cliente son factores determinantes para decidir si usar agilidad?
¿Existe la figura de Project Manager en Scrum? ¿Por qué?

Guía generada automáticamente a partir de transcripción con faster-whisper + Claude Sonnet.