Inicio → alinear visión, alcance y presupuesto.
Elaboración → refinar requisitos prioritarios y diseñar la arquitectura base.
Construcción → desarrollar el sistema de forma iterativa hasta cubrir los requisitos.
Transición → liberar, entrenar usuarios y dar soporte hasta la aceptación.

Sprint Planning → definir la meta del Sprint y seleccionar PBIs.
Sprint (1-4 sem.) → crear un incremento potencialmente liberable.
Daily Scrum → inspeccionar y adaptar el plan diario.
Sprint Review & Retrospective → inspeccionar el producto y mejorar el proceso.

Cada fase puede tomar semanas o meses y se completa cuando cumple criterios de salida predefinidos.

Sprints cortos y fijos; el ciclo se repite hasta alcanzar el valor deseado.

Documentación extensa (modelo de casos de uso, artefactos de diseño, planes de prueba) y versiones incrementales del producto.

Incremento funcional de software + artefactos ligeros (Backlog, Definition of Done) orientados a la entrega temprana de valor.

• Gestión explícita de riesgos críticos en la fase de Elaboración, reduciendo sorpresas técnicas en sistemas complejos.

• Arquitectura robusta y documentada, valiosa cuando el mantenimiento a largo plazo y la escalabilidad son prioridades de calidad.

• Procesos y roles bien definidos, lo que facilita el control de proyectos regulados o que exigen fuerte trazabilidad (p. ej., sectores bancario o sanitario).

• Menor adaptabilidad al cambio de requisitos: los artefactos y planes de fase requieren re-aprobación formal, algo que la empresa identifica como problema (“incapacidad para adaptarse rápidamente”) .

• Sobrecarga documental y de gobierno, que puede alargar los ciclos —precisamente otro dolor de XYZ (“largos ciclos de desarrollo”) .

• Curva de aprendizaje y coste inicial altos: exige capacitación en roles (Arquitecto, Gestor de Configuración, etc.) y herramientas de modelado; equipos pequeños pueden percibirlo como burocrático.

• Scrum encaja de forma natural en los dos primeros objetivos (adaptabilidad y rapidez), gracias a sus sprints cortos, priorización continua y ciclos de retroalimentación.

• RUP, por su parte, brinda un marco sólido para el tercer objetivo (calidad) mediante control de riesgos y una arquitectura documentada; sin embargo, puede contrarrestarse si la organización no atenúa la burocracia con prácticas ágiles (p. ej., Agile Modeling o OpenUP).

Para los objetivos estratégicos de XYZ Software Solutions —acortar los ciclos de entrega, adaptarse con agilidad a cambios de alcance y mantener un nivel de calidad controlado— el marco que ofrece Scrum puro resulta el más adecuado.

• Sprints cortos entregan valor funcional en semanas, reduciendo el lead time.

• La inspección y adaptación en cada Sprint Review y Retrospective permiten reaccionar oportunamente a nuevas prioridades del negocio.

• La Definition of Done y prácticas de calidad integradas (p. ej., pruebas unitarias automáticas) preservan la robustez sin la pesada carga documental de RUP.

En consecuencia, adoptar Scrum como esquema principal brinda a XYZ retroalimentación continua, visibilidad temprana de avances y una mejora sostenida del proceso, alineándose plenamente con su necesidad de rapidez y flexibilidad competitiva.