Ciclos de vida: predictivo, adaptativo e híbrido
Cascada, iterativo, incremental, ágil e híbrido: qué los distingue de verdad, y cómo elegir según la estabilidad de los requisitos, el tamaño del equipo, el riesgo tecnológico y el plazo.
- Distinguir con precisión iterativo de incremental (la confusión más común).
- Explicar la diferencia esencial entre predictivo y adaptativo.
- Recomendar un ciclo de vida para un proyecto concreto y justificarlo con los cuatro factores del temario.
- Reconocer los valores del Manifiesto Ágil y desmontar los mitos sobre lo ágil.
Tema 1, diapositivas 48-50. La diapositiva 50 termina con una pregunta del profesor: "¿podéis darme ejemplos de proyectos en los que sería mejor uno que otro?". Es casi seguro que habrá preguntas de escenario: "dado este proyecto, ¿qué ciclo de vida?". Lo ágil en detalle (Scrum) es Tema 3, pero aquí necesitas lo suficiente para contrastar.
1. Qué es un ciclo de vida
Un modelo de ciclo de vida es la forma en que se organizan en el tiempo las actividades del desarrollo (requisitos, diseño, construcción, pruebas, despliegue): en qué orden, cuántas veces y cuándo se entrega. Las diapositivas citan cinco:Tema 1, diap. 48. predictivo/secuencial/cascada, iterativo, incremental, ágil e híbrido.
2. Predictivo (secuencial, cascada)
Se intenta definir y planificar gran parte del trabajo al inicio.Tema 1, diap. 50. Las fases van una detrás de otra: requisitos → diseño → implementación → pruebas → despliegue. Cada fase termina con un entregable revisado (un documento de requisitos aprobado, un diseño aprobado) antes de empezar la siguiente. El cliente ve el producto funcionando al final.
- Funciona bien cuando los requisitos son estables y bien conocidos, la tecnología es conocida, y cambiar es caro o está regulado (software embebido de un marcapasos, un sistema contable regido por una norma, una migración bien acotada).
- Falla cuando los requisitos cambian o no se conocen: descubres los errores de requisitos en las pruebas, al final, cuando corregirlos es carísimo (lección 1).
Ampliación: el artículo de Winston Royce (1970) que se cita como origen de la cascada en realidad advertía de sus riesgos y proponía iterar. Una variante es el modelo en V, que empareja cada fase de definición con su nivel de prueba (requisitos ↔ aceptación, diseño ↔ integración…).
3. Iterativo frente a incremental
Son dos ideas distintas que se combinan a menudo. Merece la pena tenerlas muy claras:
| Iterativo | Incremental | |
|---|---|---|
| Idea | Repetir el ciclo para refinar: cada vuelta mejora lo que ya existe | Construir por partes: cada entrega añade funcionalidad completa nueva |
| Pregunta | ¿Cómo lo hacemos mejor? | ¿Qué parte añadimos ahora? |
| Imagen | Pintar el cuadro entero en boceto, luego con color, luego con detalle | Pintar el cuadro trozo a trozo, cada trozo ya terminado |
| TusBus | v1 con estimación simple; v2 con un modelo mejor; v3 con datos de tráfico | Entrega 1: tiempos de llegada; entrega 2: favoritos; entrega 3: avisos |
| Riesgo que reduce | No saber cómo debe ser (requisitos, diseño) | Tardar mucho en entregar valor |
La metáfora del cuadro es de Jeff Patton (User Story Mapping, 2014), con la Mona Lisa.
Un proyecto puede ser incremental sin ser iterativo (entregas por módulos, cada uno hecho en mini-cascada y nunca revisado) o iterativo sin ser incremental (prototipos sucesivos del producto entero, que sólo se entrega al final). Lo ágil es las dos cosas a la vez.
Ampliación: el modelo en espiral de Boehm (1986) es iterativo y está guiado por el riesgo: cada vuelta empieza identificando y reduciendo el mayor riesgo pendiente. Es la raíz de la "priorización por riesgo" de la lección 5.
4. Ágil
Ágil es una familia de enfoques adaptativos: se aprende y se ajusta progresivamente.Tema 1, diap. 50. Se trabaja en ciclos cortos (iteraciones de 1-4 semanas, o flujo continuo), cada uno termina con software funcionando que el cliente ve y comenta, y lo aprendido cambia el plan de los siguientes. Su filosofía está en el Manifiesto Ágil (2001):Manifiesto Ágil (español).
| Valoramos más… | …que |
|---|---|
| Individuos e interacciones | procesos y herramientas |
| Software funcionando | documentación extensiva |
| Colaboración con el cliente | negociación contractual |
| Respuesta ante el cambio | seguir un plan |
La frase final del manifiesto es la que se olvida: "aunque valoramos los elementos de la derecha, valoramos más los de la izquierda". Ágil no elimina planes, documentación ni contratos: los pone al servicio de lo de la izquierda.
Marcos ágiles habituales: Scrum (sprints de duración fija, roles de Product Owner, Scrum Master y equipo de desarrollo; eventos como planificación, daily, revisión y retrospectiva) y Kanban (flujo continuo, tablero visible, límite de trabajo en curso, WIP). Los verás a fondo en el Tema 3; aquí basta con saber que existen y que la gestión no desaparece en ellos: se integra en el backlog, la planificación y las retrospectivas.Las diapositivas citan Scrum y Kanban como apoyo a planificación y seguimiento: Tema 1, diap. 60.
- "En ágil no hace falta especificar requisitos": falso. Se especifican de otra forma (historias de usuario con criterios de aceptación) y de forma progresiva, justo antes de necesitarlos.
- "Debe haber una separación nítida entre el equipo y el cliente": falso, es lo contrario: colaboración continua.
- "Los cambios son el enemigo": falso. Actitud de encajar los cambios; respuesta al cambio sobre seguir un plan.
- "Ágil = sin planificación": falso. Se planifica más a menudo y con horizontes más cortos (planificación continua, rolling wave).
- "Ágil = sin documentación": falso. Documentación "justa y suficiente".Tema 1, diap. 65.
- Sí caracterizan lo ágil: entregas y demostraciones frecuentes, actitud de encajar los cambios, colaboración con el cliente, equipos autoorganizados.
5. Híbrido
Combina elementos predictivos y adaptativos. Es lo más frecuente en la industria real. Formas típicas:
- Por partes del proyecto: el hardware (o la infraestructura, o el contrato) predictivo; el software ágil. Un sistema de pantallas para las paradas de TusBus: la compra e instalación de pantallas es predictiva (no puedes "iterar" la obra civil); el software que muestran, ágil.
- Por fases: definición y viabilidad predictivas (presupuesto, contrato, hitos), construcción en sprints.
- Por gobernanza: la organización exige hitos y presupuesto anual (predictivo), el equipo trabaja en Scrum dentro de esos hitos.
Ojo con el híbrido mal hecho ("water-scrum-fall"): requisitos cerrados en cascada, sprints en medio, y pruebas y despliegue al final en cascada. Tiene los costes de ambos y los beneficios de ninguno.
6. Cómo elegir
La elección del ciclo de vida no es una decisión trivial ni única: debe adaptarse al contexto considerando la estabilidad de los requisitos, el tamaño del equipo, el riesgo tecnológico y el plazo disponible, porque un modelo inadecuado (predictivo, ágil o híbrido) puede condenar al proyecto antes de escribir la primera línea de código, mientras que el acertado es un habilitador natural del éxito.Tema 1, diap. 49.
| Factor | Empuja hacia predictivo si… | Empuja hacia adaptativo si… |
|---|---|---|
| Estabilidad de requisitos | Son estables, conocidos, impuestos (una ley, una norma) | Son inciertos o cambiarán al ver el producto |
| Tamaño del equipo | Muy grande, distribuido, con muchos proveedores, que necesita coordinación formal | Pequeño (unas 3-9 personas), en contacto directo; o grande dividido en equipos pequeños con un marco de escalado |
| Riesgo tecnológico | Tecnología conocida, ya hecha antes | Tecnología nueva: hay que aprender pronto con iteraciones cortas |
| Plazo disponible | Plazo holgado y alcance fijo, entrega única aceptable | Hay que entregar valor pronto o la fecha es fija y el alcance puede ajustarse |
Ampliación: el PMBOK 7 añade factores del producto (grado de innovación, seguridad física, regulación), del proyecto (interesados, restricciones de calendario, financiación) y de la organización (estructura, cultura, capacidad). Las matrices de complejidad tipo Stacey dicen lo mismo: cuanto más incierto es qué construir y cómo, más adaptativo.
Ejemplos, como pedía el profesor
| Proyecto | Ciclo | Por qué |
|---|---|---|
| Adaptar la nómina de una empresa a un cambio legal en el IRPF | Predictivo | Requisitos fijados por ley, tecnología conocida, fecha de entrada en vigor |
| App de una startup para un mercado que aún no se conoce | Ágil | Requisitos muy inciertos; hay que aprender con usuarios reales rápido |
| Software de control de un dispositivo médico | Predictivo o híbrido con mucha verificación | Regulación estricta, trazabilidad obligatoria, seguridad física (aunque el desarrollo interno puede ser iterativo) |
| TusBus | Ágil o híbrido | Fecha fija (feria) con alcance negociable (MoSCoW); requisitos que cambiarán al probar; riesgo técnico en los datos GPS; equipo pequeño. Probablemente contrato e hitos predictivos y construcción en iteraciones |
| Migración de 200 servidores de un banco a la nube con 5 proveedores | Híbrido | Equipo grande y distribuido y hitos contractuales (predictivo), con oleadas de migración iterativas que aprenden de la anterior |
Predictivo apuesta por saber al principio; adaptativo apuesta por aprender por el camino. Se elige según cuánta incertidumbre haya, y casi nunca en estado puro.
Práctica
¿Cuál es la diferencia esencial entre un enfoque predictivo y uno adaptativo?
- El predictivo no tiene plan y el adaptativo planifica todo con detalle
- El predictivo define gran parte al inicio; el adaptativo aprende y ajusta
- El predictivo usa documentación y el adaptativo no documenta nada
- El predictivo es para equipos pequeños y el adaptativo para grandes
¿Iterativo o incremental?
- Cada entrega añade un módulo nuevo y completo: primero reservas, luego pagos
- Se rehace la pantalla principal tres veces, mejorándola con lo aprendido
- El modelo de estimación se refina en cada versión con más datos reales
- Se publica la app con 3 líneas de bus, y en cada entrega se añaden más líneas
¿Qué aspectos caracterizan a las metodologías ágiles?
- Entregas y demostraciones frecuentes del sistema
- Una separación nítida entre el equipo y el cliente
- Actitud de encajar los cambios cuando aparecen
- No es necesario realizar especificación de requisitos
- Respuesta ante el cambio por encima de seguir un plan
- Los cambios son el enemigo y deben evitarse a toda costa
Hay que adaptar el sistema de facturación de una empresa a una nueva norma de factura electrónica, con especificación técnica oficial cerrada y fecha legal de obligatoriedad. El equipo conoce bien la tecnología. ¿Qué ciclo de vida encaja mejor?
- Ágil puro, porque siempre es el enfoque más moderno y eficiente
- Predictivo, porque los requisitos son estables y la tecnología conocida
- Espiral, porque el riesgo tecnológico del proyecto es muy elevado
- Ninguno, porque con una fecha legal no se puede planificar el trabajo
Una startup de 5 personas quiere lanzar una app para un tipo de usuario que aún no conoce bien, y no sabe qué funciones serán las que importen. ¿Qué ciclo de vida recomiendas?
- Cascada, para dejar todos los requisitos cerrados antes de programar
- Modelo en V, porque así cada fase tiene su nivel de prueba asociado
- Ágil, con entregas cortas para aprender de usuarios reales pronto
- Predictivo con un contrato cerrado de alcance, plazo y presupuesto
Verdadero o falso: "Según el Manifiesto Ágil, la documentación, los planes y los contratos no tienen valor".
- Verdadero
- Falso
Recomienda un ciclo de vida para TusBus justificándolo con los cuatro factores del temario.
¿Qué quiere decir el temario con que un ciclo de vida inadecuado "puede condenar al proyecto antes de escribir la primera línea de código"? Pon un ejemplo.
Repaso espaciado · lecciones 3-6
¿Cuál es la pregunta fundamental del estudio de viabilidad?
- ¿Podemos construir el sistema con la tecnología que ya tenemos?
- ¿Cuánto costará exactamente el proyecto hasta su entrega final?
- ¿Debemos hacer este proyecto, en todas sus dimensiones?
- ¿Qué arquitectura es la más moderna para este tipo de sistema?
Repaso de WSJF: valor 13, criticidad temporal 8, reducción de riesgo 4, tamaño 5. ¿WSJF?
Para profundizar
Manifiesto Ágil y sus 12 principios (5 minutos, merece la pena leerlos literalmente). Para Scrum en su fuente primaria (adelanto del Tema 3): The Scrum Guide. Para ciclos de vida en general: Sommerville, cap. 2 "Software processes".
Pide a un asistente que te describa cinco proyectos variados y elige para cada uno el ciclo de vida justificándolo con los cuatro factores; luego pídele que critique tu justificación.
Resumen imprimible: Referencia · Fundamentos.