Ciclo de Vida del Software
y Metodologías Ágiles

Ingeniería del Software

La Ingeniería del Software surge en la Conferencia de la OTAN de 1968 (Garmisch, Alemania) como respuesta a la denominada "crisis del software": proyectos que se entregaban tarde, superaban el presupuesto y tenían una calidad deficiente.

Objetivos principales

Características del software (diferencias con hardware)

• No se fabrica en sentido clásico: se desarrolla o ingenia.
• No se desgasta: el deterioro es por obsolescencia o cambio de requisitos.
• Es intangible y difícil de medir directamente.
• Puede copiarse sin coste de reproducción físico.
• La mayoría se construye a medida, aunque reutilizando componentes.

Ciclo de Vida del Desarrollo del Software (CVDS)

El CVDS proporciona un marco común de referencia para planificar, controlar y gestionar el desarrollo de software. No es un modelo de proceso único; es el concepto que abarca todos los modelos posibles.

Fases genéricas del CVDS

Modelos de Ciclo de Vida

Modelo en Cascada (Waterfall)

Propuesto por W. Royce (1970). Las fases se ejecutan de forma secuencial y cada una debe completarse antes de iniciar la siguiente. Es el modelo clásico prescriptivo.

Modelo en V (Verificación y Validación)

Extensión del cascada donde cada fase de desarrollo tiene asociada una fase de pruebas correspondiente. Facilita la trazabilidad entre requisitos y pruebas.

Modelo Incremental

El sistema se desarrolla y entrega en incrementos funcionales sucesivos. Cada incremento añade nuevas funcionalidades sobre las anteriores. Permite entregas tempranas de valor.

Modelo en Espiral (Boehm, 1988)

Combina el modelo cascada con el prototipado. Cada ciclo (vuelta de espiral) pasa por cuatro cuadrantes:

• Determinación de objetivos (requisitos, restricciones, alternativas)
• Evaluación y reducción de riesgos (análisis de riesgos, prototipado)
• Desarrollo y validación (modelo de ciclo de vida aplicable al cuadrante)
• Planificación del siguiente ciclo

Prototipado

Se construye un prototipo (desechable o evolutivo) para validar requisitos antes del desarrollo completo. Útil cuando los requisitos son difusos o el interfaz de usuario es crítico.

Modelos ágiles / iterativos e incrementales

Basados en iteraciones cortas (sprints) con entregas frecuentes de software funcionando. Scrum, Kanban, XP, SAFe. Se detallan en las secciones siguientes.

Metodologías de Desarrollo

Clasificación

Metodologías Tradicionales (Predictivas / Plan-driven)

RUP (Rational Unified Process), MSF (Microsoft Solutions Framework), MÉTRICA v3 (España). Se basan en planificación exhaustiva y documentación rigurosa. Adecuadas cuando los requisitos son estables y el contrato es fijo.

MÉTRICA Versión 3

Metodología oficial del Ministerio de Administraciones Públicas de España (actualmente MPTFP). Basada en RUP y estándares ISO/IEC. Define tres procesos de desarrollo: ASI (Análisis del Sistema de Información), DSI (Diseño) y CSI (Construcción). Muy preguntada en oposiciones de la Administración General del Estado.

Metodologías Ágiles (Adaptativas / Value-driven)

Scrum, Extreme Programming (XP), Kanban, Crystal, DSDM, FDD. Se basan en iteraciones cortas, colaboración con el cliente y adaptación al cambio. Detalladas a partir de la sección 5.

El Manifiesto Ágil (2001)

Firmado en febrero de 2001 en Snowbird (Utah) por 17 expertos —entre ellos Kent Beck, Jeff Sutherland, Ken Schwaber y Martin Fowler—. Define 4 valores y 12 principios.

Los 4 Valores

Los 12 Principios del Manifiesto Ágil

1. Satisfacción del cliente mediante entrega temprana y continua de software con valor.
2. Bienvenida a los cambios de requisitos, incluso en etapas tardías del desarrollo.
3. Entrega de software funcionando frecuentemente (semanas, no meses).
4. Los responsables de negocio y los desarrolladores trabajan juntos diariamente.
5. Proyectos construidos en torno a individuos motivados, con el entorno y el apoyo necesarios.
6. La conversación cara a cara es el método más eficiente de comunicación.
7. El software funcionando es la medida principal de progreso.
8. Los procesos ágiles promueven el desarrollo sostenible (ritmo constante indefinidamente).
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad —el arte de maximizar la cantidad de trabajo no realizado— es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. El equipo reflexiona regularmente sobre cómo ser más efectivo y ajusta su comportamiento.

Scrum: Marco de Trabajo Ágil

Scrum se basa en tres pilares empíricos (teoría del control de procesos empírico o empirismo):

Valores de Scrum

Compromiso Coraje Foco Apertura Respeto

El Scrum Team se compromete a alcanzar sus objetivos y a apoyarse mutuamente. Tiene el coraje de hacer lo correcto y trabaja en los problemas difíciles con foco en el Sprint y en los objetivos del equipo, con respeto entre sus miembros y apertura al trabajo y a los desafíos.

Flujo general de Scrum

Roles en Scrum

El Scrum Team es la unidad fundamental de Scrum. Es pequeño (generalmente 10 personas o menos), auto-gestionado y multifuncional. No hay subequipos ni jerarquías. Está formado por exactamente tres roles:

Artefactos de Scrum

Los artefactos representan trabajo o valor y están diseñados para maximizar la transparencia de la información clave. Cada artefacto contiene un compromiso para garantizar que aporta información que mejora la transparencia y el foco.

1. Product Backlog

Lista ordenada de todo lo necesario para mejorar el producto. Es la única fuente de trabajo del Scrum Team. El PO es el único responsable de su contenido, disponibilidad y ordenación.

• Product Backlog Items (PBIs): elementos que lo componen (historias de usuario, épicas, bugs, tareas técnicas, etc.).
• Refinamiento del Product Backlog: actividad continua de descomposición y estimación de PBIs. No consume más del 10 % de la capacidad del equipo.
• Estimación: técnicas como Planning Poker, puntos de historia (Story Points), tallas de camiseta (T-shirt sizing), escala Fibonacci.
• DEEP: el Product Backlog debe ser Detailed appropriately, Estimated, Emergent y Prioritized.

2. Sprint Backlog

Compuesto por: el Sprint Goal, los PBIs seleccionados para el Sprint y el plan para entregar el Incremento. Es propiedad de los Developers y se actualiza a lo largo del Sprint.

• Visible en tiempo real: tablero Kanban o herramienta equivalente.
• Los Developers son los únicos que pueden cambiar el Sprint Backlog durante el Sprint.
• El Sprint Goal no puede alterarse una vez iniciado el Sprint (el alcance puede negociarse).

3. Incremento

Un Incremento es un paso concreto hacia el Product Goal. Cada Incremento se suma a todos los anteriores y es exhaustivamente verificado, asegurando que todos funcionan conjuntamente. Debe ser potencialmente entregable (usable) al final del Sprint.

• DoD (Definition of Done): descripción formal del estado en que debe estar el Incremento para ser considerado Hecho. Si no cumple la DoD, no puede liberarse ni presentarse en la Sprint Review.
• La DoD crea transparencia, ya que todo el mundo entiende el nivel de trabajo completado.
• Si la DoD es impuesta por la organización, el Scrum Team debe cumplirla como mínimo.
• Diferencia entre Done y Ready: un PBI está "listo" (Ready) cuando es suficientemente claro y pequeño para seleccionarlo en un Sprint Planning.

Historias de Usuario (User Stories)

Formato estándar de descripción de PBIs desde la perspectiva del usuario:

Criterios de calidad de una historia: INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable).

Cada historia de usuario incluye criterios de aceptación que definen cuándo se considera completada.

Ceremonias / Eventos de Scrum

Scrum define 5 eventos formales. Todos tienen una duración máxima fija (time-box) para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum.

El Sprint

1. Sprint Planning — Planificación del Sprint

Time-box: máx. 8 horas para un Sprint de un mes (proporcional).

Responde a tres preguntas:

• ¿Por qué es valioso este Sprint? → Se define el Sprint Goal.
• ¿Qué puede hacerse en este Sprint? → Los Developers seleccionan PBIs del Product Backlog.
• ¿Cómo se realizará el trabajo? → Los Developers descomponen los PBIs en tareas de un día o menos.

2. Daily Scrum — Reunión diaria

Time-box: 15 minutos. Mismo lugar y hora cada día. Solo para los Developers.

Su propósito es inspeccionar el progreso hacia el Sprint Goal y adaptar el Sprint Backlog. El Scrum Guide 2020 ya no obliga a las tres preguntas clásicas (qué hice ayer, qué haré hoy, qué impedimentos tengo), dejando libertad de estructura al equipo.

3. Sprint Review — Revisión del Sprint

Time-box: máx. 4 horas para un Sprint de un mes.

El Scrum Team presenta el resultado de su trabajo a los stakeholders y se discute el progreso hacia el Product Goal. No es solo una demo: es una sesión de trabajo donde se revisa y actualiza el Product Backlog.

4. Sprint Retrospective — Retrospectiva del Sprint

Time-box: máx. 3 horas para un Sprint de un mes. Es el último evento del Sprint.

El equipo reflexiona sobre cómo mejorar su eficacia: personas, interacciones, procesos, herramientas y DoD. Se identifican al menos una mejora de alta prioridad para incorporar en el siguiente Sprint. Promueve la kaizen (mejora continua).

5. Refinamiento del Product Backlog (no es evento oficial)

Aunque no es un evento formal de Scrum, es una actividad recurrente donde se divide y ordena el backlog, añadiendo más detalles. No debería consumir más del 10 % de la capacidad del equipo.

Métricas y Conceptos Clave

Velocity (Velocidad)

Cantidad media de Story Points completados por el equipo en cada Sprint. Usada para planificar sprints futuros. No es una métrica de rendimiento individual ni de productividad.

Burndown Chart

Gráfico que muestra el trabajo restante en el Sprint Backlog (eje Y) en función del tiempo transcurrido del Sprint (eje X). Permite visualizar si el equipo va a completar el trabajo en plazo.

Burnup Chart

Similar al Burndown pero muestra el trabajo completado (eje Y) vs. tiempo. Más útil para visualizar el alcance total y los cambios en el backlog.

Cumulative Flow Diagram (CFD)

Muestra el número de elementos en cada estado del flujo de trabajo a lo largo del tiempo. Permite detectar cuellos de botella.

WIP (Work In Progress)

Número de elementos en proceso simultáneamente. Limitar el WIP mejora el flujo y reduce el tiempo de ciclo (principio de Kanban también aplicable en Scrum).

Lead Time vs. Cycle Time

• Lead Time: tiempo desde que se crea un ítem en el backlog hasta que se entrega.
• Cycle Time: tiempo desde que el equipo comienza a trabajar en un ítem hasta que lo completa.

Definición de Ready (DoR)

Criterios que debe cumplir un PBI para poder ser seleccionado en un Sprint Planning: suficientemente entendido, estimado, priorizado y sin dependencias bloqueantes.

Deuda Técnica (Technical Debt)

Consecuencias de decisiones de diseño o implementación rápidas que sacrifican calidad para ganar velocidad a corto plazo. Si no se gestiona, ralentiza el desarrollo futuro. Debe hacerse visible en el Product Backlog.

Spike

Historia de usuario técnica o de investigación cuyo objetivo es adquirir conocimiento para reducir la incertidumbre. Su resultado es información, no software entregable.

Épica (Epic)

Historia de usuario de gran tamaño que no cabe en un Sprint y debe descomponerse en historias más pequeñas antes de ser implementada.

Comparativa: Metodologías Ágiles vs. Tradicionales

Framework Cynefin (contexto de aplicación)

Propuesto por Dave Snowden, ayuda a elegir el enfoque de gestión según el tipo de problema:

• Obvio (Simple): causa-efecto claros → mejores prácticas → metodologías tradicionales.
• Complicado: requiere análisis experto → buenas prácticas → RUP, cascada con análisis profundo.
• Complejo: causa-efecto solo visibles a posteriori → prácticas emergentes → Scrum, métodos ágiles.
• Caótico: no hay patrones → actuar primero → respuesta de emergencia.

Scrum está diseñado para dominios complejos, donde el conocimiento se va descubriendo iterativamente.

Otras Metodologías Ágiles

Extreme Programming (XP)

Creada por Kent Beck (1999). Orientada a la excelencia técnica y la calidad del código. Prácticas clave:

• TDD (Test-Driven Development): escribir la prueba antes que el código (Red-Green-Refactor).
• Pair Programming: dos programadores trabajan juntos en la misma máquina.
• Integración Continua (CI): integrar y verificar el código varias veces al día.
• Refactoring: mejorar el código sin cambiar su comportamiento externo.
• Collective Code Ownership: cualquier miembro puede modificar cualquier parte del código.
• Entregas pequeñas: ciclos cortos con versiones funcionales frecuentes.

Kanban

Método de gestión del flujo de trabajo originado en Toyota (producción lean). Visualiza el trabajo en un tablero con columnas (Pendiente / En Progreso / Hecho). Principios fundamentales:

• Visualizar el flujo de trabajo.
• Limitar el WIP (Work In Progress) por columna.
• Gestionar el flujo para maximizar la entrega de valor.
• Hacer las políticas explícitas.
• Mejora continua (Kaizen).

A diferencia de Scrum, Kanban no tiene roles, sprints ni backlog obligatorio. Es más adecuado para equipos de mantenimiento o soporte.

SAFe (Scaled Agile Framework)

Marco para escalar Scrum y otras prácticas ágiles en organizaciones grandes. Define niveles: Team, Program, Large Solution y Portfolio. Introduce conceptos como el PI Planning (Program Increment Planning), los Agile Release Trains (ART) y los Big Room Planning.

LeSS (Large-Scale Scrum)

Escala Scrum con la mínima complejidad adicional. Un único Product Backlog y un único Product Owner para múltiples equipos Scrum (hasta 8 en LeSS; más de 8 en LeSS Huge).

Crystal

Familia de metodologías de Alistair Cockburn, clasificadas por color según el tamaño del equipo y criticidad: Crystal Clear (≤8 personas), Crystal Yellow, Crystal Orange, Crystal Red.

DSDM (Dynamic Systems Development Method)

Marco ágil con mayor énfasis en la gobernanza. Fija el tiempo y el coste y varía el alcance (Timeboxing). Muy usado en el sector público del Reino Unido.

DevOps y CI/CD

Aunque no es una metodología ágil en sí misma, DevOps es la cultura y conjunto de prácticas que une desarrollo (Dev) y operaciones (Ops) para acortar el ciclo de vida del software y entregar con alta calidad:

• CI (Continuous Integration): integración y pruebas automáticas en cada commit.
• CD (Continuous Delivery/Deployment): despliegue automático a entornos de staging o producción.
• Infrastructure as Code (IaC): gestión de infraestructura mediante código versionado.
• Herramientas: Jenkins, GitLab CI/CD, GitHub Actions, Docker, Kubernetes.